API Usage Constraints
On This Page
Input and Output Throttling
To ensure good performance, all accounts are limited to 100 reads per minute and 60 writes per minute. This limit is enforced programmatically by the API on a member level. That means if there are two API users for a single member, they will share the throttling limit (i.e., two users can average 50 read per minute each, four users can average 25 reads per minute each). If you require more reads or writes per minute, please reach out to your Xandr account representative.
Every response from the API will contain a dbg parameter, which contains information about the API call and response. Below is an example of this debug output as well as the definitions of the fields.
Debug Field Definitions
Field | Type | Description |
|---|---|---|
instance | string | The API machine which processed the request. |
slave_hit | boolean | Whether or not the API machine ran SQL queries on a database slave. |
db | string | The database the query was executed on. |
reads | int | The number of reads made. |
read_limit | int | The limit on the number of reads. |
read_limit_seconds | int | The time period over which the read_limit is enforced. |
writes | int | The number of writes made. |
write_limit | int | The limit on the number of writes. |
write_limit_seconds | int | The time period over which the write_limit is enforced. |
time | double | The amount of time it took to process the API request, expressed in milliseconds. |
start_microtime | double | The UNIX timestamp of the start time of processing, including milliseconds (listed on the right side of the decimal point). |
version | string | The version of the API. |
Pagination
The maximum number of objects that can be returned in a given GET response is 100. To retrieve more than 100 objects, you can paginate results by specifying start_element and num_elements in the query string of the GET request. For example, the following request would return the first 50 objects in the response:
To retrieve the next 50, you would simply set start_element=50.
- The first element is element 0.
- All GET responses will have a "count" property showing the total number of elements matching that GET request.
- This will also apply to non-reporting services, such as the creative search service, that are requested with methods other than GETs.
Examples
Authentication Frequency
After authenticating, your token remains valid for 2 hours. You do not need to re-authenticate within this time. If you do re-authenticate, please note the following limitation: The API permits you to authenticate successfully 10 times per 5-minute period. Any subsequent authentication attempts within those 5 minutes will result in an error.
It is best practice to listen for the "NOAUTH" error_id in your call responses and re-authenticate only after receiving it.
Object Limits
Xandr limits the number of non-expired creatives that you can have on the platform. In addition, Xandr limits the number of domains that can be used in a single domain list and the number of certain targets that can be used in a single profile. For all object types except creatives, both active and inactive objects are counted against the limit. For creatives, only non-expired objects are counted against the limit. A creative expires when it has neither served nor been modified in 45 days.
You can use the Object Limit Service to view your limits and proactively monitor your usage. Also, for frequently asked questions about object limits, see Object Limits - FAQ.