WhoCPA API documentation

  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.


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.


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

Method Request Appointment
list GET /api/resource/

Get a list of objects according to the specified parameters. It is used mainly for the complete unloading of information, and can also be used for search.

A list of objects can be found in the objects field of the response.

Most often, the list method does not immediately return all the objects found, instead, the answer is divided into several parts, in other words, the pagination mechanism is turned on.

If pagination is used for the list method of this resource, in the server response, in addition to the objects field, three more fields appear:

  • total_count How many total objects were found, according to the passed parameters.
  • per_page How many objects are displayed "on the page", that is, returned from the server in response to one request.
  • page The current page, in other words, a portion of objects.


page and per_page are also request parameters. per_page defaults to 100 and this is its maximum value. You can select any value between 10 and 100 . page defaults to 1 , and is incremented to get the next page of results.

view GET /api/resource/id

Get one object with the given ID. Usually contains more complete information than in the action list. list.

The returned object will be in the object field of the response.

update POST /api/resource/id

Edit an object with the given ID. In the request body, it is necessary to pass the fields of the object that should be changed, and their new values.

If successful, the updated response field will contain the ID of the edited object.

create POST /api/resource/

Create a new object. In the request body, it is necessary to pass the fields of the new object, and their values.

If successful, the response field created will contain the ID of the created object.

Also, the response status code for this request, if successful, will be 201 , and not 200, like all other methods.


DELETE /api/resource/id или

POST /api/resource/del/id

Delete object. For compatibility with some types of proxy servers, an alternative url with the POST method is supported.

If successful, the response field deleted will contain the ID of the deleted object.

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:

Code Decryption Is used for
200 OK Request completed successfully
201 Created Object created
400 Bad Request Error in request parameters
401 Unauthorized Authorization error (API key is invalid)
403 Forbidden You do not have permission to execute this method on this resource
404 Not found Object not found
405 Method not allowed This resource does not support the required method.
500 Internal server error Mistake on our part
501 Not implemented The method has not yet been implemented, but will be available soon