Skip to main content
When a buyer transacts against your storefront, you decide how much a human reviews before anything reaches your ad server. Two storefront settings control it, and both default to manual. 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 two settings

Each is storefront-wide and set independently. Configure them by asking Murph to set your approval settings, or with PUT /api/v2/storefront. 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.
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.

​
Manual review: hold exceptions

The default is both settings 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.

​
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 is age-based — an item that has waited past its deadline (or past 24 hours with no owner at all) surfaces there, oldest first. 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 Murph — if a managed storefront needs manual approval but has no approver, the go-live checklist blocks that queue and asks Murph to walk an admin through the decision. Murph 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.
  • REST — GET /api/v2/storefront/media-buy-approvals?status=pending and GET /api/v2/storefront/creative-reviews?status=pending, decided via their respective decide endpoints.
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 Murph’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.

​
Deprecated V2 per-buyer approval

If your existing V2 integration uses per-buyer auto-approval, its behavior is unchanged during the migration window. An enabled override lets that buyer’s media buys bypass Brief Acceptance screening and the human review queue while mediaBuyApproval is manual. Creative review is not affected. Use GET /api/v2/storefront/buyer-auto-approvals or the list_buyer_auto_approvals MCP tool to inspect existing overrides. Use PUT /api/v2/storefront/buyer-auto-approvals/{buyerCustomerId} or set_buyer_auto_approve with enabled: false to revoke one. The retired Page is no longer available. Do not build new integrations on these V2 operations. New clients should use the storefront-wide media-buy approval setting in AI Business Rules.

​
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 and decide endpoints

Creative reviews

The pending creative queue and decide endpoints

Ad-server access

What reaches your ad server — and how approval gates it

Notifications

What does (and doesn’t) generate a notification