Skip to main content
Deprecated. This page documents the v2 storefront API, which is being retired for external callers. Use Operate work items and approvals in V3 instead.
When a buyer transacts against your storefront, you decide how much a human reviews before anything reaches your ad server. Three storefront settings control it. Creative and media-buy approval default to manual; new buyer accounts are accepted automatically up to standard payment terms (net_60), and longer terms wait for your review. Every approval always has an accountable owner: until you save a routing rule, approvals route to your organization admins by default. Save a routing rule to name a specific primary approver, and optionally a separate escalation audience.

​
The three settings

Each is storefront-wide and set independently. Configure creativeApproval and mediaBuyApproval by asking Apostra to set your approval settings, or with PUT /api/v2/storefront. You can’t change accountApproval yet; see New buyer accounts. The mode (auto vs manual) is separate from what your acceptance policy says — the policy is the content you judge against; the setting is whether a human judges at all. These settings govern counterparty traffic from external and sponsored buyers. When your authenticated Media Company operator uploads Creative, confirms a launch, or requests a non-cancellation update for an exact own-supply campaign, that action is the Storefront decision and does not enter a duplicate review queue. Source-native approval and the ordinary validation, readiness, financial, and safety gates still apply. A separate internal maker/checker workflow is not enabled by these Storefront settings.
A manual approval class needs at least one active primary approver. When no routing rule is saved, that is your organization admins by default — one active admin is enough, and admins receive approval reminders and escalations without any setup. Save a routing rule in the Approvals widget to choose a different audience: use a role audience where possible so staffing changes resolve automatically, or choose a named user when that is how your team works. A separate escalation audience is optional; without one, the primary audience remains responsible after the SLA. Apostra never turns approval on or off automatically to repair a missing route — a storefront with no active admin and no saved route stays fail-closed.
An admin of the organization that owns your account, for example an agency or holding company above it, can also approve or reject an item whose route uses a role they hold, such as the organization-admin default. While your account has admins of its own, they are not routed to, notified, or escalated to; when it has none, the default routes to them. They cannot decide an item routed only to named users.
Apostra approval settings apply to ad-server-backed storefronts (your Google Ad Manager, FreeWheel, SpringServe, or AdsWizz inventory) and to adapter routes configured for Apostra review. Storefronts that route to an external sales agent or linked storefront pass through. So do the provider-policy-owned social adapters: LinkedIn, Meta, Pinterest, Reddit, Snap, and TikTok. There is no Apostra review queue in front of those providers. Adapter routes outside that cohort — including Amazon, Google Ads, and Spotify — retain their configured Apostra approval behavior.
If an older pending item was created before approver routing was recorded, saving a media-buy or creative-review routing rule records that rule on any unchanged item that has never reached a routing stage. The recorded route is bound to that version of the approval, so resubmitting before, during, or after repair invalidates it. An older, unchanged approval that still has no routing stage or work item uses your current saved rule or the organization-admin default when someone attempts a decision. That decision-time check does not change the old item before confirming that person is eligible, and a simultaneous resubmission prevents the decision from being applied to replacement content. A resubmitted approval does not use this compatibility path, and the check stays fail-closed when neither route has an active eligible approver.

​
Active rules and brief charges

Brief Acceptance runs only when your storefront has an active AI Business Rules version. A storefront on a plan that charges for brief responses must have one before it runs briefs, along with payment cover. See Before your storefront runs briefs.

​
New buyer accounts

Before a buyer can transact with you, its agent asks for an account with sync_accounts. Your storefront accepts a new account straight away when it asks for net_60 or shorter terms, for prepay, or for no particular terms. A request for net_90 waits in your review queue on the Buyer Account Mapping page until you accept, link, or reject it. An account you have already decided on is not asked about again. GET /api/v2/storefront reports this as accountApproval: auto with accountMaxAutoAcceptPaymentTerms: net_60. You can’t change either setting yet, including to review every new account yourself: a PUT /api/v2/storefront that sets them is refused with a validation error, and your current setting stays in place. A Listing storefront that passes buyers through to your own sales agent leaves account decisions to that agent, so this setting does not apply to it.

​
Manual review: hold exceptions

Creative and media-buy approval both default to manual. For counterparty traffic, creative review and media-buy review behave differently: every creative waits, while media buys that are clearly on policy auto-forward and exceptions wait for an operator. Exact own-supply operator actions use the decision semantics above. Approval Mechanics runs before any ad-server write for an item that is pending, so no order or line item is created upstream until that item is approved. One honest nuance:
  • creativeApproval: manual holds every counterparty creative. Each one lands in your queue as pending_review.
  • mediaBuyApproval: manual holds exceptions. Brief Acceptance runs first. Clearly on-policy buys auto-forward; ambiguous results, evaluator errors, and deterministic hard findings enter the operator queue.
The manual-mode create-time pre-screen reads your written acceptance policy against the buy and sorts it into three buckets: clearly on policy (eligible), needs a look, and clearly against an explicit rule you wrote — e.g. a category you stated in plain block language. The first bucket auto-forwards; the other two enter the queue. A deterministic hard finding supplies a strong rejection signal to the operator. The pre-screen reads what you wrote — it is not a fixed category list — so a rule like “we don’t accept fast-food advertisers” is honored even though it isn’t a built-in category. When it cannot judge a buy with confidence, it errs toward queueing it for you. For the full verdict model, the AI second opinion, and the creative fidelity guarantees, see AI Business Rules. In auto mode, the seller’s policy is enforced at product discovery: a confident policy conflict returns no products, while unavailable qualification fails open. create_media_buy then retains the established auto-forward contract instead of introducing a second evaluator gate.

​
Buyer pauses never wait for review

A buyer can pause delivery of a live media buy whatever your mediaBuyApproval setting, and on guaranteed buys too. The pause goes straight to your ad server and never enters your approval queue. Pausing suspends delivery only; it does not change the buy’s budget, flight dates, or contract. When mediaBuyApproval is manual, you receive a storefront.media_buy_buyer_paused notification once the pause is applied, so you know a change reached your ad server without your review. It asks for no action. When mediaBuyApproval is auto, buyer pauses send no notification, the same as any other buyer change you have chosen not to review. A pending change to the same buy, such as a budget change waiting for your decision, does not hold the pause back. It stays in your queue, and when you approve it the buy stays paused. This covers an update whose only change is the pause. A pause combined with any other change follows your normal approval settings. A buyer’s request to resume a paused buy is not covered by this exception: it is reviewed like any other change to a live buy. On an ad-platform storefront with manual review, that means every resume waits for you. On a storefront that forwards to a sales agent, only material changes to the buy’s terms wait for you (for example a budget change, a longer flight, or broader targeting), so a resume on its own goes straight through: it restores terms you already approved. A resume that comes with any material change still waits for you.

​
How you review what’s queued

Pending items wait for your decision — approved forwards the item to the underlying sales agent; rejected carries your reason back to the buyer. You act on the queue three ways:
  • The Approvals widget in chat — your main work surface. It shows both queues (creatives and media buys) with the submitted evidence and pre-screen verdict, and you approve or reject inline. The verdict is the recommendation; the Page does not send you back to chat for another answer. If approval records but forwarding is incomplete, the Page shows that partial success honestly and offers an explicit, confirmation-gated retry in place. A failed retry leaves the retry available. Its Approval routing section lets admins choose a primary approver and optional escalation roles or users, email/Slack delivery, and reminder/escalation timing; until a rule is saved it shows the default — organization admins receive these approvals. Ad-server approvals and inventory shortfall reviews always route to organization admins. The queue includes Mine, Team, Overdue, and Unowned views, and admins can reassign open work to an eligible approver. The Overdue view lists an item that has waited past its deadline, or one that was never routed and has waited longer than your escalation time (24 hours until you save a rule), oldest first. Apostra decides which approvals are overdue or unowned, so the Page and your assistant always agree. If routing settings cannot load, the section stays visible with a retry action; non-admins see that a customer admin must manage it. Ask any compatible assistant to open Approvals (“show me what’s waiting on me”); Apostra, Claude, ChatGPT, and other MCP Apps hosts open the same portable Page.
  • Seller Setup with Apostra — if a managed storefront needs manual approval but has no approver, the go-live checklist blocks that queue and asks Apostra to walk an admin through the decision. Apostra explains the choices, then opens the same Approvals widget for configuration.
  • Ask your assistant — “what needs my approval?” opens the Page. For one exact item, the assistant pulls its details and pre-screen before asking you to confirm an approve or reject decision; rejection also requires a reason.
See Media-buy approvals and Creative reviews for the per-queue mechanics and buyer-facing callbacks.

​
How you find out something is waiting

When a buyer submits a creative or media buy for review, it appears in your Approvals widget and Apostra’s pending list right away, and you also get a notification the moment it lands. In-app delivery always goes to the current approval audience. Email goes only to that audience when enabled on the routing rule — the default (organization admins) delivers in-app and email, so an unconfigured storefront still hears about waiting work. Slack posts once to your configured customer channel when both the rule and the Slack event filter enable it.
If the primary owner becomes inactive, the item moves immediately to the configured escalation audience. If there is no separate escalation audience, the primary audience remains responsible after the deadline. If no eligible approver remains active, the item appears as Unowned for admins to reassign. A reminder is sent before the deadline. Expiry never broadcasts the task to every user and never auto-approves media spend or creative.

​
Retired: per-buyer auto-approval

Per-buyer auto-approval is retired. A buyer can no longer be exempted from your review one by one, and the GET /api/v2/storefront/buyer-auto-approvals and PUT /api/v2/storefront/buyer-auto-approvals/{buyerCustomerId} endpoints and the list_buyer_auto_approvals and set_buyer_auto_approve MCP tools no longer exist. Every buyer’s media buys follow the storefront-wide media-buy approval setting in AI Business Rules. A buyer who had an override is now reviewed like every other buyer: while mediaBuyApproval is manual, a buy that is clearly on your acceptance policy still forwards automatically, and the rest wait for your decision. Creative review was never affected.

​
What’s not configurable yet

Current configuration is storefront-wide auto-or-manual. Dollar thresholds and new per-buyer approval settings are not available.

Media-buy approvals

The pending media-buy queue

Creative reviews

The pending creative queue

Ad-server access

What reaches your ad server — and how approval gates it

Notifications

What does (and doesn’t) generate a notification