> ## 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. # Get readiness > Check whether your storefront is ready to go live `GET /api/v2/storefront/readiness` Computes whether your storefront can transact now. Returns blocking checks for inventory-source lifecycle, agent auth, and, for Apostra-cleared storefronts, the confirmed settlement currency (`currency_confirmed`), plus a per-source `sourceDiagnostics[]` array used by setup surfaces. Poll this while you connect sources to see what is still missing. Managed and mixed storefronts with external ingredient agents require an explicit local routing scope. Set an allowlist with, for example, `PUT /api/v2/storefront { "acceptedCountries": ["FR"] }`. This is the operator-confirmed exhaustive brief-routing scope. It is separate from legacy Business Profile regions and from an ingredient agent's inventory evidence. Use `{ "acceptsAllCountries": true }` for an explicitly global agent. Existing connections with unconfigured scope receive an advisory readiness item but are not transaction-blocked during rollout. A pure pass-through storefront does not configure a second local scope. Each source's read-only standard AdCP `primary_channels` and `primary_countries` are the coverage shown on the Listing and used for routing. Accepted countries equal primary countries. A missing or malformed primary array stays unknown and is a readiness gap. For Apostra-cleared storefronts, the `currency_confirmed` check is a blocker and stays `missing` until you set a primary settlement currency with `PUT /api/v2/storefront { "defaultCurrency": "USD" }` (ISO-4217). It is independent of billing setup — saving payout details does not satisfy it. There is no implicit currency. A storefront without a supported `defaultCurrency` is `blocked`, absent from transaction-ready discovery, and rejects new media buys. Setting a supported currency removes that blocker automatically; it does not rewrite the seller's pause choice. Direct sales adapter storefronts run by our expert agents skip `currency_confirmed` and `settlement_currency_match` because Apostra does not pay the seller on that path; the buyer pays the downstream platform directly through their selected platform account. For Apostra-cleared storefronts that need to be paid in more than one currency, also send `paymentCurrencies` — the ISO-4217 currencies your storefront will be **paid in**, e.g. `PUT /api/v2/storefront { "defaultCurrency": "USD", "paymentCurrencies": ["USD", "GBP"] }`. On a currency you settle there is no FX: the currency a buyer pays in is exactly the currency you are paid in, so you cannot sell a pricing option in a currency that is not in this set. The marketplace may additionally accept a buyer currency outside your set via [cross-currency FX](/v2/concepts/cross-currency) — converting each source cost to the buyer's currency while you are still paid in your own. A media buy must be denominated in a currency you transact (your `defaultCurrency` is always included); discovery only surfaces a product to a buyer in a currency you accept, and a buyer whose currency you don't accept gets no products (an empty list, not an error) rather than ones they can't buy. If `paymentCurrencies` is empty or omitted, it falls back to `defaultCurrency`, so a single-currency storefront need not set it. **Changing the settlement currency after go-live is guarded.** Operator fixed prices are only shown to buyers in the storefront's settlement currency, so changing `defaultCurrency` on a live (transacting) storefront can hide products buyers can currently purchase. When the change would hide one or more buyer-visible products, `PUT /api/v2/storefront` rejects it with a `VALIDATION` error stating the affected product count; confirm the impact and retry with `{ "defaultCurrency": "EUR", "confirmCurrencyCatalogImpact": true }` to proceed. Hidden products reappear once their fixed prices are re-authored in the new settlement currency. Non-transacting storefronts and zero-impact changes are unaffected. ## Request ```bash curl theme={null} curl https://api.apostra.com/api/v2/storefront/readiness \ -H "Authorization: Bearer $SCOPE3_API_KEY" ``` ## Response ```json theme={null} { "platformId": "premium-ctv", "status": "blocked", "isPaused": false, "canTransact": false, "effectiveStatus": "blocked", "checks": [ { "id": "inventory_sources", "name": "Inventory source", "description": "Inventory source connected.", "category": "inventory", "status": "complete", "isBlocker": true, "method": "agent", "details": "1 inventory source connected" }, { "id": "agent_auth", "name": "Inventory source authentication", "description": "Add authentication credentials for your inventory sources.", "category": "agents", "status": "missing", "isBlocker": true }, { "id": "currency_confirmed", "name": "Currency", "description": "Confirm the currency your storefront settles in before going live — it is never chosen for you.", "category": "billing", "status": "missing", "isBlocker": true } ], "sourceDiagnostics": [ { "id": "9007199254740993", "sourceId": "src_main", "name": "Premium CTV — Direct", "executionType": "agent", "sourceStatus": "ACTIVE", "agentId": "agt_premium_ctv", "agentStatus": "ACTIVE", "requestRouting": null, "endpointUrl": "https://agent.premium-ctv.example.com/mcp", "protocol": "MCP", "auth": { "required": true, "configured": false, "type": "api_key" }, "capabilities": { "products": "supported", "createMediaBuy": "supported", "updateMediaBuy": "unknown", "signals": "unsupported", "wholesaleProducts": "unknown" }, "productBuilder": { "mode": "passthrough", "wholesaleProductCount": null, "signalCount": null, "catalogCacheCold": false, "declaredUnsupportedIngredients": false }, "compliance": { "passed": false, "summary": "1 of 3 tracks failing", "checkedAt": "2026-06-06T15:00:00.000Z", "trackCounts": { "total": 3, "passing": 2, "partial": 0, "failing": 1 } }, "debug": { "version": null, "syntheticCapabilities": false, "tools": ["get_products", "create_media_buy"], "supportedBillings": ["cpm"], "channels": ["ctv"], "publisherDomains": ["premium-ctv.example.com"], "requireOperatorAuth": true }, "lastActivity": null, "health": { "status": "healthy", "lastError": null, "lastErrorCode": null, "lastErrorAt": null, "lastSuccessAt": "2026-06-06T14:59:00.000Z", "lastCheckedAt": "2026-06-06T15:00:00.000Z" }, "capabilityHealth": { "inventory": { "status": "healthy", "observations": [ { "observer": "get_products", "status": "healthy", "previousStatus": null, "cause": null, "detail": null, "owner": "seller", "observedAt": "2026-06-06T14:59:00.000Z", "lastOkAt": "2026-06-06T14:59:00.000Z" } ] }, "reporting": { "status": null, "observations": [] } } } ], "setupMode": null, "liveness": { "state": "setup", "reasonCode": "setup_incomplete", "reason": "Not live — 2 steps remaining.", "remainingSteps": 2, "actionPath": null } } ``` ## Response fields | Field | Type | Description | | ---------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `platformId` | string | Your storefront's public slug | | `status` | enum | Overall readiness: `ready` or `blocked` | | `isPaused` | boolean | Compatibility-named intake hold. `true` blocks buyer discovery, new buys, and buyer edits without stopping existing delivery; `false` is neutral, not proof that the storefront is live | | `canTransact` | boolean | Compatibility storefront transaction rollup. For exact `get_products` selection, use each Source's `sourceDiagnostics[].requestRouting.selectedForRequest`. | | `effectiveStatus` | enum | Derived `archived`, `paused`, `blocked`, or `live`; never stored | | `availabilityGuidance` | object | Canonical cause, effect, and fix when a top-level Pause or Archive control blocks buyer-serving work; omitted otherwise | | `checks[]` | array | Top-level readiness checks (see below) | | `sourceDiagnostics[]` | array | Per-inventory-source diagnostics (see below), including the canonical `requestRouting` decision used by live discovery | | `setupMode` | object \| null | Per-source composition classification and aggregate verdict used by setup surfaces. Fields: `sources[]`, `managedSalesAgents[]`, `composition` (`{ required, sourceCount }`), `passthrough` (`{ sourceCount }`), `unknown` (`{ sourceCount }`), `recommendation` (`"composition"` \| `"passthrough"` \| `"mixed"` \| `"undecided"`). `null` when inference fails (e.g. cold cache). | | `liveness` | object | The projected liveness verdict (see below) — one derived status every surface presents the same way | ### `checks[].guidance` Every incomplete hard requirement includes one canonical explanation. Murph, V3 account status, and inventory-source reads consume this same object instead of inferring demand or causality from source call counts. | Field | Type | Description | | ------------ | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | `coverage` | enum | `complete` when the readiness catalog owns the resolution; `missing` makes an unregistered future blocker explicit instead of inventing a fix | | `stage` | enum | Currently `before_source_dispatch`: buyer-serving work stops at storefront transaction admission before an inventory source receives `get_products` | | `why` | string | Current cause using the check's live `details` evidence | | `effect` | string | Buyer-path consequence, including why source call counts can remain flat while buyers are trying the storefront | | `fix` | string | Smallest action that clears the blocker | | `subjects[]` | array | Inventory sources directly implicated by the blocker, when known; each row is `{ kind, id, name }` | | `evidence` | object | Optional typed evidence. Billing compatibility reports `requiredSupportedBilling` plus each incompatible source's advertised `supportedBillings` values | Complete hard requirements and non-blocking checks omit `guidance`. ### `liveness` One derived liveness status per storefront, computed server-side over the checks, source diagnoses, and settlement invariants above. The seller setup page and the account switcher's per-storefront status dot both present this same verdict — there is exactly one answer to "is my storefront live?". `liveness` is operational/readiness presentation, not a discovery gate. A degraded or erroring Source still receives requests when its canonical `requestRouting.selectedForRequest` is `true`. This is the canonical configured-Source selection; cache-backed wholesale Sources can contribute without receiving a live network call. | Field | Type | Description | | ---------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `state` | enum | `setup`, `live`, `live_attention`, or `live_critical` (see below) | | `reasonCode` | enum | Machine-readable cause: `archived`, `paused_before_live`, `paused_after_live`, `setup_incomplete`, `settlement_ineligible`, `catalog_empty_live`, `go_live_requirement_regressed`, `degraded_source`, `trafficking_error`, or `healthy` | | `reason` | string | One human-readable status line, e.g. `"Not live — 2 steps remaining."` or `"Stopped — settlement currency unsupported."` | | `remainingSteps` | number \| null | Open go-live blocker count, present only for `state: "setup"` | | `actionPath` | string \| null | In-app path of the surface that owns the fix (e.g. `/inventory-sources`). `null` when the fix lives on the home/setup surface | **The four states:** * **`setup`** (rendered gray) — the storefront is not live yet, and that is expected: it is in setup, pre-launch, or deliberately paused before ever going live. Setup is not failure — no matter how many steps remain, a storefront that never went live is never shown as broken. * **`live`** (green) — live and healthy. Buyers can discover and buy. * **`live_attention`** (yellow) — live, with something worth acting on that has **not** broken the promise to buyers (for example, a degraded inventory source that isn't affecting what buyers can purchase). * **`live_critical`** (red) — the storefront reached live and the promise to buyers is now broken: it was paused or a go-live requirement regressed after going live (e.g. the settlement currency became unsupported, or the buyable catalog emptied post-launch), or a critical problem is stopping buys. "Reached live" means durable evidence: a completed real buyer media buy, the recorded setup history showing every current go-live requirement was once complete, or a previously recorded live status. Once your storefront has been observed live it never drops back to `setup` — a newly introduced or broken requirement shows as `live_critical` instead, so an outage is always visible (and alerted) as a broken promise, never hidden as setup. A passed no-spend sandbox test alone does not make a storefront "live" — a mid-setup storefront that just ran its first test stays `setup`. The status reflects the buyer's reality: a dead source that carries no buyer-visible products does not change the state, and storefronts selling through their own third-party sales agent are never gated on merchandising requirements that don't apply to their path. **A flip away from `live` sends a proactive notification** — you don't have to notice the dot change color to find out. See [Notifications](/v2/guides/notifications) for the `storefront.liveness_degraded` / `storefront.liveness_recovered` event types, their payload, and the dedupe rules (a storefront sitting degraded is not re-notified every sweep; a further worsening is). ### `checks[]` | Field | Type | Description | | --------------------------------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `id`, `name`, `description`, `category` | string | Check identity and grouping | | `status` | enum | `complete`, `partial`, `missing`, or `optional`. `optional` checks are explicitly skipped (e.g. billing in non-production) and never block | | `isBlocker` | boolean | Whether this check blocks going live | | `method` | string | How the check was evaluated. Optional | | `details` | string | Human-readable detail. Optional | | `compliance[]` | array | Per-agent compliance results (present on `agent_connectivity` checks). Each is `{ agentId, agentUrl, passed, summary, tracks[], observations[] }`. A track's `status` is `pass`/`fail`/`partial`/`skip`; a `skip` track did not run and is labelled "not run" / "no coverage". `observations[]` carries advisory `{ category, severity, message }` notes. Compliance is informational and does not block going live. | The `operator_domain` check distinguishes two setup states. If no operator domain is set, it is `missing`. If a domain is set but not verified yet, it is `partial` with `details` like ` is pending verification`; go-live is still blocked until the registered organization domain is approved or ownership is confirmed. The `business_profile` check (`name: "Listing"`) verifies your buyer-visible identity — description, channels, and accepted countries. Its `isBlocker` value tells you which of two states applies to your storefront, and can differ between storefronts: for most storefronts an incomplete Listing is advisory (`isBlocker: false`) and does not block going live on its own. For storefronts in the cohort where the Listing go-live gate is enabled, an incomplete Listing is `isBlocker: true` and blocks going live like any other blocking check. Always read `isBlocker` on your own storefront's response rather than assuming either state — the gate rolls out by cohort over time, so the same missing field can be advisory today and blocking later without any other change on your side. Transaction admission verifies product availability strictly: These wholesale/component checks apply only when product composition is part of the storefront path. A pure third-party sales-agent storefront is not required to publish or cache a wholesale catalog in Apostra; its live agent path and transaction validation remain the applicable gates. * **Untraffickable catalog.** `source_products_traffickable` blocks the flip when EVERY synced product across your non-managed sources is untraffickable (e.g. hosted video with no duration, or a display format with no width/height) — you would otherwise sell nothing that can actually traffic. It stays a non-blocking warning when only some products are affected; the rest can sell. * **Unverified catalog.** If product availability can't yet be confirmed (a cold, not-yet-fetched catalog cache), the flip warms the catalog with a live fetch and rechecks once before deciding. If it is still unconfirmed, `products_available` blocks with "Catalog not yet verified — retry in a moment" instead of allowing a buy. `product_publisher_domains` warns when an active product has no publisher-domain mapping or references a domain the storefront has not declared. It remains non-blocking while older catalogs are backfilled. For every storefront, `publisher_domains` requires at least one declared domain so buyers know what is being sold. Neither check requires that domain to authorize Apostra. The separate `publisher_authorization` warning reports adagents.json/AAO authorization progress and never blocks transactions. The brand domain identifies the company running the storefront and is not used as a publisher domain unless the seller declares it as one. The compatibility-named `publish_validation` check requires transaction proof for every active execution path. For a third-party Sales Agent, Apostra reads the canonical `media_buy_transaction` assertion for that Agent's exact current production revision. One valid revision proof can therefore cover multiple Sources using the same Agent implementation. Credentials, client account mapping, reachability, and health remain Source-specific checks; proof from another client never hides those failures. A material Agent revision does not inherit the previous revision's proof. In **Required to go live**, choose **Run transaction validation** to open the Test section for the exact Agent and inventory source that still needs proof. For a modular source, it opens that source's readiness surface instead; it does not ask you to connect the source to an Agent. If an active Agent source is not yet linked to a registered Agent, it opens **Source diagnostics** for that source. Create or attach the Agent there, then retry transaction validation. If multiple active Agent connections match, select the connection to use or remove or reconcile the extra connections before retrying. A completed seller-owned no-spend sandbox test or a successful live buyer media buy can still satisfy a Storefront-local path. Compatibility test records are judged by the ordinary `create_media_buy` operation they exercised, not by an orchestration wrapper name. The sandbox path can exercise a pre-live storefront without exposing it to ordinary buyer discovery; it is server-authored, seller-scoped, respects Pause, and cannot bypass another readiness blocker. Failed later tests remain diagnostic evidence but do not erase an earlier successful transaction. An already-activated Source keeps its onboarding completion if the Agent's current proof later expires or fails; implementation health, Source health, and quarantine continue to govern ongoing operation without rewriting history as "never tested." The check is scoped to the storefront's connected source mix, because it exists to prove an *unproven* transaction path — it never asks you to prove plumbing Apostra already operates: * **Managed-only.** If every connected source is your Apostra-managed sales agent (ad server), the check reports `complete` with "Covered by your managed sales agent" — it counts toward your required steps without asking for a separate test. * **Mixed.** If you also connect a third-party sales agent (or a modular source whose recipe executes campaigns, such as CitrusAd), the check still applies. For an uncovered Agent, its details name `create_media_buy` and direct you to run the public transaction validation skill on that Source or ask the Agent owner to provide current-revision proof. * **Third-party only.** If none of your connected sources is Apostra-managed sales agent, the check applies as described above. In exceptional cases Apostra may approve a storefront-specific service override for `publish_validation`. The readiness item remains `complete` but reports `method: service_override` and names the approval evidence; it never claims a transaction occurred. The exception does not bypass Pause, publisher-domain declaration, product availability, or any other readiness requirement. If a live storefront's buyer-visible catalog later empties (for example, manual pricing expiring), you get a proactive notification naming the cause and the fix — see [Troubleshoot source problems](/v2/storefront/inventory-sources/troubleshooting#products-hidden-from-buyers). Its effective status automatically becomes `blocked`; `isPaused` is unchanged. **Ad-server-derived pricing has a 60-day freshness ceiling.** A product priced from ad-server reporting history stays buyable only while its catalog keeps refreshing; if the sync stops and a cached price goes more than 60 days without a refresh, the product is hidden from buyers rather than quoted on a stale price. When this is the only reason your catalog is hidden, the `products_available` blocker names the stale ad-server sync as the cause and its fix is checking the ad-server connection — not uploading a pricing feed. A successful sync restores the pricing automatically. ### `sourceDiagnostics[]` | Field | Type | Description | | ------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `id`, `sourceId` | string \| null | Surrogate id and storefront-scoped source id | | `name` | string | Inventory source display name | | `executionType`, `sourceStatus` | string | Source type and current source lifecycle status | | `agentId`, `agentCapabilityUid`, `agentStatus`, `endpointUrl`, `protocol` | string \| null | Linked agent identity and transport. `agentCapabilityUid` is the authorised SALES capability that can open transaction validation for this source; it is `null` when no active, authorised Agent connection is resolved for the source. `agentStatus` is a deprecated compatibility copy of `sourceStatus`, not an independent lifecycle signal. | | `auth` | object | `{ required, configured, type }` — whether auth is needed, set, and which type | | `capabilities` | object | Support state for `products`, `createMediaBuy`, `updateMediaBuy`, `signals`, `wholesaleProducts` — each `supported`, `unsupported`, or `unknown` | | `productBuilder` | object \| null | Legacy compatibility projection: `{ mode (composition\|passthrough\|unknown), wholesaleProductCount, signalCount, catalogCacheCold, declaredUnsupportedIngredients }`. For component-cache diagnostics, `wholesaleProductCount > 0` means cached raw products are available, `declaredUnsupportedIngredients: true` means the source explicitly does not provide usable cached components, and `catalogCacheCold: true` means readiness cannot classify the source until cache refresh has evidence. Component readiness applies only to the Storefront-built path when the Agent reports AdCP 3.1+ support. | | `compliance` | object \| null | `{ passed, summary, checkedAt, trackCounts: { total, passing, partial, failing } }` | | `debug` | object | Sanitized capability metadata: advertised `tools`, `supportedBillings`, `channels`, `countries`, `publisherDomains`, `version`, `syntheticCapabilities`, `requireOperatorAuth` | | `lastActivity` | object \| null | Latest setup activity `{ action, resourceType, resourceId, resourceName, description, timestamp }` | | `health` | object | `{ status (healthy\|degraded\|unhealthy\|unknown), lastError, lastErrorCode, lastErrorAt, lastSuccessAt, lastCheckedAt }` (one collapsed reading; this is the one place on this page where "nothing has reported" is the string `unknown` rather than `null` — see the note under [Capability health observations](/v2/storefront/inventory-sources/diagnostics#capability-health-observations)) | | `capabilityHealth` | object | The `inventory` and `reporting` axes, each `{ status, observations[] }`: `status` is the derived current verdict for that axis (discounts stale readings, `null` when nothing has reported), and `observations[]` is the per-observer evidence behind it. See [Capability health observations](/v2/storefront/inventory-sources/diagnostics#capability-health-observations). | | `sourceDiagnostics[].requestRouting` | object \| null | The canonical per-Source discovery decision: Storefront and Source setup, Source and Agent explicit eligibility, Agent mapping (`UNMAPPED`, `CERTIFIED`, `VALIDATED`, or `UNVALIDATED`), separate Source health and Agent implementation health, exact request compatibility, and `selectedForRequest`. Health is diagnostic and never changes this value implicitly. `willReceiveRequest` remains a deprecated compatibility alias and is not proof of a live network call. | ## Errors * `401 UNAUTHORIZED` — missing or invalid bearer token. See [Errors](/v2/reference/errors) for the full error contract. ## Related Readiness, marketplace review, and AAO signals. Connect the sources readiness checks against. Interpret source health and recent ADCP activity. Inspect the AAO registry for your brand domain.