As a media owner, you can choose to use the people-centric, web application or go the fully electronic route and use the API. Below is our current API service spec. If you have any questions please Contact Us.
Whether you're a buyer or a seller of media you can use the full web application to trade on MediaEquals. This is a great place to start but we also provide a path to full electronic trading that will further reduce your admin and manual processing time.
The MediaEquals API breakdown into three clear areas
- The booking or trading process including the import and export of media plans, bookings, accounting data
- The admin tools you need to remotely manage your MediaEquals service
- Reporting, monitoring and audit access
MediaEquals exposes certain elements of it's service as a REST based API which is secured over 2-Legged OAuth.
RESTful Web Services
The basic principle of REST is that a URL should access a resource on a server for-example to request an article you could have a URL in the form http://yourserver.com/article/12 instead of http://yourserver.com/articles.php?article=12, this is because an article actually exists as a distinct thing, as apposed to being an option to articles.php. There is a good explanation available at IBM Developerworks.
OAuth is a modern a simple modern authentication process used by Google, Twitter and many others, the specification is available at here.
There are two distinct flavours of OAuth:
The first being 3-Legged where the user is using a website and wants that website to perform operations upon resources stored on another website. There are three parties to the communication known in OAuth as User, Consumer and Service-Provider. The User is a physical person, the Consumer is the website which the user has his/her browser upon and the Service-Provider hosts the resources upon which the user wants the Consumer to perform actions upon. The caveat of this is that the User does not necessarily want to give the Consumer his/her password to the Service-Provider.
The second is the less widely used/documented version called 2-Legged which is when there are only two parties and the trust between them has already been established. Therefore the not-revealing-username/password problem does not exist. There is no specific specification for this however this is just the very first stage of the normal 3-Legged OAuth process flow, stage A in the OAuth Authentication Flow diagram within the old 1.0 specification.
MediaEquals RESTful API
MediaEquals accepts and responds to all requests using JSON unless otherwise noted.
All requests will return data in the form:
Where validation errors are errors in the form of the request and business errors are either system errors or errors not related to the request. If there are no errors a body will be returned containing the result of the request.
A HTTP error code or 200 will also be sent in the headers.
If due to firewall/proxy restrictions you are unable to issue PUT or DELETE requests please use the special _REQUEST_METHOD parameter with the value of GET/PUT/POST/DELETE in a POST request and it will be handled using the appropriate method.
Non GET methods usually involve specifying additional methods, these are listed along with the resource documentation.