Listings

A listing (previously called the media kit or Discovery Card) is the buyer-visible projection of a storefront. The same listing powers what buyers see on Apostra and the discoveryCard object returned by the buyer storefront APIs. It is not a separate inventory or policy object. Seller admins publish this same listing from Settings → Discovery & distribution. The publication identity, logo, colors, and generated icons come from the values present in the storefront’s canonical brand profile when it is published. Icon generation is not a background step to wait for. Publishing and downloading the submission package do not require a logo. If the brand profile has no usable logo, the publisher uploads production-ready logo assets directly in OpenAI before submitting. See Publisher domains and Discovery publication origins for the operator workflow and public-origin behavior. The Discovery & distribution page links to the complete OpenAI submission walkthrough, including verification, package contents, manual logo handling, and the steps that remain in OpenAI. Visibility and account access are separate. Public makes the published Discovery page readable on the web; it does not grant anonymous or self-serve access to the account. Browser-based MCP apps still need OAuth, PKCE, and an exact registered redirect URI. Public distribution also requires an active publication hostname. Apostra’s first-party publication uses the platform-managed api.apostra.com origin and needs no CNAME. A customer-owned origin uses the TXT ownership and CNAME routing records shown in Discovery & distribution before it can become the preferred public origin. The machine-readable listing JSON is available under Developer details for renderers and integrations; it is not a manual submission artifact.

​

Public root and agent discovery

A verified customer CNAME is one shared publication implementation, not a copy of the API or a new set of routes maintained for that customer. Its root stays human-first while publishing machine links in both the HTML and HTTP Link headers. Listing assets stay on the verified publication origin; reusable skills stay on the platform API origin: The platform-managed Apostra listing uses /discovery and /discovery/card.json; agents should follow the advertised links instead of assuming either layout. The public listing and skill do not grant access. A buyer authenticates with its own Apostra buyer credentials, the same ones it uses for the buyer API. To transact directly with the published Seller, the agent follows the verified actions[kind=adcp].url from the listing. On a Seller CNAME that URL is /adcp/mcp, because the verified hostname already identifies the Seller. A platform-managed listing uses the shared-host fallback /seller/{platformId}/mcp. The agent must not derive a Seller ID or restore the retired /storefront/{platformId}/mcp path. The action is included when the Seller has the Listing + Distribution package; other published Listings do not advertise a direct transaction endpoint. The public projection follows the Seller’s current profile immediately, so changing profiles does not require republishing the Listing. The CNAME changes public discovery and routing only. Apostra remains the agent of record for the resulting inbound AdCP campaign: it anchors buyer identity, advertiser, contract terms, governance, journal, reporting identity, accepted commitments, and delivery evidence. The Seller Account manages the one-to-one buy; the public hostname does not bypass Apostra or create a new commercial counterparty. /mcp/v3 is a different contract: it is the account-resolved Apostra product API. The authenticated account, enrollment, and capabilities determine which nouns and tools appear in tools/list. Serving V3 through an approved hostname does not make it a direct Seller endpoint, and the hostname does not widen the credential’s authority. Use the listing to answer three questions before sending a brief:

• Who operates this storefront?
• Does it accept briefs for this channel and country?
• Has the seller chosen to disclose any Advertising Policies?

​

Coverage declarations

coverageDeclarations contains the storefront’s coverage claims. Each entry keeps a set of channels and the countries they cover together. A storefront has one declaration when it names any channel or country, set by its seller or assumed (see below), and none when it names neither. Never combine channels from one declaration with countries from another. The top-level channels and countries arrays are aggregate search and display facets. They are the union of known values, not a promise that every listed channel is available in every listed country. Country values are ISO 3166-1 alpha-2 codes such as FR, US, and JP. The legacy channel alias audio is normalized to the AdCP channel streaming_audio. Use GET /api/v2/buyer/storefronts?region=FR&channel=ctv to find storefronts that accept CTV briefs in France. Today the filters match each storefront’s stored channels and region declarations, and a storefront with an empty list matches any value in that dimension. Apostra is rolling out filters that read the same channels and countries the listing shows. Once that is enabled, a storefront matches a channel filter when its channels include that channel or it names no channels, and a country filter when its countries include that country, it accepts all countries, or it names no countries. A combined filter then matches only when both dimensions match. Legacy market-group filters such as EMEA remain available for older region declarations, but new listings use country codes. The coverage object makes completeness explicit: acceptsAllCountries: true remains the only explicit worldwide declaration. For managed storefronts that still have legacy unknown country coverage, Seller Setup starts the editor with every country selected. Saving records that worldwide behavior explicitly; leaving the old record untouched keeps the dimension open.

​

Where listing fields come from

The listing carries provenance so buyers and agents can distinguish operator, registry, and upstream facts.

• Managed storefronts author their accepted channels and countries in Seller Setup. Their identity is resolved from the verified brand domain and its brand profile, with an operator-authored description on Apostra.
• Official provider adapters always use the provider name registered by Apostra and the channels implemented by that adapter. Stale operator-authored channels cannot change the provider’s listing coverage. Apostra uses the provider logo when it can resolve that logo from the provider’s registered domain. Until then, the listing shows the provider’s initials; it never pairs the provider name with the operator’s logo or colors. The brand domain remains a separate ownership fact.
• Until its seller saves the storefront’s own channels and countries, a pure pass-through storefront’s coverage is assumed: for each dimension, the union of the values stored on the storefront and the primary_channels and primary_countries its active sales agents declare. A dimension that includes an agent-declared value has upstream_capabilities provenance. A dimension neither names is empty with unknown coverage, and requests in any channel or country of that dimension reach the storefront. Once the seller saves, only the saved values are the listing’s coverage, marked as set by the operator. A mixed or BOTH-capable storefront’s Storefront-built sources declare coverage locally.

Brand identity remains owned where its brand.json is hosted. Seller Setup opens the specific AAO brand Page for an AAO-hosted identity. For a self-hosted identity, it instead tells the seller to update /.well-known/brand.json on the verified brand domain. All Apostra listings and buyer storefront responses use this same projection; clients do not need to resolve a second profile to reproduce the listing.

​

Advertising Policies

advertisingPolicies is an optional buyer-facing disclosure. A managed seller chooses whether to publish its Brief Acceptance rules, Creative Policy, or both. Approval routing, approver identities, revision notes, and per-buyer overrides are never included. A pure pass-through storefront can expose the upstream AdCP media_buy.portfolio.advertising_policies value read-only; a mixed or BOTH-capable storefront’s local disclosure remains editable. The complete disclosure is bounded to 10,000 characters. Storefront list responses use hasAdvertisingPolicies plus a bounded advertisingPoliciesExcerpt; retrieve storefront detail when you need the complete disclosed text. Advertising Policies help evaluate fit, but absence is not permission. The seller or upstream agent still decides whether to accept a brief.

​

Response fields

​

V3 compatibility

For new V3 integrations, read the listing with get({ kind: "seller", include: ["listing"] }) (discoveryCard is a deprecated alias) or open the listing Page (discovery_card is an accepted, deprecated spelling of the same Page; open_page({ page: "media_kit" }) is retired as an ambiguous key and returns an error naming listing and business_profile instead of opening either). The older get(kind: "media_kit") and save_media_kit contracts remain available as deprecated V3 compatibility surfaces pointing at the legacy Business Profile; they do not define the canonical listing model.