> ## Documentation Index > Fetch the complete documentation index at: https://docs.apostra.com/llms.txt > Use this file to discover all available pages before exploring further. # Storefront > What a storefront is for an operator — inventory sources, business profile, operating instructions, readiness, and marketplace listing. ## Overview Your **storefront** is your buyer-facing home on Apostra: the business presence, name, and discovery surface buyers use to understand who they are buying from. Behind it, the Merchandising Agent answers buyer briefs, composes products, and runs the AdCP media-buy workflow on your behalf, drawing from one or more **inventory sources** you connect. This page is the operator's map of the storefront object. Each domain below has its own task pages; this overview explains what the pieces are and how they fit together. **Merchandising is open beta.** Every media company can use it — there is no cohort to be admitted into and nothing to apply for. It is beta rather than generally available because the journey is newly built and we have not yet watched enough publishers through it to promise it won't break. The capabilities inside it keep their own maturity, and any step a person does by hand is marked as such rather than described as automatic. **Running real-money campaigns on your own inventory is limited to named companies.** The no-spend sandbox — build, activate and read a campaign against your own storefront — is open to every media company. The same workflow with live spend is switched on for named companies while it is proven, and for those companies live campaigns are read-only in the campaigns experience; changes go through the agent rather than a native write path. ## Seller navigation The **Advertisers** tab opens on your sole visible advertiser automatically. When you have several, it reopens the advertiser you last selected for this account; when there is no earlier choice (or no advertisers), it shows the account name and advertiser count. This choice survives a reload and is kept separately for each person and account. **Sandbox** remains a toggle-revealed badge, not a lens, and the visible set after that toggle determines the default. A link that already names an advertiser always takes precedence. The rail has a fixed picker with that advertiser's class, recent selections, search, and **All advertisers** to return to the overview. Below it are only that advertiser's jobs. A House or Self-serve advertiser offers **Overview**, **Campaigns**, **Creatives**, and **Reporting**. Its Overview opens that advertiser's scoped Campaigns Page. An External advertiser with a resolved relationship offers **Overview**, **Media buys**, **Creatives**, and **Account**; its Overview opens that relationship's Account setup case. An unresolved External row does not offer Overview. A System advertiser offers read-only **Overview**, opening that System row's read-only roster detail. Overview always keeps the selected advertiser scope; only **All advertisers** returns you to the full roster. When you select an External or System advertiser, its filtered roster detail stays in the canvas until you choose one of that advertiser's available jobs; you will not be taken to Campaigns. Seller analytics is still available from **Operate → Dashboard**. Each roster row carries one of four classes — House, Self-serve, External, or System — shown as a small leading icon. House and Self-serve are advertisers you operate (Self-serve means a client runs their own workflow inside your roster, but you can still edit); External is any counterparty reached through an AdCP account relationship. System is an Apostra-operated reviewer or compliance-canary advertiser. It is always read-only to the seller and takes precedence over every other class. The class comes from its provisioning record, never its name, and it does not use the managed-marketplace class label. To see your buyers, open **Buyers**. Each external counterparty appears there, and a pending setup case shows **awaiting you** in the **Needs you** signal. A House or Self-serve row opens **Sellers, Activity, Campaigns, Creatives, Catalogs, Conversions, and Reporting** — there is no Account tab for these, since there's no relationship or setup case behind an advertiser you operate. An External row opens **Media buys** by default: the buyer's approval queue and active buys with you, including their synced creative state. Its sublist also offers **Creatives** and **Account**; it never opens the buyer's own campaign container. The roster shows the relationship's buy count and most recent activity when that relationship has routed activity. The **Account** tab is where the buyer's billing path, setup requests, and inventory mappings live for that relationship — one place instead of two. System rows expose no mutation or navigation affordance. The `shared_default` billing binding is a billing route, not an advertiser, and is not a seller roster row. External rows show neutral buyer account-setup status when action remains: **Needs setup — waiting on you**, **Waiting on buyer**, or **Awaiting billing**. The **Needs you** row counts only advertisers with a case waiting on you and filters the canvas to those rows, regardless of lens; there is no separate inbound-requests list. Selecting a row awaiting your decision opens its **Account** job's setup case — the same case available from Buyer Account Mapping. Buyer account setup does not change storefront health or the Inventory tab's go-live status. See [Buyer Account Mapping](/v2/storefront/buyer-account-mapping#account-setup-in-advertisers) for each state, who acts, and the case action; House, Self-serve, and System rows do not carry a setup state. ``` Storefront (your buyer-facing surface) ├── Business Profile (identity, positioning, authorized domains) ├── Discovery (brand-derived card and publication visibility) ├── Operating Instructions (versioned guidance; exactly one active) └── Inventory Source(s) (AdCP agent — discovery + execution) └── Buyer accounts (the buyers that transact through the source) ``` All examples use the storefront base URL and a bearer token: ``` https://api.apostra.com/api/v2/storefront ``` ```bash theme={null} curl https://api.apostra.com/api/v2/storefront/readiness \ -H "Authorization: Bearer $SCOPE3_API_KEY" ``` ## Discovery publication The listing (previously called the media kit or Discovery Card) is the storefront's canonical buyer-visible identity and coverage summary. Seller admins publish it from **Storefront settings → Discovery** by choosing a visibility and selecting **Publish**. Name, description, website, logo, colors, and generated icons are derived from the storefront card and its `brand.json` profile, so there is no second directory profile to maintain. Customer 1 can also activate the platform-managed public origin at `api.apostra.com`; other customers remain limited to private or Apostra visibility during the initial rollout. OpenAI verification is optional and appears only after that public origin is active. See [Publisher domains](/v2/storefront/publisher-domains#discovery-publication-origins) for public routes, verification, and withdrawal behavior. ## Inventory sources An **inventory source** is private upstream supply behind your storefront. It can be an AdCP-compatible agent, an ad-server connection, a runtime link to another storefront, or a modular lifecycle. Each path supports the product discovery (`get_products`) and media-buy execution (`create_media_buy`) stages it advertises. A storefront can use multiple sources, and the products buyers see are assembled from the supply they provide. Sources come in a few shapes: * **External sales agents** you already run, connected by endpoint and auth. * **Managed ad servers** — Google Ad Manager, FreeWheel, SpringServe, or AdsWizz — where Apostra runs the sales-agent plumbing in front of your ad server. * **Other storefronts** that have authorized passthrough or federation. * **Modular sources** assembled from catalog/avails, booking, creative, execution, reporting, and human-work modules. Use [Choose how your storefront gets supply](/v2/storefront/inventory-sources/choosing-a-source) before connecting anything. It also explains the separate storefront-adapter path, which configures the storefront dispatcher rather than adding an inventory source. Each source declares its capabilities (`products`, `createMediaBuy`, `updateMediaBuy`, `signals`, `wholesaleProducts`) and whether it requires authentication. A Storefront-built storefront assembles products across active sources; an Agent-supplied storefront proxies `get_products` to one upstream source and overlays your storefront identity and buyer instructions on the response. ## Business profile Your **business profile** is captured during storefront setup and helps the Merchandising Agent describe your business, follow the right merchandising guidance, and understand which publisher domains it is authorized to sell through the storefront. | Field | Type | Description | | ------------------ | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `summary` | string | Concise explanation of what the storefront sells. Maximum 2000 characters. | | `agentName` | string | Deprecated agent-name field, kept for legacy compatibility only. Prefer the storefront display name for buyer-facing naming. Maximum 80 characters. | | `agentPersonality` | string | **Deprecated.** An agent has no personality of its own — voice belongs to the brand and is read from the brand manifest (`tone`). Nothing consumes this field. Maximum 1000 characters. | | `propertyCount` | integer | Approximate number of owned publisher properties, from 0 to 10,000. | | `channels` | string\[] | The full AdCP MediaChannel vocabulary the storefront offers: `display`, `olv`, `social`, `search`, `ctv`, `linear_tv`, `radio`, `streaming_audio`, `podcast`, `dooh`, `ooh`, `print`, `cinema`, `email`, `gaming`, `retail_media`, `influencer`, `affiliate`, `product_placement`, or `sponsored_intelligence`. The legacy aliases `audio` (for `streaming_audio`) and `video` (for `olv`) are also accepted on write and round-trip unchanged. | | `regions` | string\[] | Up to 64 ISO alpha-2 country codes or region groups such as `EMEA` and `WORLDWIDE`. | | `verticals` | string\[] | Up to 32 audience or content focus areas, each no more than 80 characters. | | `publisherDomains` | string\[] | Publisher domains or properties the storefront is authorized to sell. Up to 128 valid domains; each is normalized to lowercase, deduplicated, and limited to 253 characters. | | `evidenceUrls` | string\[] | Up to 16 media-kit, about-page, or other source URLs. | | `notes` | string | Confirmed context that does not fit the structured fields. Maximum 4000 characters. | | `updatedBy` | string | Audit marker for the last writer. The Business Profile page manages this automatically. | `businessProfile.regions` is the canonical market configuration used by storefront qualification and cards. The legacy top-level `regions` field remains a compatibility alias: writing it updates the Business Profile, and reads project the Business Profile value so the two surfaces cannot disagree. ```json Example theme={null} { "businessProfile": { "summary": "Premium sports inventory across web, mobile, and CTV.", "channels": ["display", "ctv"], "regions": ["GB", "EMEA"], "publisherDomains": ["touchline.example", "football.touchline.example"] } } ``` Omitting `publisherDomains` means the authorized domains are unknown or have not been captured yet. It does not mean the storefront is authorized to sell every domain. In an MCP-compatible assistant, call `get_business_profile` to open the portable Business Profile page. Operators can review, create, and edit the profile in the page. An assistant can also call `update_business_profile` for an exact change confirmed in conversation. That tool applies a patch: omitted fields from the profile state read for that call stay unchanged, while an explicit `null` clears a field. Overlapping patch calls use last-writer-wins behavior, so clients should serialize concurrent edits. For managed sales-agent storefronts, this field is the authoritative publisher-domain set Apostra syncs to the managed sales agent. See [Publisher domains](/v2/storefront/publisher-domains) for replacement and removal behavior. ## Operating instructions **Operating instructions** are versioned guidance that steers how your storefront responds to demand — what to package, how to position, and how to negotiate. Exactly one version is active at a time; publishing a new version supersedes the prior one without losing history. Operating instructions are authoritative over historical analytics signals. When the Merchandising Agent composes products, your written instructions and [buyer instructions](/v2/storefront/buyer-instructions/overview) win over any directional signal derived from recent outcomes. ## Readiness diagnostics `GET /readiness` tells you whether your storefront can transact now. It returns blocking checks for inventory sources, agent status, and agent auth, plus a per-source `sourceDiagnostics[]` array used by setup surfaces. The overall `status` is `ready` or `blocked`; each check reports `complete`, `partial`, `missing`, or `optional`, and carries an `isBlocker` flag. Storefront lifecycle is not stored as a state. The seller-owned control is the buyer **intake hold**, exposed under the released compatibility name `isPaused`. It defaults to `false`. Setting it to `true` removes products from buyer discovery and blocks new media buys and buyer edits. Seller preview still works, and an approved buy that has not yet been sent to a source waits in the queue and forwards automatically after intake resumes. Clearing an intake hold is always available unless the storefront is archived: it restores the seller's prior neutral intake posture without claiming that a new readiness, runtime-safety, or administrative requirement has passed. Those independent safeguards continue to determine whether new business can actually transact. An intake hold does **not** pause campaigns already delivering in your ad server. Existing campaigns keep delivering and reporting. A storefront-wide delivery freeze is a separate, confirmed operation because resuming it must not activate campaigns that were already paused before the freeze. Effective status remains the v2-compatible `archived`, `paused`, `blocked`, or `live`. A storefront without an intake hold becomes live automatically when every current requirement passes, and becomes blocked automatically when any new or existing requirement fails. The deprecated `transacting` field is only an API compatibility projection of `!isPaused`; it is not proof of readiness. See [Get readiness](/v2/storefront/tasks/get-readiness) for the full field reference. ## Marketplace review and AAO signals New storefronts start in a pending-review marketplace state. You can configure and use your storefront, and open it for known transactions, but public buyer discovery only includes storefronts that Apostra has reviewed and listed. Marketplace listing uses signals from the [Agentic Advertising Organization](https://agenticadvertising.org) (AAO) registry. Source registration, storyboard compliance, and publisher authorization are different checks: registration blocks connecting an external agent source; compliance is advisory for activation; publisher `adagents.json` authorization is surfaced as an advisory setup/product signal today. Apostra's marketplace review decides when a live storefront is listed in public buyer discovery. Use [Discover agents](/v2/storefront/tasks/discover-agents) and [Resolve brand](/v2/storefront/tasks/resolve-brand) to inspect what the registry knows about your brand domain and the brands you transact with. An admin can hide a listed storefront, which removes it from public buyer discovery without deleting the storefront or its inventory sources. ## Storefront domains Connect and manage the AdCP agents and ad servers behind your storefront. Versioned merchandising and negotiation guidance. The targeting and optimization inputs your sources expose. Review and decide on incoming media buys before they go live. Payout bank details and fees so Apostra can pay you. Win rate, buyer asks, top products, and negotiation posture. Per-buyer discounts, notes, and country scoping.