Data Insertion API response types

The response type is the numeric segment of the endpoint path (the /1/ in /b/ss/examplersid/1/s234234238479). It selects the format of the server's response: a GIF, 204 No Content, JavaScript, JSON, XML, and so on. The response format is independent of how you send the request, with one exception: an XML request body is parsed only at the /6/ response type (see XML).

Every response type technically accepts both GET and POST; however, several response types would not make sense in practice. The type you choose does not change whether a valid hit is recorded; it changes only the response you receive and, for some types, how a validation failure is surfaced.

Response types

data-slots=heading, text

/0/: HTML

Returns a single space with a text/html content type, and 200 OK. On a failed hit it sets a Status: FAILURE header (with a Reason header when a reason is available), and it flags failure even when no hit is recorded, so it surfaces a dropped GET.
data-slots=heading, text

/1/: GIF (default)

Returns a 1x1 transparent GIF (image/gif), and 200 OK. Use this response type for <img> tag requests. AppMeasurement primarily uses this response type for both GET and POST requests. On POST validation failures it sets Status and Reason headers; GET validation surfaces Nothing, even when the hit is dropped.
data-slots=heading, text

/2/: No content

Returns 204 No Content with no body. It sets a Status header (SUCCESS or FAILURE) on any method, plus a Reason header when a reason is available (the most reliable lightweight signal).
data-slots=heading, text, code

/3/: JavaScript

Returns a JavaScript response that assigns the visitor ID to a s_vid variable, so a browser can read the ID back after the beacon fires. This ID is the visitor's s_vi cookie value (the aid variable). On a POST validation failure it sets Status and Reason headers.
var s_vid='355231C82E332200-4000195842CEFA67'

data-slots=heading, text

/4/: Partner redirect

Used by select partner libraries, and only on a GET. Do not set it manually.
data-slots=heading, text

/5/: WBMP

An image/wbmp image, equivalent to /1/ (GIF) for legacy wbmp-only clients. It does not surface a status or reason.
data-slots=heading, text, code

/6/: XML

Returns an XML body with the hit status. This response type exclusively parses an XML request body (see XML); it also mirrors the status and reason into Status/Reason headers, except for a NO account failure, which appears only in the body.
<?xml version="1.0" encoding="UTF-8"?>
<status>SUCCESS</status>

data-slots=heading, text, code, text

/10/: Visitor JSON

Returns the hit status and visitor ID as JSON. When an Experience Cloud ID (mid) is available for the visitor, the response includes additional visitor information as well. AppMeasurement uses this response type when Audience Manager is included in your implementation.
{"status":"SUCCESS","id":"355231C82E332200-4000195842CEFA67"}
The id is the visitor's s_vi cookie value (the aid variable). Status appears in the JSON body, not in headers; a hit that fails validation returns without an id.
data-slots=heading, text, code, text

/11/: Visitor XML

The same visitor information as /10/, returned as XML.
<?xml version="1.0" encoding="UTF-8"?>
<visitor>
  <status>SUCCESS</status>
  <id>355231C82E332200-4000195842CEFA67</id>
</visitor>
The id is the visitor's s_vi cookie value (the aid variable). Status appears in the <visitor> body, not in headers; a hit that fails validation returns an empty <visitor> element. Reading it back is the basis of the server-side identity pattern in Visitor identification using the Data Insertion API.

Validation and failures

Whatever the response type, a 2xx status confirms only that the request was received, not that the hit passed validation or appeared in reporting. How a failure is surfaced depends on the HTTP method and the response type: a failure reason is computed only for POST requests, so GET responses never return one. The surest confirmation is to inspect the request with a packet monitor as you send it, or to check for the data in Adobe Analytics reporting.

A failed hit reports one of the following reasons. The same reason string appears wherever the response type surfaces it; a Reason header, the <reason> XML element, or the JSON body.

Reason
Meaning
NO account
Missing the required report suite ID.
NO pagename OR pageurl
Missing the required page name or page URL.
NO visitorid OR ipaddress
Missing the required visitor identifier.
Syntax error
Malformed XML, or a reserved character that was not encoded.

Statuses and reasons by response type

The reason value is the same everywhere; only the container differs by response type and HTTP method. A reason is computed only for POST requests, so every GET cell below is either Nothing or a bare Status.

Response type
On GET
On POST
Notes
/0/ HTML
Status header
Status + Reason headers
Failure only; also flags a dropped hit.
/1/ GIF
Nothing
Status + Reason headers
Failure only.
/2/ No content
Status header
Status + Reason headers
SUCCESS or FAILURE; also flags a dropped hit.
/3/ JavaScript
Nothing
Status + Reason headers
Failure only.
/4/ Partner redirect
Nothing
N/A
Partner use only; don't set manually.
/5/ WBMP
Nothing
Nothing
Surfaces nothing.
/6/ XML
N/A
<status>/<reason> body + headers
Header suppressed for NO account (still in the body).
/10/ Visitor JSON
status in body
status in body
No headers; no id on failure.
/11/ Visitor XML
<status> in body
<status> in body
No headers; empty <visitor> on failure.

Resolving failures

If hits return FAILURE, check the following:

POST request rejected

Some HTTP clients add an Expect: 100-Continue header to POST requests, which Adobe data collection servers reject. The request fails before the body is processed, so no FAILURE body is returned. Disable the header in your client. For example, in .NET, set ServicePointManager.Expect100Continue = false.