Attention: API is under active development. Soon it will be supplemented by many new methods, however subject to change in existing methods . We will notify you of important changes, stay in touch

Beginning of work

The document describes the WhoCPA service programming interface (hereinafter referred to as the “API”). Through the API, external applications add and edit offers, goals, promotional materials, receive lists of offers, leads, and all kinds of statistics.

It is assumed that the reader knows the terminology and understands the principles of CPA networks. This information is contained in the user help.

Use cases

The API provides various levels of access to system objects; these levels correspond to account types. Without authorization, the "Guest" level is available, using which you can get information, also available without registering on the site: a list of available offers, their goals, news, etc. The levels of "Webmaster" and "Advertiser" correspond to the functionality of similar accounts on the site.

Access

Public information, such as a list of offers, their goals, categories, etc. available without authorization.

To use the functionality of your account, with each request you should pass the api_key parameter, which can be obtained on the profile page or at the top of this page.

REST

The API is built on the principle of REST. To access any resource, just make a normal HTTP request.

In general, the resource url looks like this: /api/<resource_name>, There can be 5 methods of interacting with the resource

Obviously, not every resource supports all 5 interaction methods. A complete list of available methods for each type of account can be seen in the "Resources and Methods" menu on the left.

Request parameters

The basic method of transmitting data over HTTP is used. In the case of GET requests & mdash; parameters are passed as a string of url parameters, in case of POST, PUT, DELETE & mdash; in the body of the request.

Additional serialization of the request is not required, however, note that in some cases it is necessary to useURL encoding.

Server responses and errors

Response data format — always json. In the table above you can see which fields should be expected in the response in case of a successful request. In case of an error in the response, only the field will be eroded error.

The general rule is this: if the response does not contain the error field, then the request is successful, and in the response you need to search for the field that matches the request (see the table of methods).

The error field contains the most detailed error description. This field can contain a string or a more complex data structure, for example:

GET /api/geo?api_key=wrongkey

{ "error": "Unauthorized" }

GET /api/goal/?offer_id=-123

{ "error": { "offer_id": ["Offers not found"] } }

In addition to the error description in the error field, general information about the response (including the error) is transmitted in the HTTP status code. List of used codes: