Skip to main content
Configure event sources on a seller account for conversion tracking. Sources can be buyer-managed integrations such as website pixels, mobile SDKs, server-to-server feeds, and CRM imports, or seller- and platform-native owned properties such as channels, profiles, feeds, podcasts, and newsletter lists. Supports upsert semantics, seller-managed sources, and setup instructions. Response Time: ~1s (synchronous configuration) Request Schema: /schemas/v3/media-buy/sync-event-sources-request.json Response Schema: /schemas/v3/media-buy/sync-event-sources-response.json

Quick Start

Configure an event source for purchase tracking:

Request Parameters

Event Source Object

Response

Success Response:
  • event_sources - Results for each event source, including both synced and seller-managed sources on the account
Error Response:
  • errors - Array of operation-level errors (auth failure, account not found)
Note: Responses use discriminated unions - you get either success fields OR errors, never both. Each event source in success response includes:
  • All request fields
  • seller_id - Seller-assigned identifier for this event source
  • action - What happened: created, updated, unchanged, deleted, failed
  • action_source - Type of event source (website pixel, app SDK, etc.)
  • surface - Structured surface this source represents, when the flat action_source is too coarse
  • managed_by - Who manages this source: buyer or seller
  • setup - Implementation details (snippet, instructions)
  • health - Event source health assessment (when seller supports health scoring)
  • errors - Per-source errors (only when action: "failed")
  • ext - Per-source extension metadata, such as platform-native conversion IDs, attribution-window handles, or raw origin strings
See schema for complete field list: sync-event-sources-response.json

Event Source Health

Sellers that evaluate event source quality include a health object on each source in the response. This is analogous to Snap’s Event Quality Score or Meta’s Event Match Quality — it tells the buyer whether their event integration is working well enough for optimization.
test=false
Buyer agents should key decisions off status, not detail.score. The four-tier status is comparable across all sellers — a buyer agent writes one rule (“require good or better for DR products”) that works everywhere. The detail object is for human dashboards or advanced diagnostics. Buyer agents can use health data to:
  • Gate product selection on event quality (e.g., require good or better for DR products)
  • Surface setup issues to the buyer before campaign launch
  • Prioritize which event sources to fix first

Common Scenarios

Discovery Only

Discover all event sources on an account (including seller-managed sources) without making changes. Useful for platform-managed conversion tracking where the seller provides always-on attribution:

Multiple Event Sources

Configure separate sources for website and app:

Discovering Seller-Managed Sources

Sellers may provide always-on event sources (e.g. Amazon sales attribution). These appear in the response with managed_by: "seller" alongside your buyer-managed sources:
test=false
Products with conversion_tracking.platform_managed: true indicate the seller provides these sources.

Creator and Owned-Property Sources

Seller-managed creator or owned-property sources use the same event_sources array, with a flat action_source for compatibility and surface for structured context:
test=false
Use follow for free durable opt-ins to a channel, profile, feed, list, or podcast. Use subscribe only for paid subscriptions or paid memberships.

Clean Sync with delete_missing

Replace all buyer-managed event sources on the account:

Setup Instructions

The response includes setup details for each event source. The setup object tells you how to activate the source:

Error Handling

Best Practices

  1. Sync before logging - Always configure event sources before sending events via log_event. Events sent to unconfigured sources will be rejected.
  2. Use descriptive IDs - Choose event_source_id values that are meaningful (e.g. web_pixel, app_sdk, crm_import) rather than opaque identifiers.
  3. Specify event_types - Restrict each source to relevant event types for better validation and debugging.
  4. Check seller capabilities - Use get_adcp_capabilities to discover supported event types, UID types, and action sources before configuring event sources.
  5. Install setup snippets - When the response includes setup instructions, install the provided snippet before logging events. Server-only sources (snippet_type: "server_only") skip this step.
  6. Handle seller-managed sources - The response may include sources with managed_by: "seller" that you didn’t configure. These are always-on and provide additional attribution data.

Next Steps