Skip to main content
This page covers the error responses of the Context Targeting API, how bulk requests report results, how to retry safely, and the limits that apply to requests.

Error Responses

A failed request returns an HTTP error status and a JSON body in one of the forms below. Handle errors by the HTTP status and errorCode, not by the message text.

Validation Errors

The request was rejected before processing. A field is missing or invalid, a name or Context ID breaks the rules, the request has an unknown field (such as _id in a create request), or a per-request limit is exceeded. Nothing in the request is applied, including bulk requests. message is an array that lists every problem found.
When an ID in the path isn’t a valid ULID, or the body isn’t valid JSON, message is a single string.

Business Errors

The request is well-formed, but the server can’t process it. For example, the name is already in use, or the targeting doesn’t exist. This is the response when you create a targeting with a name that another context targeting already uses:
A single-item endpoint returns the error of its item as the response. If the item fails because of an unexpected error, the endpoint returns 502 instead. Bulk endpoints report errors per item in results. See Bulk Responses.

Authentication and Permission Errors

401 means the x-api-key header is missing, or the key is invalid or revoked. 403 means the key doesn’t have the scope that the endpoint requires.

Request Body Too Large

413 means the request body is larger than 8 MB. Nothing is applied.

Server Errors

502 means the request couldn’t be completed because of a temporary server problem, and 500 means an unexpected server error. In both cases, the request may or may not have been applied. The message text can vary. See Retries and Duplicate Requests.

Error Codes

Errors by Status

These errors have no errorCode.

Errors by Code

TARGETING_CATEGORY_NOT_SUPPORTED occurs in these cases:
  • An option group has neither sub-options nor Context IDs of its own.
  • children is sent with type: "atomic", or exposeChildren is sent for a regular option.
  • When you add an option, parent is sent together with type: "collection", children, or exposeChildren.
  • parent points to an option that isn’t a top-level option group.
  • An update sends parent for an option group. Option groups can’t be moved.
  • A move, detach, or delete would remove the last sub-option of an option group that has no Context IDs of its own.
  • An update would remove every Context ID of an option group that has no sub-options.
  • The parent query parameter of List Options points to a regular option.
  • The option is stored in a form that the API can’t change, such as an option group inside another option group.

Detail Fields


Bulk Responses

Bulk endpoints, such as POST /context-targeting/bulk/create and POST /context-targeting/category/bulk/update, return a result for each item.

Response Fields

Response Status

When a bulk request is processed, it returns 200, even if some or all items fail. Check failed, or success of each item. In these cases, the whole request fails without results, and nothing in it is applied:
  • 400 validation error. For example, the request has too many items, more than 10,000 Context IDs in total, or the same _id twice in an option bulk update.
  • 400 TARGETING_CATEGORY_TREE_ITEMS_LIMIT_EXCEEDED in an option bulk delete
  • 401, 403, or 413
  • 404 PROJECT_NOT_FOUND
  • 409 CONTEXT_TARGETING_WRITE_IN_PROGRESS
A 500 or 502 response also comes without results, but the request may or may not have been applied.

How Items Are Applied

  • An option bulk update applies items concurrently, but results stay in request order. Put all changes to one option in a single item. The same _id twice rejects the whole request.
  • A later item in a rename or update request can use a name that an earlier item frees by renaming. If the earlier item fails, the later item fails with a name duplicate error.

Example

The first item adds a Context ID to Sports. The second item tries to rename Tech to Sports, which is already in use.
The response status is 200.

Concurrent Writes

API writes for a project are processed one at a time. This covers every POST, PATCH, and DELETE request of the Context Targeting API, single-item and bulk, from any API key of the project. GET requests aren’t affected, and writes for different projects don’t wait for each other. When a write arrives while another write for the project is in progress, the server waits briefly for it to finish. If it’s still running, the request fails with 409 CONTEXT_TARGETING_WRITE_IN_PROGRESS, and nothing in the request is applied. A bulk request fails as a whole, without results.
To handle this error:
  1. Wait detail.retryAfterMs milliseconds. The value is between 0 and 2,000.
  2. Send the same request again. If you get 409 again, repeat.
Send writes for a project in order: wait for the response to one request before you send the next. If several processes or workers write to the same project, each one should retry on 409.
In rare cases, a request that runs unusually long is taken over by another request. Items that the first request hadn’t applied fail with the same 409 in results, or as the response of a single-item endpoint. Items with this error weren’t applied, so send only those items again.

Retries and Duplicate Requests

If a request times out or returns 502 or another 5xx status, you may not know whether it was applied. The server may still be processing the original request. Wait a moment, then send the same request again. If the original request is still in progress, the resend fails with 409 CONTEXT_TARGETING_WRITE_IN_PROGRESS. Wait and send it again. What happens when you resend a request that had already succeeded depends on the operation.

Resending a Create

The server always generates IDs, and _id in a create request fails with 400. If you resend a create that had already succeeded, use the IDs in the 409 response instead of creating the item again.
  • Targeting: 409 TARGETING_NAME_DUPLICATE. detail.existingId is the ID of the targeting. To get the IDs of its options, see Get a Targeting.
  • Option: 409 TARGETING_CATEGORY_NAME_DUPLICATE. detail.existingIds has the IDs of the options with that name.
  • In a bulk create, only the items that the original request created fail this way. The other items are processed as usual.
detail.existingId is included only when the existing targeting is a context targeting. If an audience targeting uses the name, choose another name. A name that repeats within the same request returns detail.duplicateOfIndex instead. Fix the request in that case. Because API writes for a project are processed one at a time, two identical create requests sent at the same time don’t both create. The later one fails with a name duplicate error or with 409 CONTEXT_TARGETING_WRITE_IN_PROGRESS.

After a 500 or 502

  • 500 UNCATCHED in the results of a create or delete bulk request: nothing in the request was applied. Send the same request again.
  • 500 UNCATCHED in the results of an update bulk request: that item failed. Send it again.
  • A 500 or 502 response: the request may or may not have been applied. Send the same request again, and handle the result as shown in the table above.
If an option update has both add and remove and fails, the add may already be applied. Sending the same update again is safe.

Limits

  • Limits on stored data (per option, per project, per targeting, and per ad product) are checked only when a change increases the amount. Changes that reduce it, such as removing Context IDs, aren’t blocked even if the data is already over a limit.
  • To upload more than one request can hold, split it into requests within these limits, and send them one after another. For example, add tens of thousands of options with option bulk add requests of up to 5,000 items each.
  • To replace the Context IDs of an option that has more than 10,000, see Updating Context IDs.
  • Send non-ASCII text, such as Korean names and Context IDs, as raw UTF-8 to keep the request body small.

Name Rules

Targeting and option names, including option groups and sub-options, follow these rules.
  • Other characters aren’t allowed, such as Japanese or Chinese characters, _, ., and brackets.
  • Names that repeat within one request are also duplicates. See duplicateOfIndex in Detail Fields.
  • Renaming to the current name isn’t an error.
  • Options in different targetings can have the same name.

Using the API with the Console

  • Same data: The console and the API manage the same context targetings. Targetings and options that you create with the API appear in the console, and the API returns those created in the console.
  • Context targetings only: Requests for an audience targeting fail with 404 TARGETING_NOT_FOUND, and requests for its options fail with 404 TARGETING_CATEGORY_NOT_FOUND. Audience targeting names still count for name uniqueness, so creating a context targeting with the same name fails with 409 TARGETING_NAME_DUPLICATE without detail.existingId.
  • No write ordering for console edits: The one-at-a-time processing applies only to API writes. A console edit doesn’t wait for an API write and doesn’t cause 409 CONTEXT_TARGETING_WRITE_IN_PROGRESS, and an API write doesn’t wait for a console edit.
  • Simultaneous changes can conflict: When the console and the API change the same targeting at the same time, a change saved later can overwrite an earlier one, and two targetings or options can end up with the same name. Don’t edit a targeting in the console while your integration writes to it. If it may have been changed in the console, get it again before you write.
  • Duplicate names: If two targetings or options end up with the same name, rename or delete one of them. Before you delete an option, check Effects on Ad Products and Campaigns.
  • Ad product settings: To change which options an ad product sets as Required Include or Required Exclude, use the console. See Selling Targeting.