Skip to main content
Manage first-party CRM audiences on a seller account. Upload hashed customer lists, check matching status, and reference the resulting audiences in create_media_buy targeting overlays for explicit retargeting or suppression. Audiences are distinct from signals: signals are third-party data products you discover and activate; audiences are data you own and upload. Use audience_include to target only members of an uploaded list. audience_include is a hard constraint — only users on the list are eligible. To find new users similar to an audience (lookalike expansion), describe that intent in your campaign brief — the seller handles expansion strategy. Note: lookalike intent expressed in the brief cannot be verified through the protocol; confirm via seller-side reporting. Response Time: Upload accepted in ~1–2s. The task remains active until matching completes (1–48 hours depending on the seller). Configure push_notification_config to receive a webhook when the audience is ready. Request Schema: /schemas/3.0.19/media-buy/sync-audiences-request.json Response Schema: /schemas/3.0.19/media-buy/sync-audiences-response.json

Quick Start

Upload a customer list and check its status:

Request Parameters

Audience Object

Audience Member

Every member requires an external_id (buyer-assigned stable identifier) plus at least one matchable identifier. Hash all values with SHA-256 before sending — normalize emails to lowercase+trim, phone numbers to E.164 format (e.g. +12065551234). Providing multiple identifiers for the same person improves match rates. Composite identifiers (e.g. hashed first name + last name + zip) are not yet standardized — use ext for platform-specific extensions. Identifier support varies by seller: Check get_adcp_capabilitiesmedia_buy.audience_targeting.supported_identifier_types and media_buy.audience_targeting.supported_uid_types before sending. MAID support is not universal (LinkedIn does not accept MAIDs; iOS IDFA requires App Tracking Transparency consent). The media_buy.audience_targeting.matching_latency_hours range and media_buy.audience_targeting.minimum_audience_size in capabilities are also seller-specific. Size limit: Payloads are limited to 100,000 members per call across all audiences. For larger lists, chunk into sequential calls using add deltas. Concurrency: Ensure that calls made to sync_audience are independent of eachother. They may be processed out-of-order. If you need sequential execution, wait for the callback to your configured webhook before making another call.

Response

Success Response:
  • audiences — Results for each audience on the account, including audiences not in this request
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 audience in success response includes:

Match breakdown

When a seller supports per-identifier-type reporting, the response includes match_breakdown — an array showing which identity types are resolving and at what rate. This helps buyers decide which identifiers to prioritize in future uploads.
Key semantics:
  • submitted and matched are cumulative across all syncs, matching total_uploaded_count semantics (not uploaded_count).
  • effective_match_rate is deduplicated — a member matched via both email and phone counts once. It will be less than or equal to the sum of per-type match rates.
  • match_rate is server-authoritative — consumers should prefer this value over computing their own from submitted/matched.
  • id_type values combine hashed PII types (hashed_email, hashed_phone) with universal ID types (rampid, uid2, id5, euid, pairid, maid).
Sellers that only support aggregate match counts omit match_breakdown entirely.

Common Scenarios

Discovery Only

Check status of all existing audiences without making changes. The response includes all audiences on the account — filter by audience_id to find the one you care about:

Suppression List

Upload a list of existing customers to suppress from acquisition campaigns:

Removing Members

Update an audience incrementally — add new members and remove ones that no longer qualify:

Deleting an Audience

Remove a specific audience from the account without affecting others. Set delete: true on the audience object:
To delete multiple audiences in one call, include each with delete: true. To delete all buyer-managed audiences at once, use delete_missing: true with an empty audiences array — but be careful, this removes everything.

Using Audiences in a Media Buy

Once an audience is ready, reference it by audience_id in create_media_buy targeting overlays. Audience IDs are scoped to the seller account — they cannot be used across sellers.
test=false

Audience Status

Platform matching is asynchronous. The status field reflects the current state: status is present when action is created, updated, or unchanged. It is absent when action is deleted or failed. Sellers MUST emit too_small whenever matched_count < minimum_size. Returning ready with a matched_count below the platform minimum is non-compliant — buyers rely on the status value as a programmatic signal that targeting will fail, not on post-hoc interpretation of the count. Webhook (recommended): Configure push_notification_config at the protocol level before uploading. The task stays active while the seller’s platform matches members. When matching completes, the task completes and the webhook fires with the final result — status: "ready" or status: "too_small". Check get_adcp_capabilitiesaudience_targeting.matching_latency_hours to set realistic expectations (typically 1–48 hours). Polling fallback: If not using webhooks, poll with discovery-only calls (omit audiences) no more frequently than every 15 minutes. Use tasks/get with the task_id to check task status — the task will be submitted while matching is in progress and completed when the audience is ready or too small. Agent workflow: Upload with push_notification_config set. Externalize the audience_id and account_id before the session ends. When the webhook fires with status: "ready", resume and proceed to create_media_buy.

Hashing Requirements

Hash all identifiers with SHA-256 before sending. Normalize first:
test=false

Privacy Considerations

The schema never carries cleartext email or phone — buyers MUST hash before transport. The seller matches by independently hashing its own user data with the same algorithm. Hashed identifiers are pseudonymous PII, not anonymous. Unsalted SHA-256 of an email or phone number is recoverable via precomputed dictionaries of the email and E.164 namespaces, so hashed_email and hashed_phone MUST be treated as PII for retention, consent, access control, and data-subject-request purposes. Do not describe them as “privacy-preserving” in operator documentation or DPAs. See Privacy Considerations. Buyer obligations: The buyer is responsible for having a lawful basis to process and share audience data, regardless of jurisdiction. Include consent_basis on each audience to communicate the GDPR lawful basis to sellers operating in regulated markets — some sellers require this field for EU audiences. Data handling: Once uploaded, data processing and retention are governed by your agreement with the seller. Review the seller’s data processing terms before uploading audience data.

Error Handling

Next Steps

  • Targeting — Reference audiences in targeting_overlay.audience_include and audience_exclude
  • create_media_buy — Apply audience targeting to packages
  • Conversion Tracking — Track outcomes from audience-targeted campaigns