> ## 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.
# Reviewing buyer transactions before they go live
> How creative and media-buy approval work, how to require human review of everything (the lowest-risk posture), and how you find what's waiting.
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
| Setting | Controls | Values |
| ------------------ | --------------------------------------------------- | ------------------------------------- |
| `creativeApproval` | Buyer-submitted **creatives** (`sync_creatives`) | `auto` or `manual` (default `manual`) |
| `mediaBuyApproval` | Buyer-submitted **media buys** (`create_media_buy`) | `auto` or `manual` (default `manual`) |
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](/v2/concepts/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](/v2/storefront/media-buy-approvals/overview) and
[Creative reviews](/v2/storefront/creative-reviews/overview) 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.
## Related
The pending media-buy queue and decide endpoints
The pending creative queue and decide endpoints
What reaches your ad server — and how approval gates it
What does (and doesn't) generate a notification