Skip to main content
list_products is the side-effect-free entry point to the compact product lifecycle. Each invocation completes synchronously, while account-level wholesale feed webhooks keep long-lived buyer mirrors current without polling. It returns products only—never proposals. Buyers can purchase listed products through buy_products or pass returned product_id values to request_proposals for seller planning. Request schema: /schemas/3.0.23/media-buy/list-products-request.json
brand is an identity-only key. Sellers resolve its canonical manifest from the domain; callers do not send logos, colors, or governance overrides in this request. Catalog ingestion belongs to sync_catalogs; discovery accepts only a compact catalog selection under criteria.catalog. offer_filters select commercial offers. targeting_overlay instead constrains the inventory or impressions that may deliver, so every returned price and forecast must account for the effective overlay. required_overlay_support asks for targeting dimensions the buyer can select independently on packages later; it does not request one product per metro or guarantee availability for every future value. When a product can honor the overlay exactly, it does not echo the request. A product that proposes a different executable overlay returns sparse targeting_resolution.modifications; selecting that configured product accepts those disclosed changes.

Response

Every response has an explicit outcome: A product page can include continuation and cache state:
To check whether the same selection has changed, repeat the request with if_feed_version. Include if_pricing_version only when if_feed_version is also present:
If the selected feed and pricing layer still match, the seller can omit products:

Wholesale feed webhooks

Buyers maintaining a wholesale product mirror register product.* and wholesale_feed.bulk_change subscribers through sync_accounts.accounts[].notification_configs[]. Registration is account-level and durable; push_notification_config on an individual list_products request does not create that subscription. The normal mirror flow is:
  1. Call list_products to bootstrap the mirror and store feed_version plus cache_scope.
  2. Register the durable account subscriber through sync_accounts.
  3. Apply the webhook’s canonical_product or canonical_pricing_options replacement payload directly.
  4. On a gap, call list_products with the mirror’s last successfully applied feed_version. On an uncertain or bulk-change repair, omit the conditional token and replace the mirror from a complete read.
The webhook version describes post-change state; it is not the conditional token for a stale mirror. Conditional reads are a repair path, not a requirement to poll while webhooks are healthy.