Target Admin API Overview

This article provides an overview of background information necessary to understand and use Adobe Target Admin APIs successfully. The following content assumes you understand how to configure authentication for Adobe Target Admin APIs.

Before You Begin

In all code examples provided for the Admin APIs, replace {tenant} with your tenant value, your-bearer-token with the access token that you generate with your JWT and your-api-key with your API key from the Adobe Developer Console. For more information on tenants and JWTs, please see the article on how to configure authentication for Adobe Target Admin APIs.

Versioning

All APIs have an associated version. It is important to provide the right version of the API you want to use.

If the request contains a payload (POST or PUT), the Content-Type header of the request is used to specify the version.

If the request does not contain a payload (GET, DELETE or OPTIONS), the Accept header is used to specify the version.

If a version is not provided, the call will default to V1 (application/vnd.adobe.target.v1+json).

Error Message for unsupported features

{
    "httpStatus": 406,
    "requestId": "8752b736-cf71-4d81-86c3-94be2b5ae648",
    "requestTime": "2018-02-02T21:39:06.405Z",
    "errors": [
        {
            "errorCode": "Unsupported.Feature",
            "message": "Unsupported features detected"
        }
    ]
}

Admin Postman Collection

Postman is an application that makes it easy to fire API calls. This Target Admin API Postman Collection contains all Target Admin API calls that require authentication using Activities, Audiences, Offers, Reports, Mboxes, and Environments

Response Codes

Here are the common response codes for the Target Admin APIs.

Activities

An activity enables you to test or personalize content for your users. Activities may be one of the following types:

Batch Updates

Multiple Admin APIs can be executed as a single batch request.

Execute Calls in Batch

POST /{tenant}/target/batch

Stack multiple API calls together and execute them in a single batch.

Batching allows you to pass instructions for several operations in a single HTTP request. You can also specify dependencies between related operations (described in a section below). TNT will process each of your independent operations (possibly in parallel) and will process your dependent operations sequentially. Once all operations have been completed, a consolidated response will be passed back and the HTTP connection will be closed.

The batch API takes in an array of logical HTTP requests represented as JSON arrays - each request has a method (corresponding to HTTP method GET/PUT/POST/DELETE etc.), a relativeUrl (the portion of the URL after admin/rest/), optional headers array (corresponding to HTTP headers) and an optional body (for POST and PUT requests). The Batch API returns an array of logical HTTP responses represented as JSON arrays - each response has a status code, an optional headers array and an optional body (which is a JSON encoded string). To make batched requests build a JSON object which describes each individual operation to perform. The number of maximum allowed operations are 256 (from 0 to 255).

Specifying dependencies between operations in the request By default, the operations specified in the batch API request are independent - they can be executed in arbitrary order on the server and an error in one operation does not affect execution of other operations.

Often, the operations in the request are dependent - for example, the output of one operation may be used in the input of the next operation. For example offer created in operationId=0 needs to be used in campaign creation operationId=1.

In order to link two batch operations together specify in the dependent operation the id of the required operation, for instance: “dependsOnOperationId” : 5. Also IDs of created resources via POST requests of batch operations can be used in dependent operations both in “relativeUrl” and “body”.

Permissions & Throttling

In order to execute batch API actions the underlying user has to have at least “editor” rights (for each individual operation in case additional rights are required than user has then the individual operation will fail). Usual throttling strategies are applied on batch API actions as if every operation has been performed individually.

Batch processing finishes when all operations have been completed, an operation could either be successful (2xx statusCode), failure (4xx, 5xx status code) or skipped because a dependency operation has failed or has been skipped.

Request Object Parameters

Sample Request Object

{
  "operations": [
    {
      "operationId": 1,
      "dependsOnOperationIds~": [0],
      "method": "POST",
      "relativeUrl": "/v1/offers",
      "headers~": [
        {
          "name": "Content-Type",
          "value": "application/json"
        }
      ],
      "body~": {
        "key": "value"
      }
    }
  ]
}

Response Object Parameters

Sample Response Object

{
  "results": [
    {
      "operationId": 1,
      "skipped~": false,
      "statusCode~": 200,
      "headers~": [
        {
          "name": "Content-Type",
          "value": "application/json; charset=UTF-8"
        }
      ],
      "body~": {
        "id": 5
      }
    }
  ]
}