This page explains how to work with our Impression Bus REST API. It includes information on:
- How to authenticate
- How to ask a service about itself: what fields it supports, which can be used to filter
- Response codes and errors
For more information about how to work with specific API services, see the links at API Services.
The AppNexus Impression Bus API supports HTTP Protocol version 1.1 or later. While some calls may work with the deprecated 1.0 version, this is not guaranteed. Please ensure that your client communicates using at least version 1.1.
We recommend always using the secure endpoint (
Sandbox mirrors Production
This Sandbox environment replicates the Production codebase and is kept up to date on a monthly or shorter release schedule. The environment is made available expressly for clients to test their integrations without having to interfere with Production data.
AppNexus API services are "RESTful." REST (Representational State Transfer) is a type of software architecture in which requests model the communication from a web browser to a web server. Below are the central REST methods used in the AppNexus API Services and their uses:
In our documentation we use curl to make REST requests. Curl is a command line tool for transferring files with URL syntax, supporting FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS and FILE. The example scripts on each API wiki page will make clear the structure of the curl commands you will need to run AppNexus API Services.
PUT requests, only the fields included in the JSON file will be updated, except in the case of arrays.
When updating an array using
PUT, all fields in the array are overwritten with the contents of the new array you upload, unless you add this to your request's query string:
All Bidder Services support meta calls, which will return the service's fields and the value type. Meta calls look like this:
For example (partial output of a meta call):
Limiting GET Request Records
Adding this string to the end of any GET request to the API will limit the number of records retrieved:
The maximum number of elements that can be returned regardless of your request is 100.
- 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.
Filtering and Sorting
Most API Services support filtering and sorting. Filtering allows you to specify a subset of objects to be returned. Sorting allows you to control the order of the objects returned.
Get multiple objects by ID
You can get multiple specific objects by ID by passing a comma-separated list of IDs. The result object will contain an array holding just those specific objects. In the example below, we ask the Creative Service for just the creatives with IDs 1, 2, and 3.
Filter by IDs
Pass a query string parameter for the field with a comma-separated list of IDs.
Example: Request all creatives for certain members.
Only 100 objects will be returned per request
The maximum number of objects that can be returned, regardless of pagination, is 100. If you request over 100 objects, we will only return the first 100 and will not provide an error message.
Filter by Min and Max Values
Fields that are of the type
money can be filtered by
max. For example:
Fields of the type
date can be filtered using the
min_last_modified filter. Note the required date/time syntax: YYYY-MM-DD+HH:MM:SS
Filter by field names
To limit the response to specific fields of an object, pass the
fields query string parameter with a comma-separated list of field names. For example:
Misc Filters on Field
We support the following additional field-based filters on API responses:
JSON Field Values
POST and PUT requests require JSON-formatted data. POST request generally create objects in the database, and thus require all of the information about that object (unless it is subsequently modified by a PUT request). For PUT requests, only the JSON fields included in a request will be updated. All other fields will be unchanged.
Different fields require different types of values.
String of 100 characters or less
Positive integers only
Floating point number
Floating point number with twice the bit space of a float.
One element from an array of preassigned values only
Date and time string in the form YYYY-MM-DD HH:MM:SS
More than one value allowed
Before you can use the APIs, you must authenticate yourself with your username and password. Please see Authentication Service for details.
All API Services return JSON-formatted data. When Service calls are successful, the JSON response will include a "status" field set to "OK". The response to POST and PUT calls will also include the ID of the relevant object, such as bidder, member, tag, or creative, as well as any relevant attributes of that object. (In the example below we are using cookies to store our authentication token and adding the file "tag" to the Tiny Tag Service.)
When invalid input is sent to the API - for example, an incorrect password - a JSON response will be returned with "error" and "error_id" fields. For some error conditions you may also see the optional "error_description" and "error_code" fields.
The "error" field is useful for debugging purposes, as it contains a verbose description of the error. The "error_id" field can be used programmatically as follows.
Authentication information is either missing or invalid
Use /auth to get a valid token
The user is not authorized to take the requested action
Check 'error' message and make sure logic is correct in code
The syntax of the request is incorrect
Use the 'error' message to identify the issue and fix the code
A system error has occurred
A client request is inconsistent; for example, an attempt to delete a default creative attached to an active TinyTag
Check the request for integrity