API Semantics

This page explains the semantics of our REST API. It includes information on:

• How to ask a service about itself: what fields it supports, which fields are filterable
• How to get only the information you want by filtering and sorting
• The "shape" of our JSON responses in different scenarios

This document assumes you have completed the API Onboarding Process.

HTTP Protocol

The AppNexus 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.

API Endpoints

The URL for the production API endpoint is: https://api.appnexus.com. Please note that non-secure access to the product API (HTTP) is not available.

Changes made with this API affect the production AppNexus Console. Only authorized users should alter information or settings in this environment.

The URL for the testing API endpoint is: https://api-test.appnexus.com.

This 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.

REST Semantics

Our 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 our API services, and their uses:

When making a POST or PUT request, you must include a JSON file with the data to create or update.

Using cURL

In our documentation we use curl to make HTTP 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 more. Example scripts have been provided on each API wiki page to illustrate the structure of the curl commands you will need to run AppNexus API services. In addition, an example of how to a make a generic POST request is shown below. This example uses the Authentication Service:

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 Campaign Service for just the campaigns 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 campaigns for certain line items.

Example: Request certain advertisers

Filter by Min and Max Values

Fields that are of the type int, double, date, or money can be filtered by min and max. For example:

Fields of the type date can be filtered by nmin and nmax as well. The nmin filter lets you find dates that are either null or after the specified date, and the nmax filter lets you find dates that are either null or before the specified date. For example:

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:

• not_*
• like_*
• min_*
• max_*
• nmin_*
• nmax_*
• having_*
• having_min_*
• having_max_*

Example:

Search

Some services support search as a query string parameter to look for ID or name. For example:

Sorting

To sort use the sort query string parameter and pass in a list of fields you'd like to sort by and whether you want them ascending (asc) or descending (desc). For example:

Paging

To page, use the start_element and num_elements parameters.

Append-only PUT

By including append=true in the query string of a PUT call, a user can update only a particular child object instead of replacing all child objects. In other words, rather than overwriting an entire array with a new one on a PUT call, you can use append=true on the query string to add a single element to a long array.

In this example, we'll use append=true on a PUT call to toggle the is_available flag of an object in the member_availabilities array of the Plugin Service. Without the append=true flag on the query string, the new item would replace the entire array. In this example, it's only added.

First let's look at the object we'll be modifying (these examples use jq to slice and dice the JSON). Both of the availabilities are set to true:

We'll send the following JSON to turn off the is_available flag on one of the member_availability objects:

Normally, sending the JSON above on a PUT call would overwrite the whole member_availabilities array. However, this time we'll add "append=true" to the query string of the call. This tells the API to change just the object whose id is 4. We can verify that it's done so by inspecting the output.

Meta: What Fields Are Available

In almost all services you can add /meta to the end of the URL and get a list of the fields included in the service. You will also see the "type", such as "int", and whether or not you can sort and filter by that field. For example:

JSON Basic Structure

Below are the syntax of the components of a JSON object and what they mean.

An object:

An array:

A string:

Associate a key with an alphanumeric string value:

Associate a key with a numeric value:

An example that puts them together:

JSON Field Types

POST and PUT requests require JSON data. 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. The table of types below extends those defined in the JSON standard.

How and Why Reporting APIs are Different

The reporting APIs available via the Report Service work differently than our other APIs. They have their own multi-step request and response flow. This is required because they process large amounts of data; this processing needs to be performed asynchronously.

For instructions on how to retrieve reports, see the Report Service.

For a tutorial that explains how to use our reporting APIs effectively, see Report Pagination.

A Note on Underscores and Hyphens

JSON fields and values use underscores, e.g., audit_type_direct.

API service names in URLs are hyphenated, e.g., https://api.appnexus.com/insertion-order.

Response Codes

All API Services return JSON 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, as well as any relevant attributes of that object. Every response will include a "dbg_info" object that conveys information about the API call and response, such as the API machine that processed the request and the version of the API you're using.

In the example below, we are using cookies to store our authentication token and adding the file "creative" to advertiser 123 with the Creative Service.

The table below lists the fields of the dbg_info object and their definitions:

Error Messages

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.

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 described in the table below.

Related Topics

• API Usage Constraints
• API Best Practices