sync_catalogs manages buyer-provided data feeds that a seller uses to render or target ads. This is separate from the seller-side wholesale product feed exposed by get_products buying_mode: "wholesale" and the wholesale signals feed exposed by get_signals discovery_mode: "wholesale"; webhooks are the push layer for changes to those seller-side feeds.
Response Time: Instant to days (returns completed for small catalogs, or submitted for large feeds requiring platform review)
Request Schema: /schemas/v3/media-buy/sync-catalogs-request.json
Response Schema: /schemas/v3/media-buy/sync-catalogs-response.json
Who calls whom
The buyer callssync_catalogs on the seller to push catalog feeds to the seller’s account. The seller validates items, runs content policy checks, and returns per-item approval status.
This task sits between format discovery and creative submission in the account state setup sequence:
list_creative_formats— checkcatalogasset types in each format’sassetsarray to know what feeds to syncsync_catalogs— push the required feeds to the accountsync_creatives— submit creatives that reference synced catalogs bycatalog_idcreate_media_buy— launch the campaign
Quick start
Sync a product feed:Request parameters
Catalog object
Each catalog in thecatalogs array is a Catalog object. Key fields:
Response
Success response — per-catalog results:
Error response — operation failed entirely:
Responses use discriminated unions — you get either
catalogs or errors, never both.
Example response with item-level review
Item review lifecycle
Catalog items follow a simple review cycle: items enterpending on sync, and the platform reviews them asynchronously. Items are either approved, rejected (with reasons), or approved with warning (serving but with fixable issues).
Rejection is not terminal — fix the issue in the source catalog and re-sync. Re-syncing an item resets it to pending for re-review. The item_issues array on the response identifies per-item rejection reasons.
Discovery mode
Omitcatalogs to list all catalogs on the account without modification:
Async approval workflow
Large feeds or feeds requiring content policy review returnstatus: "submitted" with a task_id. The seller reviews items asynchronously and notifies the buyer via webhook when done.
Async response states:
working— platform is processing the feed (fetching URL, validating items)input-required— platform needs buyer action (fix validation errors, provide missing fields)submitted— review complete, final per-catalog results available
push_notification_config on the request to receive webhook notifications for state transitions.
Common scenarios
Retail media (product + inventory + store)
Recruitment (inline job offerings)
Dry run validation
Error handling
Best practices
-
Check format requirements first — Call
list_creative_formatsand checkcatalogasset types in each format’sassetsarray before syncing. This tells you what catalog types to sync and what fields each item needs. -
Use discovery mode — Before syncing, call without
catalogsto see what the seller already has. The seller may have brand data from other sources. -
Set
update_frequency— For URL-based feeds, always setupdate_frequencyso the platform knows how often to re-fetch. Stale feeds lead to ads showing out-of-stock products. -
Declare
conversion_events— Connect catalogs to the conversion tracking system by declaring which event types represent conversions for catalog items. -
Use
dry_runfor large feeds — Validate before committing, especially for first-time syncs with thousands of items. -
Handle per-item failures — In
lenientmode, valid items are processed even when others fail. Checkitem_issueson the response to fix rejected items.
Next steps
- Catalogs — Complete documentation on catalog types, sourcing, and format requirements
- Account state — How catalogs fit into the account setup sequence
- sync_creatives — Submit creatives that reference synced catalogs
- list_creative_formats — Discover format catalog requirements