Skip to main content
The Context Targeting API lets you manage context targeting from your server. Map the sections, boards, or tags in your CMS to targeting options and Context IDs, and update them automatically as your content changes instead of editing them by hand in the console. The API works on the same data as context targeting in the console. Targetings you create with the API appear in the console, and the API can read targetings created in the console.

Prerequisites

  • An API key with both the context-targeting:read and context-targeting:write scopes. A project owner creates the key in [Settings] > [Integrations] and selects both scopes. See Integrations & API Keys for how to create a key.
  • You can’t change the scopes of an existing key. If your current key doesn’t have both scopes, create a new key, and revoke the old one if you no longer need it.
Grant both scopes, even if you mostly write. Each endpoint checks a single scope, and context-targeting:write doesn’t include context-targeting:read. A key with only the write scope gets 403 on every GET request, so it can’t look up IDs, read the current Context IDs, or check whether a change has been loaded.
Call the API only from your server. Don’t include the API key in apps or web pages.

Basic Information

For all request limits, see Limits.

Terms

Some API paths and fields use different names from the console. These docs use the console’s terms.

Endpoints

Paths are relative to the base URL. Each endpoint requires the scope shown. Bulk endpoints return a result for each item. See Bulk Responses.

Quick Start

This example creates a “News Sections” targeting, changes the Context IDs of one option, and checks when the change has been loaded.
1

Create a targeting with options

Create the targeting and its options in one request.
The response is 201 with the new targeting. Save the _id of the targeting and of each option. You need them to change the targeting later.
Creating isn’t idempotent. If a create request times out, see Retries and Duplicate Requests before you send it again.
2

Add and remove Context IDs

When your sections change, update the Context IDs of the option. add and remove change only the IDs you list.
The response is 200 with the updated option.
To replace all Context IDs of an option at once, see Updating Context IDs.
3

Check that the change has been loaded

Read the targeting and compare its syncedAt with the time your update succeeded.
The update in the previous step succeeded at 2026-10-13T01:30:00.000Z (1791855000000). syncedAt is later than that, so the change has been loaded, and ad serving picks it up within a few more minutes. If syncedAt is missing or earlier, read the targeting again after a short wait. See When Changes Take Effect.
4

Send Context IDs in ad requests

Send the Context ID of the page a user is viewing as contextId in your ad requests. After the change takes effect, an ad request with contextId set to basketball matches the “Sports” option.See Creating Context Targeting for how Context IDs work in ad requests.

When Changes Take Effect

A successful write is saved right away. Adrop then loads the project’s context targetings into ad serving, and the change usually reaches ad serving within a few minutes. Use the syncedAt field of a targeting (epoch milliseconds) to check whether a change has been loaded.
  • syncedAt is the time the most recent load of the targeting started. A change that succeeded at or before syncedAt has been loaded, and ad serving picks it up within a few more minutes.
  • syncedAt is omitted for a new targeting. It’s also omitted after you change Context IDs (add, remove, or set), add an option, or move or detach an option. It usually comes back when the next load finishes.
  • A load that was already running when you made a change can set syncedAt to that load’s start time, which is earlier than your change. That load may not include your change, but a later load does.
  • Renaming or deleting doesn’t clear syncedAt.
So don’t decide based on whether syncedAt is present. Record the time your request succeeded, then read the targeting that contains the change, for example with Get a Targeting and includeCategories=false. The change has been loaded when syncedAt is equal to or later than that time. syncedAt uses Adrop’s server clock, so allow a margin if your clock may differ.
Until a change takes effect, ad requests are matched against the previous Context IDs. Add a new Context ID before your app or website starts sending it in ad requests.

Targetings

List, create, rename, and delete targetings

Targeting Options

Add options and keep their Context IDs up to date

Option groups

Group options into an option group with sub-options

Errors and Limits

Error codes, limits, and how to retry

Integrations & API Keys

Create and manage API keys

Creating Context Targeting

How context targeting and Context IDs work

Selling Targeting

Connect targetings to ad products and sell them to advertisers