> ## 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.

# Glossary

> Every term you'll hit across the v2 docs — alphabetized, defined in a sentence or two, and linked to the deep guide where one exists.

A fast lookup for the vocabulary of Apostra. Where a term has a
dedicated guide, the definition links to it. For the shape of how these objects
nest, see the [Object Model](/v2/concepts/object-model); for the design choices
behind them, see the [Philosophy primer](/v2/concepts/philosophy).

## A

**AAO (Agentic Advertising Organization)** — The public registry and compliance
pipeline that decides which agents are real. An agent must be **registered** in
the [AAO registry](https://agenticadvertising.org) to be connected as an inventory
source; its compliance verdict is read live and is **informational** — it surfaces
as a warning but does not block a storefront from going live. The registry is the
source of truth, not an Apostra allowlist. See [Identity documents](/v2/concepts/identity-documents).

**AAO compliance** — The registry's computed verdict on an agent: it grades the
agent's self-declared capabilities against AAO test storyboards and returns
`passing`, `pending`, `degraded`, or `failing`. It is **informational** —
a non-`passing` verdict is surfaced prominently but never blocks going live.
Contrast with **authorization** (a publisher's `adagents.json`), which is
publisher-controlled and resolved per publisher: an unauthorized result warns
during setup and product authoring rather than blocking them, while buyer-facing
discovery hides unauthorized publishers and managed product coverage discloses
only the authorized set.
See [Identity documents](/v2/concepts/identity-documents#blocks-vs-informs).

**Brief Acceptance policy** — The content rules in **AI Business Rules** that a Seller Account uses to judge buyer transactions against — which advertisers, categories, and creatives it will and won't carry. The operator authors it in plain language (with Murph); the agent reads what the operator wrote rather than a fixed category list. It is **separate** from the
[approval mode](/v2/storefront/approvals/overview) (`auto` vs `manual`): the policy
is *what* is acceptable, the mode is *whether a human reviews*. The pre-screen
sorts a media buy into clearly-on-policy / needs-a-look / clearly-against-a-rule,
and an AI second opinion can only **downgrade** an auto-approval to human review —
never approve or reject on its own. A deterministic hard match to an explicit
rule supplies a strong rejection signal in the human queue; it does not
auto-reject a submitted buy in the current rollout.
See [AI Business Rules](/v2/concepts/ai-business-rules).

**Account** — A buyer or seller workspace. Buyer accounts hold advertisers and
campaigns; each seller account owns one storefront whether it sells inventory
the operator owns, represents, or manages. An account may begin standalone or
be explicitly attached to an **Organization**. Attachment is what moves
contract, billing, and administrator authority to the organization; a matching
email domain or CRM association does not attach it. A user can belong to more
than one account and switches between them per session. See
[Account Access & Signup](/v2/setup/account-access).

**Account setup** — The setup case for a buyer relationship: billing path,
currency, approvals, inventory mappings, and notes; for a pending buyer, the
admission decision.

**Account type** — **Buyer** to manage campaigns or **Seller** to sell inventory.
A Buyer Account has no sandbox/live lifecycle mode: permission is derived for
the requested operation from identity, Terms, plan and entitlement, standing,
and any transaction route requirements. **Offer a sales agent** is a signup choice that enables
a sales agent offering on an organization for registration and certification;
it is not another account type or commercial approval. Its compatibility API
value is `PARTNER` even though the field is named `accountType`.

**Listing (Seller Account package)** — The Seller Account foundation. It gives you
a **Listing** on Apostra while you bring your own sales agent, plus the
operational record for campaigns, media buys, creatives, approvals, delivery,
activity, and reporting. Its agent source is a `COMPOSING` source. AI Business
Rules are available. Saving, enabling, and evaluating AI Business Rules is not
an IU-rated activity today; other qualifying activity remains governed by the
organization's accepted IU Rate Card.

**Listing + Distribution** — The standard paid Seller Account package for unlimited
self-serve advertiser invitations and management, public listing distribution and an
optional customer CNAME, and customer-branded AdCP and ChatGPT app channels. It does
not improve or rank Apostra listing, enable Merchandising, or replace the
connected sales agent. Existing accepted offers continue to use the advertiser
capacity stated in their terms.

**Activated social account** — A historical v0-v3 Rate Card activity. It
remains readable on an agreement accepted under those catalog versions, but is
not added to a new Rate Card. See **Enhanced Reporting**.

**Enhanced Reporting** — The current Rate Card activity for one exact connected
account in a billing period after its Enhanced Reporting control is enabled and
its existing reporting subscription completes a successful sync. It is 4 IUs
at the standard rate. An enabled account without a reporting subscription or
successful sync draws no IUs. Ordinary connection, synchronization, and
campaign actions are included. Connection and advertiser mapping cost nothing. See the
[Organization IU Rate Card](/v2/buyer/billing/organization-iu-rate-card).

**Activation (Storefront connection)** — The readiness and lifecycle of one
Storefront for one advertiser in a buyer account. Selection and billing policy
remain account-wide; activation is tracked separately for each advertiser as
provisioning, active, action required, waiting on seller, retrying, failed,
retiring, inactive, or not applicable. See
[Storefronts](/v2/buyer/storefronts/overview#manage-storefront-connections).

**Ad platform connection** — One authorization grant against an ad platform
(Meta, Google Ads, TikTok, Amazon Ads, …): "I linked this account." Can be made
at the organization level (a manager account reaching many ad accounts) or the
advertiser level (a single ad account). The connection carries the credential;
the accounts it reaches are discovered from it, and each ad account is then
mapped to one of your advertisers. See
[Ad Platform Accounts](/v2/concepts/ad-platform-accounts).

**Dimension and label** — A **dimension** is a Buyer Account-owned organizing
axis, such as Market or Quarter. A **label** is one of that dimension's values
on an advertiser or campaign. A dimension's immutable `key` appears in the
object's `labels` map; the server-issued `id` addresses the dimension itself.
The built-in open `tags` dimension covers free-form tags. Labels do not grant
authority, change targeting, or select inventory. See
[Dimensions and labels](/v2/object-guides/dimension).

**Ask** — Anything you are waiting on Apostra for. Which part of Apostra picks it
up is its `type`: `support` (something is broken or blocking, or you want a
person), `product` (a capability that does not exist yet), `supply` (inventory
we do not carry), `integration` (a counterparty we do not connect to), or
`commercial` (pricing, terms, billing, or a rate-card exception). Whichever
type it is, an ask carries one status from the same short list — `received`,
`accepted`, `in_progress`, `done`, `closed` — that follows the real work, plus
a label and sentence written for you. Internal workflow states and ticket names
are never shown. Support and supply asks reach `done` before ageing out of the
list; a product ask, and a cancelled supply ask, leave the list rather than
reporting a terminal status. Read your asks by asking Murph, from
`GET /api/v2/asks`, or on `/mcp/v3` with `search({kind: "ask"})` and
`get({kind: "ask", id})` from either a buyer or seller account.

That status is **ours** — where the work stands. You have a separate answer of
your own: `confirmed_resolved`, `accepted`, `still_blocked`, or `withdrawn`.
The two sit side by side rather than one overwriting the other, so "we called
it resolved" and "I am still blocked" both stay visible. Note the two senses of
`accepted`: as a status it means we took the ask into work; as **your** answer
it means you have heard our answer and are not disputing it — which is not the
same as saying you got what you wanted.

Not to be confused with a **buyer ask** in a negotiation (see **Negotiation
posture**), which is a demand-side request inside a deal, not something we owe
you. See [Ask Murph](/v2/setup/ask-murph).

**Supply ask** — An **Ask** of type `supply`: inventory we do not carry, that
you want us to go get. It requires a buyer who can actually spend — a curator
buying on behalf of demand qualifies; a publisher who wants *demand* for their
own inventory does not, because that is a request for buyers rather than for
supply, and counting it would inflate what looks like unmet demand for
inventory. A withdrawn supply ask keeps its record: it stops notifying and
leaves your active list, but it stays as evidence that the demand existed.

<Note>
  **"Demand signal" describes evidence, not an object.** You may see the phrase
  used for what a supply ask *is evidence of* — real demand for inventory we
  cannot yet fill. It is not a thing you create, read, or hold, and it is not a
  kind of **Signal**, which is targeting material a seller authors. Where buyer
  intent is a durable record it is a **Brief**; where it is something you are
  waiting on us for, it is an **Ask**.
</Note>

**Agent Registration** — A WorkOS-managed way for an agent to establish its own
identity. An unclaimed agent can verify its integration in a zero-spend sandbox; an
authorized customer user can later grant the agent organization access. See
[Authentication](/v2/authentication#agent-registration).

**Ad Server** — An operator-owned ad server (Google Ad Manager, FreeWheel,
SpringServe, or AdsWizz) connected as an inventory source. Apostra manages the
sales-agent plumbing in front of it, so buyers transact through your storefront
while the ad server reads its existing inventory, ad units, and placements.
The setup uses either a supported direct integration or an
Apostra-managed sales agent; sellers use the same ad-server connection
surface either way. It stays enabled unless `deactivatedAt` is set, and whether
it is live is derived from its connection status. Contrast with **Sales
Agent**, which is a separate AdCP agent you point at by URL. See
[Choosing a source](/v2/storefront/inventory-sources/choosing-a-source).

**adagents.json** — The file a publisher publishes at
`/.well-known/adagents.json` to declare which agents are authorized to sell its
inventory. Resolution follows three paths: the publisher's own file first; an
**`authoritative_location`** one-hop redirect if that file is a pointer to a
centrally-hosted file (how a network serves one file for many publishers); and a
**manager domain fallback** if the direct file is absent — the domain's `ads.txt`
`managerdomain` is read and that manager's file is used instead, so a network-managed
publisher (e.g. a Raptive/CafeMedia domain delegating to `cafemedia.com`) resolves
even though it hosts no file of its own. Authorization is scoped to the publisher
domain, not mere presence in the file. See
[adagents.json for network sellers](/v2/storefront/inventory-sources/adagents-json)
and [Discover agents](/v2/storefront/tasks/discover-agents#how-adagents-json-resolves).

**AdCP (Ad Context Protocol)** — The open protocol for agentic media buying
that Apostra runs on. AdCP defines how participants discover, negotiate,
and execute (`get_products`, `create_media_buy`, `get_media_buy_delivery`). One
integration on AdCP reaches every counterparty. See
[adcontextprotocol.org](https://adcontextprotocol.org).

**AdCP Collection** — Canonical publisher-declared content identity, such as a
series, publication, event series, or rotation. An AdCP Collection is not a
generic capacity pool, placement, channel, portfolio, monthly grouping, or
parser container. The exact `collectionId`, `collectionName`, and
`collectionDescription` fields in `static-avails-feed:v1` are legacy
compatibility grouping fields; their values do not establish AdCP Collection
identity. See [Publisher domains](/v2/storefront/publisher-domains) and the
[inventory source input guide](/v2/setup/publisher-onboarding-starter-kit).

**AdCP version negotiation** — How a buyer and a source agree on a protocol
version per request. The buyer pins a release-precision version (`adcp_version`,
e.g. `3.1`); the source advertises the versions it speaks (`supported_versions`),
and a conformant source **downshifts** a pin to its highest supported release at
or below the pin within the same major version rather than rejecting it with
`VERSION_UNSUPPORTED` (which is reserved for a cross-major mismatch). See
[AdCP versioning & negotiation](/v2/concepts/adcp-versioning).

**Advertiser** — Apostra's commercial media identity on whose behalf
campaigns run: a **Brand Reference care of an Operator**. This is a product
projection; AdCP keeps Brand, Operator, Account, and Agent separate. A
buyer-declared AdCP account uses `(brand, operator, sandbox)` as its natural
relationship key, while an upstream-managed `account_id` names a seller-owned
namespace entry with a declared `account_scope`. Direct self-serve from an
account registered to the brand's domain means the brand is its own operator
(Coca-Cola care of Coca-Cola); `self-serve` is an interface, not an operator.
When a buyer account has no registered domain, current v2 outbound AdCP calls
temporarily use `interchange.io` as the operator until the real account domain
is recorded. The current v2 advertiser resource is the top-level container for
that identity's media and may partition it by currency and sandbox mode. It
owns a default optimization mode and linked sales-agent accounts; campaigns
live underneath it. See the
[Advertiser guide](/v2/object-guides/advertiser).

**Advertiser grant** — An expiring, accepted authorization from one
organization to another for exact advertiser IDs and reviewed read or campaign
capabilities. The advertiser owner keeps ownership, Campaign IDs, and its
backing account; the grantee never receives account, member, billing,
unrelated-advertiser, future-advertiser, or private-configuration access.
Names, domains, CRM associations, signup history, providers, external Business
Manager membership, and Partner status do not create a grant. See
[Manage organization advertiser grants](/v2/buyer/advertisers/tasks/manage-organization-advertiser-grants).

**Advertiser mapping** — The link between a platform ad account and one of
your advertisers, so campaigns for that advertiser transact on the right
account. Managed on the **Media Partners page**. See
[Ad Platform Accounts](/v2/concepts/ad-platform-accounts).

**Audience** — A target or suppress list attached to a campaign to shape who a
buy reaches. See the [Signal guide](/v2/object-guides/signal).

**Audience facts** — Seller-provided statements about who a product's
audience is, taught as **Selling points** from your **Product marketing**
material and matched onto a proposal's merchandise block by the product's
channel and creative format (a claim scoped to both must match both). Each
fact carries the seller's own source alongside it — a verbatim document
quote, or a plain statement that the seller told us this — never something
Apostra has independently verified. We present audience facts as your claims,
not as findings of our own; where you haven't taught one for a product yet,
the proposal says so rather than describing the audience generically. See
[Product marketing](/v2/storefront/product-marketing/overview).

## B

**Bid Decision** — The qualification judgment a storefront makes before it
composes anything: **pitch** the brief in full, **counter-pitch** it with a
credible reframe of the ask, or **pass** with a short branded decline. Decided
against the seller's Selling Doctrine and recorded on the proposal pass with
the doctrine version and the rule that reached it. A pass withholds the composed
proposal and returns the storefront's existing no-fit response shape, so a
buyer cannot tell a decline from nothing having matched. Passthrough inventory
and already-finalized proposals are a different lane the doctrine never judged
and still ship; the decline itself is recorded seller-side. See
[Selling doctrine](/v2/storefront/operating-instructions/selling-doctrine).

**AI Business Rules** — The seller Page for what a storefront accepts and when a
person reviews it. It combines the versioned advertiser, category, and creative
Brief Acceptance policy with the current creative and media-buy approval gates. The
policy says what is acceptable; a gate says whether human review happens. See
[Seller Pages](/v2/setup/seller-pages#business-rules--what-you-accept).

**Brand / Brand Reference** — Whose products are advertised: name, assets,
safety posture, and story. A brand becomes an **Advertiser** only in an operator
context (`BrandRef × Operator`); the same brand may therefore participate in
more than one advertiser identity. The brand reference is the structured form
sellers and creative agents read. See the [Brand Story guide](/v2/object-guides/brand-story).

**Brand domain** (previously called the operator domain) — The domain where a
seller's identity lives: where Apostra picks up the logo and company
description (via **`brand.json`** / AAO), used to resolve the seller's
**listing**. Confirmed on the storefront, distinct from a buyer account's
**operator domain** (see **Operator**) and from the WorkOS organization
domains used for sign-in, SSO, invitations, and membership. See
[Domains](/v2/concepts/domains) and [Seller Pages](/v2/setup/seller-pages).

**Public listing domain** — The hostname, a CNAME onto Apostra, on which a
storefront's public listing and any channel app built on it (such as a ChatGPT
app) are served and verified. Entered and verified inside **Public
distribution**, the Listing page's fourth step. Distinct from the **Brand
domain** (where `brand.json` lives) and from **Publisher domains** (the
properties a storefront sells).

**Brand hierarchy (`house` / `keller_type` / `parent_brand`)** — The corporate
structure a brand declares in its `brand.json`: the `house` it belongs to, its
`keller_type` (`master`, `sub_brand`, `endorsed`, or `independent`), and its
`parent_brand`. Seller Accounts resolve a buy's brand and operator up this hierarchy
to apply a [house discount](/v2/storefront/house-discounts/overview) — a discount
keyed to a corporate house (e.g. `nike.com`) that reaches every brand and operator
rolling up to it. See [Identity documents](/v2/concepts/identity-documents).

**Budget (gross)** — Every budget a buyer sets — campaign `budget.total`,
per-product budgets on a media buy, package budgets — is **gross**: the
fee-inclusive, all-in amount the buyer pays. Apostra fee is carved out
inside it at the **Fee terms** locked when each media buy was created, and the
split is readable via the media buy's `budget_breakdown`. Delivered spend on
buyer surfaces is gross too — except on legacy media buys created before fee
terms were locked, which report delivered spend net, as the seller reported
it, and carry neither `budget_denomination` nor `budget_breakdown`. See
[Budgets and fees](/v2/concepts/budgets-and-fees).

**Buyer Account Mapping** — The seller-side record for one exact operator-and-brand
buyer relationship on a Seller Account, with private mappings to the native accounts
used by its inventory sources. Legacy v2 operation names retain `seller_account`
for compatibility, but those records are buyer relationships — not Apostra
**Seller Accounts** or **Connected provider accounts**. See
[Buyer Account Mapping](/v2/storefront/buyer-account-mapping).

**Buyer discount** — A discount a Seller Account sets for an advertiser, applied at
product discovery. An advertiser has two facets, so a
[house discount](/v2/storefront/house-discounts/overview) is keyed to one axis: a
**brand discount** (the advertiser's brand or its house — `coke.com`,
`nike.com`) or an **operator discount** (the advertiser's buying agency/DSP or
its house — `groupm.com`, `wpp.com`), each resolved up the brand hierarchy.
Within an axis the nearest ancestor wins; across axes the larger discount wins
(tie → brand). The narrower cases — an exact brand-and-operator advertiser,
country terms, or freeform notes — live in a
[buyer instruction](/v2/storefront/buyer-instructions/overview). When both
match, the larger applies; either is floored at the Seller Account's wholesale cost.

**Billing (`agent` vs `operator`)** — The two ways a media buy is settled.
The buyer Connections view labels **`agent`** as **Consolidated** and
**`operator`** as **Direct**. **`agent`** (Apostra-cleared): Apostra invoices the buyer and pays the seller by
bank transfer, net of fees — this requires the seller's **Payout details** on
file. **`operator`** (seller-cleared): the seller bills the buyer under their own
external agreement; Apostra moves no media money. Normal Seller Accounts are
Apostra-cleared today. Seller-cleared settlement for Seller Accounts is planned but
is not configurable yet; existing official sales-adapter arrangements are the only
current exception. See the
[seller billing overview](/v2/storefront/billing/overview) and the
[buyer billing overview](/v2/buyer/billing/overview).

**Billing mandate** — A seller-specific commercial relationship that records
who sells and is paid, who operates, who is liable to pay, who holds payment or
invoice authority, and which exact advertiser or reviewed advertiser set the
terms cover. Its `billingMandateReady` projection is tracked separately from
advertiser access and supplies only necessary mandate evidence to a later
composing workflow. It never grants complete billing, proposal, Campaign,
execution, or spend authority and does not prove a funded or invoice rail. It
contains typed internal evidence references and audit evidence, not structured
credential fields. Recognizable credential and bank-account literals are
rejected from caller-authored free text, where credentials must never be placed;
semantically unknowable bare identifiers are not treated as credentials. See the
[seller billing overview](/v2/storefront/billing/overview#seller-specific-billing-mandates).

**Billing policy (Storefront connection)** — The account-wide choice of
Consolidated or Direct media billing for one buyer account and Storefront.
Direct billing acceptance is separate from Storefront selection and applies to
current and future advertisers. The policy becomes read-only when Apostra
sends the first activation for an eligible advertiser. See
[Storefronts](/v2/buyer/storefronts/overview#manage-storefront-connections).

**Bring/build your own buyer agent (BYOBA)** — Using software your organization
builds or operates as its buyer interface to Apostra. BYOBA is an entry
point, not a customer segment, plan, discount, or wallet. A BYOBA workload uses
the same [Organization IU Rate
Card](/v2/buyer/billing/organization-iu-rate-card) as the organization's other
buyer, Seller Account, and Murph activity.

**`brand.json`** — The file a brand or operator publishes at its own
`/.well-known/brand.json` to declare the agents it **owns and runs** (role-typed,
each with a `jwks_uri` signing-key root) and its corporate **brand hierarchy**. It
is the demand/operator-side identity document — distinct from `adagents.json`'s
supply-side authorization. See [Identity documents](/v2/concepts/identity-documents).

## C

**Campaign** — A unit of buying owned by an advertiser, labeled with a
`mode` (`discovery`, `performance`, or `directed`) and a `management` state
(`tracked` or `managed`). Managed campaigns use the canonical buyer product and
media-buy lifecycle; tracked campaigns are read-only shells mirrored from a connected
provider account the platform did not set up. Planning inputs (brief, objective)
belong to the `discovery` and `performance` modes, not to `managed` as a
class. A campaign that projects exactly one Seller-authoritative media buy
may come from a provider-account mirror (tracked) or a direct AdCP Seller
request (managed). Tracked projections are read-only; managed buys
use the canonical buyer media-buy lifecycle. See the
[Campaign guide](/v2/object-guides/campaign).

**Channel group** — One named, coherent inventory selection inside a campaign,
defined with AdCP channel, property type, device type, and canonical format
kind values. It is a media-buy compilation and reporting boundary: each group,
seller, and settlement-currency combination becomes a separate media buy. A
name such as “mobile web display” is an alias for its full inventory definition,
not a new AdCP channel. See [Channel groups](/v2/buyer/campaigns/channel-groups).

**Cancellation approval** — The seller approval required when a buyer cancels a
committed guaranteed media buy. The buy keeps delivering while the Seller Account
operator decides: approving terminates the buy (the cancel is forwarded to the
source); rejecting keeps it active. Non-guaranteed and uncommitted buys cancel
directly with no approval. See
[Media buy lifecycle: Cancellation](/v2/concepts/media-buy-lifecycle#cancellation).

**Capability health observation**: one health check's reading on one
inventory source's `inventory` or `reporting` capability, carrying `status`
(always `healthy`, `degraded`, or `unhealthy` — never a null or unknown
reading), what it saw last time (`previousStatus`), a machine-readable `cause`
and human-readable `detail`, who can act on a failure (`owner`), and when it
was observed (`observedAt`, `lastOkAt`). `capabilityHealth.inventory` /
`.reporting` on [storefront readiness](/v2/storefront/tasks/get-readiness) and
[source diagnostics](/v2/storefront/inventory-sources/diagnostics#capability-health-observations)
each carry a derived `status` (the current verdict for that axis, computed
across every observer and discounting stale readings) alongside the
`observations[]` evidence behind it, so two checks can disagree and both stay
visible even though `status` still gives you one answer, and an axis nothing
has ever reported on reads `null` rather than healthy.

`unhealthy` is the compatibility wire value for the human-facing **Erroring**
state. Source Health surfaces otherwise use **Healthy**, **Degraded**,
**Erroring**, and **Unknown** consistently. The separate `condition` identifies
what happened: a `timeout` means an observer budget expired and is degraded
evidence, whereas `error_response` means the Source returned an error.

This page uses two different conventions for "nothing has reported," because
they describe two different fields. `capabilityHealth.inventory.status` /
`.reporting.status` use `null`. The older, singular `source.health.status`
cell — one collapsed reading per source, predating the per-capability
observation set above — still uses the string `unknown`, and keeps doing so
for as long as that cell exists: it reads from a different, single-value
column that this observation model does not replace.

**Catalog** — An advertiser's structured list of what it sells — products,
offerings, job openings, hotels, listings — synced onto the advertiser so
sellers can build ads from the real items (names, prices, images) instead of a
static banner. A catalog arrives as a feed: either a remote `url` the platform
re-fetches on a schedule, or `items` supplied inline (never both). Items pass
validation and per-item review, and campaigns and creatives then reference the
catalog. For a Shopify store, the product-export CSV from the Shopify admin is
a supported feed as-is (`feed_format: shopify`). See the
[Catalog guide](/v2/object-guides/catalog).

**Catalog activation** — The lifecycle that turns a synced catalog into
campaigns: save a **transform** (rules that fan items out into campaign groups,
budget hints, and creative prompts), **preview** the resulting plan, **execute**
it into campaign and creative-generation jobs, and **refresh** the feed to pick
up changes. A catalog has exactly one active transform at a time. See
[Save catalog transform](/v2/buyer/advertisers/tasks/save-catalog-transform).

**Channel guest** — A person who can remain in a connected support channel
without becoming a member of Apostra account. Channel guests cannot
use account data or make account changes unless they separately receive an
account membership. See [Review support channel participants](/v2/features/channel-participant-review).

**Community fallback (community mirror)** — A copy of a publisher's
`adagents.json` that the AAO registry hosts so an unpublished publisher is still
discoverable. A community mirror lists **no** authorized agents — it exists to be
*found*, never to *authorize*, so an empty mirror is not a denial. An
owner-published document always supersedes it. This is different from an
AAO-hosted publisher document, where AAO hosts the publisher's configured document
and the publisher origin must verify it with an `authoritative_location` stub. See
[Identity documents](/v2/concepts/identity-documents#the-aao-registry-is-not-a-document).

**Component / Inventory component** — The raw material a source exposes — avails,
ad units, placements, creative assets — before it is packaged for sale. A
component is unpackaged and **not directly sellable on its own**; it is the
*stock* that flows through a source (the pipe), and it is discovered rather than
authored. Components are composed into **Products** at discovery time. Contrast
with **Product** (component plus business rules), with **Wholesale product** (a
product you author, which *is* directly sellable), and with **Source** (the
connection that carries the component). The raw targeting material on the signal
side has its own name — **Ad-server targeting** — because what a seller authors
from it is a **Signal**, not a component.

<Note>
  **Component or selector?** The same ad unit is both, in different roles. It is
  a **component** when you are deciding *what to sell* — the material a source
  exposes and merchandising composes. It is a **Selector** when you are telling
  the ad server *where to run* — an execution address. If the sentence is about
  packaging, say component; if it is about addressing, say selector.
</Note>

**Component cache** — The cached raw products/components Apostra reads from
an inventory source when merchandising is enabled or when wholesale-mode reads
need source material. Cache success means the source returns stable component
ids, names/descriptions, pricing, formats, publisher properties or selectors,
delivery type, and execution metadata. A cache complaint is not the same as a
live passthrough failure.

**Comparative Proposal Ranking Pass** — A managed comparison of up to 100
accepted proposal candidates under buyer instructions. It returns a score,
rationale, and ordering without changing seller-authored proposal fields. The
meter is currently calibrating and reports no charged IUs. See
[Evaluate proposals across storefronts](/v2/buyer/discovery/multi-storefront-get-products#evaluation-metadata-and-cost).

**Composition vs Passthrough** — Two ways the platform handles a buyer intent.
*Composition* means the storefront agent builds a proposal from cached
components, operating instructions, pricing, and policies. *Passthrough* means
the request flows straight to a single sales-agent source. These are concrete
execution mechanisms, not `DECISIONED` / `ROUTED` storefront types; use explicit
source capabilities and authentication requirements to distinguish them.

**Connection** — A specific organization linking its own account on an existing
**Integration** — self-serve, no engineering involved. Connecting a Snap ad
account or a Google Ad Manager network is a connection; the integration that
makes Snap or GAM connectable at all is the separate, Apostra-built thing.
Seller connections are managed on the **Media Partners page**; creative, data and
measurement, and cloud-drive provider connections are managed under
**Settings → Connections**.

**Connected provider account** — A buyable external account exposed through a
**Connection**, either from an ad-platform integration or a registered AdCP
Seller source (called a `storefront` source in legacy v2). It remains owned and
operated in the upstream provider,
where its campaigns are authoritative. A buyer can map it to an Apostra
**Advertiser** and, where supported, subscribe to read-only **tracked
campaigns** mirrored from it. It is not an Apostra **Seller Account**.

**Corporate IU discount** — One plan-wide percentage discount authorized for a
billing organization. It applies to the organization's shared IU plan across
buyer, Seller Account, Murph, and other rated workloads; it is not a Seller Account
**Buyer discount** and does not stack. Plan & Billing shows list and effective
prices before acceptance. See the [Organization IU Rate
Card](/v2/buyer/billing/organization-iu-rate-card).

**Coverage** — The set of publisher domains or properties a product can run on.
For managed network storefronts, run-of-network coverage comes from the
storefront's authorized publisher properties, usually resolved from
`adagents.json`; when coverage disclosure is enabled, `get_products` surfaces it
as `publisher_properties`. See
[Publisher properties and coverage](/v2/storefront/inventory-sources/publisher-properties-coverage).

**Creative engine** — An AdCP creative service that declares generation and
transformation capabilities. Models and provider-specific controls belong to
those capabilities. A V3 `creative_engine` is the catalog entry; a `connection`
is an organization's authorization grant to it. The
[Creative Engines backend preview](/v2/setup/v3/creative-engines) provides
discovery, connection setup, campaign-scoped session reads and saves, and
explicit generation or named-parent refinement for enrolled Buyer Accounts.
The Creative Engines Page lets those accounts browse registered engines and
manage their connections. This is an alpha workflow: a saved engine connection,
account access, and applicable provider funding are still required. Saving a
session does not start generation, and finalising a creative does not approve it
for a seller or launch a campaign.

**Creative review (Publisher approval)** — The gate a buyer's creative passes
through before it serves on a publisher's inventory. There are two independent
gates: a **storefront operator review** (when the publisher has `creativeApproval:
manual`, a human on their ops team approves or rejects each creative) and a
**source system review** (the publisher's ad server accepts or rejects the creative
after it is synced). Both statuses are visible to buyers on `get_campaign`. See
[Creative approval](/v2/buyer/creatives/approval).

**Creative source** — A source whose components are creative assets: a creative
library, asset feed, or a generation and approval workflow the Merchandising
Agent draws on when answering a brief. A peer source type alongside inventory
and signal sources. See [Choosing a source](/v2/storefront/inventory-sources/choosing-a-source).

**Credentials (source)** — A buyer's registered account for one inventory
source, used where that source requires per-buyer authentication. Registered
via `POST /sales-agents/{agentId}/accountCredentials`. See the
[Storefront guide](/v2/object-guides/storefront).

**Credit line** — An Apostra-granted spending ceiling beyond an organization's
funded balance, carried on its **Standing** as `creditLimit` (minor currency
units, absolute — not monthly). A `null` or `0` `creditLimit` means the
organization has **no credit line**: it can still spend a **funded balance**,
but no credit is fronted until Apostra grants a positive limit — apply for credit
or contact Apostra. Contrast with **Prepay**.

## D

**`DECISIONED` / `ROUTED` compatibility field** — A temporary, lossy billing
observation derived from the media buy's authoritative AdCP BillingParty fact
for legacy rate-card and ledger compatibility. It is not a Seller Account,
execution, campaign, or authentication type and is never a client input. The
deprecated `supportedRoutingTypes` v2 response field is a behavior-free
placeholder and must not be used for eligibility. See the
[Campaign guide](/v2/object-guides/campaign).

**Default account** — The ad account a platform connection uses for new buys
when a request doesn't name one. One per connection; set automatically when the
grant reaches exactly one buyable account, otherwise chosen on the Connections
tab. Organization (manager) accounts can never be the default. See
[Ad Platform Accounts](/v2/concepts/ad-platform-accounts).

**Document category (Library)** — A seller-set label that helps the storefront
agent decide when to use a Library document: Sales deck, One-sheet, Case study,
Response, Specification sheet, or Uncategorized. Topics, audiences, and
verticals are set separately. See
[Library document categories](/v2/storefront/library#document-categories).

**`delegation_type`** — A field on each entry in a publisher's `adagents.json`
`authorized_agents[]` describing *how* authorization flows: `direct` (the agent
sells directly), `delegated` (authority delegated to another party), or
`ad_network` (network-level authorization). See [Identity documents](/v2/concepts/identity-documents).

**Delivery** — The reported metrics that roll up per package — `impressions`,
`spend`, `clicks` — following the AdCP `get_media_buy_delivery` schema.

**Destination** — A place where buyers find a storefront's **Listing**, or
where the account's own linked, active Apostra members reach Murph,
shown as a tab in **Distribution**: the **Listing card** (a PDF, available to
every storefront); buyer-facing app destinations (the **ChatGPT app** and
Claude), which unlock once **Public distribution** (the Listing page's
fourth step) is live; and messaging destinations (Slack, Microsoft Teams,
Discord, and WhatsApp), which are never gated by Public distribution because
they let the account's own team — not buyers — talk to Murph. Adding an app
or branded messaging destination is a prerequisite-plus-artifact flow — what
the destination needs, then the thing you take away (a download, a request,
a published token). See [Seller Pages](/v2/setup/seller-pages).

**Directed campaign** — Deprecated vocabulary. `mode: "directed"` survives as a
compatibility wire value for campaigns that project exactly one
Seller-authoritative media buy (one upstream campaign, one AdCP media buy,
one campaign shell); the concept it named is now expressed by the campaign's
`management` state — **tracked** when mirrored from provider-side activity,
**managed** when authored through the canonical buyer lifecycle against one Seller. See
[Campaigns on connected provider accounts](/v2/buyer/campaigns/directed-campaigns).

**Discovery Session** — A refinable product-search conversation a buyer runs
against sales agents. It produces ranked proposals the campaign selects from.
See the [Discovery guide](/v2/guides/discovery).

**Distribution** — The set of **destinations** where buyers find a
storefront's **Listing** and where the account's own linked, active
Apostra members reach Murph: the Listing card everyone has; buyer-facing
app destinations (the ChatGPT app today, plus Claude) that unlock once
**Public distribution** (the fourth step on the Listing page) goes live; and
messaging destinations (Slack, Microsoft Teams, Discord, and WhatsApp), which
are never gated by Public distribution — they are how the account's team,
not buyers, talks to Murph. The Distribution package is the paid upgrade a
storefront adds to unlock its own **public listing domain** and the
ChatGPT/Claude destinations; it does not change ranking or presence in the
**Apostra marketplace**, which is its own switch (Listing step three),
and it has no bearing on messaging destinations. A storefront that hasn't
published yet is a state, "Not listed yet," never a step to select, and an
already-listed storefront returns to it by turning off the **Listed on
Apostra marketplace** switch (step three), with confirmation, on the
**Listing** seller UI page. See
[Publisher domains](/v2/storefront/publisher-domains#discovery-publication-origins)
and [Seller Pages](/v2/setup/seller-pages).

**DSP advertiser (Amazon)** — An Amazon DSP advertiser account: programmatic
display, video, and CTV bought through Amazon DSP. A separate system from
**Sponsored Ads profiles** under the same Amazon Ads login; one connection
surfaces both, typed `dsp` vs `sponsored_ads`. See
[Ad Platform Accounts](/v2/concepts/ad-platform-accounts).

## E

**Endorsement** — Your mark that a [Pair](/v2/storefront/library#responses-and-pairs)
is a good answer to its brief. Endorsed pairs can shape later responses; removing
the endorsement keeps the pair and its commentary.

**Effective gross CPM** — A media buy's gross budget ÷ its impression goal ×
1000: the buy's all-in price per thousand impressions (for a buy priced at a
single fixed seller CPM, this works out to `seller CPM ÷ (1 − fee rate)`). Use
it for "budget ÷ CPM = impressions" math on gross budgets; returned as
`effective_gross_cpm` in a media buy's `budget_breakdown`, `null` when the buy
has no positive impression goal or no gross budget. See
[Budgets and fees](/v2/concepts/budgets-and-fees).

**External advertiser** — An advertiser operated by a buyer and connected to
your storefront over AdCP. You see the buyer's activity with you, never their
campaign container.

**Platform-license overlay** — An optional license added to the same base
platform and organization IU plan when contracted governance, SSO,
integrations, support, SLA, or sized service capacity is needed. It is not a
separate IU wallet or a second self-serve plan; "Enterprise" is only a working
commercial name. See the [Organization IU Rate
Card](/v2/buyer/billing/organization-iu-rate-card).

**Event Source** — A conversion-tracking source (pixel, server event)
referenced by event-based optimization goals so the platform can optimize
toward real outcomes. See the [Campaign guide](/v2/object-guides/campaign).

## F

**Fee terms / Fee rate** — The commercial terms on a buyer's Apostra contract,
resolved from its rate card. Today's fee terms are a **fee rate** — a percent
of spend, carved out *inside* the buyer's gross budget.
The rate locks per media buy when the buy is created (the way the FX rate
locks); later contract changes affect new buys only. Sellers never see a
buyer's fee rate. See [Budgets and fees](/v2/concepts/budgets-and-fees).

**Format (canonical)** — The AdCP 3.1 way to identify a creative format: a bare
`format_kind` enum value (`image`, `html5`, `display_tag`, `image_carousel`,
`video_hosted`, `video_vast`, `audio_hosted`, `audio_daast`, `native_in_feed`,
`sponsored_placement`, `responsive_creative`, `agent_placement`, `custom`) with
**no `agent_url`**. Parameters — including video/audio duration — live in `params`
(`duration_ms_exact` for a fixed value, `duration_ms_range` `[min, max]`). On a
product these appear in `format_options[]`; on a package, via `format_option_refs[]`
or a direct `format_kind` + `params`.

For a newly executed or resubmitted package containing one unambiguous
fixed-size image creative, Apostra narrows a broad canonical `image`
selector to that creative's `width` and `height`. During the legacy migration
window, a dimensionless AAO image ref such as `display_image` may be sent beside
the canonical selector with the same inline dimensions. Concrete legacy sizes
and seller-specific format refs are preserved rather than rewritten.

A `duration_ms_exact` value names a **nominal spot length**, not a
frame-exact requirement — see [Pinned duration](#p). A `duration_ms_range` is
enforced exactly as written.

**Format reference (legacy / v1)** — The older way to identify a format: a
structured object `{ agent_url, id }` (e.g. `{ "agent_url":
"https://creative.adcontextprotocol.org", "id": "video_vast" }`), optionally with
`width`/`height`/`duration_ms`. Sent on the wire as `format_ids[]`. Supported
through the deprecation cycle but being replaced by the canonical `format_kind`
path. A package may temporarily carry both representations during compatibility
bridging, and their parameters must agree. `video_standard` and
`display_300x250_html` are legacy ids, not `format_kind` values.

**Format Option ID** — A stable identifier a seller publishes on a product's
`format_options[]` entry so buyers can pin a specific option via
`format_option_refs[]`. Required when a product has multiple options sharing one
`format_kind`.

**Frequency Cap** — A buyer-side limit on how often a person sees an ad, set on
the campaign or advertiser and enforced by Apostra across all publishers in the
campaign — distinct from publisher-side caps in package overlays. Shape:
`{ "max_impressions": 5, "window": { "interval": 7, "unit": "days" } }`.

**Funded balance** — Money an organization has prepaid and Apostra currently
holds for it. Spend draws down the funded balance first; a **Credit line** (when
granted) is what spend may run beyond it. An organization with a funded balance
but no credit line is on **Prepay**.

## G

**Grant** — One authorization of ad platform access: who authorized it (the
platform user, plus the organization where the platform has one) and which
accounts it can reach. A grant is what an **Ad platform connection** row
represents; relinking with the same platform user and organization updates the
existing connection in place rather than creating a duplicate. See
[Ad Platform Accounts](/v2/concepts/ad-platform-accounts).

## I

**Imported brief** — A historical RFP added with `origin: imported`, rather
than received as live or uploaded demand. It can form a [Pair](/v2/storefront/library#responses-and-pairs)
but is excluded from the Demand Inbox scoreboard. See
[Demand inbox](/v2/storefront/demand-inbox#importing-a-historical-brief).

**Inbound AdCP campaign** — A directed buyer campaign created when an external AdCP
client calls an enrolled Apostra-hosted Seller. The Seller Account manages the
1:1 buy; Apostra anchors buyer identity, advertiser, contract terms, governance,
journal, and reporting identity, then records accepted commitments and delivery on
its ledger. It projects as `mode: "directed"`. *Inbound* describes the protocol door,
not a fourth campaign mode. See
[How Apostra uses AdCP](/v2/concepts/adcp-on-the-buy-side#external-buyer-to-apostra-to-seller-alpha).

**Intelligence Unit (IU)** — A billing unit for metered intelligent work on Apostra, rather than a raw model token or a unit of media. One billing
organization uses one IU plan, corporate discount, rollover policy, and wallet
across buyer, Seller Account, Murph, and other rated workloads while preserving
usage attribution for each. The standard IU Rate Card is not yet published in
production. New Rate Cards have three published activities: Brief response,
Enhanced Reporting, and Interchange media buy. A Rate Card accepted
under an earlier catalog keeps its original terms. During the controlled pilot,
a published activity may draw from the accepted IU balance and appear as usage
while monetary charging, invoices, and payment collection remain off. Monetary
charging begins only when it is explicitly switched on for the organization. See
the [Organization IU Rate Card](/v2/buyer/billing/organization-iu-rate-card).

**IU wallet** — The billing organization's shared pool of committed,
pay-as-you-go, and eligible credit lots used by every IU-rated workload. Usage
remains attributed by buyer, Seller Account, Murph, advertiser, and capability even
though the balance is shared. A credit lot may carry its own expiry — the
planned 100-IU setup credit runs for 60 days — and a lot can in principle
restrict what spends it, though no current lot does.

**Integration** — A platform capability Apostra builds to speak an external
system — Google Ad Manager, CitrusAd, and the like. Only Apostra can add one; it
is engineering work, not a customer action. An AdCP-speaking sales agent needs
no integration at all — the protocol itself is the integration. Contrast with
**Connection**, the self-serve act of linking a specific organization's account
on an integration that already exists.

**Apostra** — Apostra's operated platform where buyer agents and seller
storefronts transact on AdCP. AdCP is the protocol; Apostra is how it
runs at scale — adding trust, identity, billing, legal, and observability.

**Inventory Source** — A source that provides supply (ad space) to a Seller Account.
Comes in four kinds, distinguished by `executionType`: **Ad Server**, **Sales
Agent**, **Modular source**, and **Linked source** (each defined in this
glossary). A Seller Account can connect several. An inventory source can answer live
passthrough calls, expose cached components for merchandising, or both. See
[Choosing a source](/v2/storefront/inventory-sources/choosing-a-source).

## L

**Library** — The Material and responses a seller uses to sell, including
paired proposals, endorsed examples, and reusable slides. It is the canonical
home for [product marketing](/v2/storefront/product-marketing/overview), not
the advertiser creative library buyers use for campaign creatives. See
[Library](/v2/storefront/library).

**Library request** — A recorded gap the storefront agent encountered while
answering a brief. The agent files one request for each gap; close it by
uploading the missing material or telling the storefront agent what to use. See
[Library requests](/v2/storefront/library#library-requests).

**Learned default posture** — The **Negotiation posture** the Merchandising
Agent has saved as its own default — the first rule it writes for itself.
Persisted once a posture has been converting consistently, and only when the
gated, off-by-default learning loop is enabled; it is durable and visible in
seller analytics. The agent applies it only as a *fallback* when it has no
fresher read for the buyer in front of it, so your **Operating Instructions**
always take precedence. See [Seller analytics](/v2/storefront/analytics).

**Linked source** — An inventory source whose supply comes from the platform
rather than from your own ad server or agent — the curation use case. Linked
inventory is discovered automatically from the ambient pool of LISTED,
transacting Sellers and resolved at runtime, so there is no source row to
create or manage; you participate by being LISTED. Registered logically as
`executionType: LINKED_STOREFRONT`. See
[Choosing a source](/v2/storefront/inventory-sources/choosing-a-source).

**Listing** (previously called the media kit or Discovery Card) — The seller
identity buyers see in Marketplace: resolved name/logo, short description,
website, channels, and accepted countries. Managed storefronts declare
coverage; a pure pass-through storefront uses
upstream capabilities and leaves unknown fields unknown (a mixed or
BOTH-capable storefront declares coverage locally for its Storefront-built
sources). A channel app listing — for example the
ChatGPT app listing — is a read-only projection of it, not a separate object.
It may also show optional **Advertising Policies**: selected public Business
Rules text for a Seller Account on Listing or Merchandising. Source-native AdCP
policies from a connected sales agent remain independently applicable; a
legacy pure pass-through storefront without local rules shows only that
upstream disclosure. The listing is a storefront projection, not a V3 noun.
Not to be confused with the plan-catalog sense of "listing" used elsewhere for
IU rate cards. "Media kit" is retired for this object — see the
industry-collision note under **Media kit** below. The deprecated `media_kit`
V3 compatibility kind is a different, older object (Business Profile) that the
v3 agent surface now also spells `listing`; see **`media_kit` (retired API
name)** below for that alias. See [Seller Pages](/v2/setup/seller-pages).

The buyer-visible Listing object is distinct from the Seller Account package
also named Listing. The object is what buyers see; the package governs the
seller's access to Apostra tools.

Sellers manage it on the **Listing** page (the retired Branding &
distribution page redirects here) as four steps completed in order:
Identity, What you do, Listed on Apostra marketplace (a switch), and
Public distribution — the gate for the ChatGPT app and Claude **Destination**
tabs (not for the Listing card, and not for messaging destinations, which are
never gated by it). See [Seller Pages](/v2/setup/seller-pages).

**Listing card** — A downloadable PDF of a storefront's live Listing, always
available as the first tab in **Distribution**, whether or not the
Distribution package is added. It always matches what is currently live.

## M

**M2M application** — An organization-owned OAuth client for a deployed backend
integration. It exchanges a client ID and secret for short-lived access tokens;
organization admins can add a replacement secret, test it, and revoke the old one.
See [Authentication](/v2/authentication#m2m-applications).

**Managed audio source** — An inspected WAV or MP3 a buyer uploaded to private
Apostra storage, held under an opaque owner-scoped `source_uid` rather than
a URL. Its bytes stay private. A **promoted** source is eligible for a
server-issued, bounded, revocable hosted HTTPS publication. Its adoption
contract is available only when both the account capability and bounded origin
are explicitly enabled. When enabled, it returns opaque identities and the
hosted asset URL, never a storage reference; a
campaign association records manifest membership only and never sends to a
seller or destination, attaches to a media buy, or makes anything live.

**Managed campaign** — A campaign with `management: "managed"`: authored or
adopted through the platform spine (`get_products` → `create_media_buy` →
`update_media_buy`), whether the buys came from discovery, an objective, or the
buyer addressing one Seller by name. The platform sends instructions down;
the execution system remains the source of truth. Contrast **tracked
campaign**.

**Managed video source** — A large video a buyer uploaded directly to private
Apostra storage, held under an opaque owner-scoped `source_uid` rather than
a URL. The bytes stay private: a source becomes deliverable only once it is
**promoted** and published as a bounded, revocable hosted HTTPS URL — the value
a creative uses, whether you assemble the creative by hand around that URL or
adopt the source directly with `adopt_managed_video_source`. See
[Video creatives](/v2/concepts/video-creatives).

**Management state** — The campaign axis (`management: "tracked" | "managed"`)
that answers who may act on the campaign. It is independent of where truth
lives: in both states the Seller's execution system is authoritative and
the platform reflects it. Distinct from the older phrase *platform-managed*,
which describes the `discovery` and `performance` modes (the platform selects
and allocates); every platform-managed campaign is `management: "managed"`,
but so is a buyer-authored single-Seller campaign.

**Manager account** — A platform's organization-level container: Google MCC,
Meta Business Manager, TikTok Business Center, Snap Organization, Reddit or
Spotify Business, LinkedIn Organization. It reaches the ad accounts under it
but is not itself buyable — Apostra lists it for context (typed
`organization`) and expands the accounts under it into individually mappable
ad accounts. For an agency, one manager-account **Grant** links the whole
client portfolio — see the
[agency setup runbooks](/v2/guides/connecting-ad-platforms#agencies-link-the-manager-account).
See [Ad Platform Accounts](/v2/concepts/ad-platform-accounts).

**Manager domain** — The domain a publisher delegates to when a network manages
its `adagents.json` centrally. A managed publisher can point to the manager with
an `ads.txt` `MANAGERDOMAIN=<domain>` line or an `authoritative_location` stub;
Apostra resolves that manager file to find the publisher's properties and
authorized agents. See
[adagents.json for network sellers](/v2/storefront/inventory-sources/adagents-json#manager-domain-delegation).

**Material** — Seller-owned evidence or teaching input saved through the v3
agent surface, such as a media kit, deck, image, site, spreadsheet, inline
note, or historical reference. Each source refresh is an immutable revision;
Material can inform composition but does not own products, inventory, pricing,
Playbook instructions, or AI Business Rules. See
[Seller workflows](/v2/setup/v3/seller-workflows#add-and-inspect-seller-material).

**MCP (Model Context Protocol)** — The tool-calling protocol an AI agent uses to
drive Apostra. v2 exposes three composite MCP tools — `health`,
`ask_about_capability`, `api_call` — rather than a tool per endpoint.

**Measurement endpoint (`ping.apostra.com`)** — Apostra's first-party endpoint
that the auto-injected impression (`/agentic/imp`) and click (`/agentic/clk`)
trackers fire to. Powers impression counting, frequency capping, emissions
measurement, and conversion attribution; carries identifiers and tokens, never
raw PII. In Google Ad Manager it can surface under *Associated ad technology
providers* and must be declared as a custom ad partner URL to serve in the
EEA/UK/Switzerland/Brazil. See
[Creative → Measurement endpoint and EU consent](/v2/object-guides/creative#measurement-endpoint-and-eu-consent).

**Messaging app** — A shared Slack app or a customer-branded Microsoft Teams,
Discord, or WhatsApp provider registration that lets linked, active Apostra
members talk to Murph from an approved location. Installing or authorizing the
app does not grant Apostra access. Slack, Teams, and Discord can deliver
approved notifications only to active destinations; WhatsApp replies only
inside an active user-initiated service window and never initiates conversations
or sends proactive or template notifications. See [Talk to Murph in Slack,
Teams, Discord, or WhatsApp](/v2/guides/messaging-apps).

**Media kit** — Retired as the name for the seller identity buyers see in
Marketplace; see **Listing**. The industry reads "media kit" as including
merchandising material — audience stats, products, rates — which the listing
does not contain, so this term now refers only to Product Marketing source
material (see the retired `media_kit` compatibility API name below and
[Product marketing](/v2/storefront/product-marketing/overview)).

**Advertising Policies** — Optional buyer-visible policy text on a listing.
A Seller Account on Listing or Merchandising elects whether Brief Acceptance,
Creative Policy, both, or neither are disclosed from its local AI Business
Rules. Approval mode, approvers, routing, per-buyer overrides, and revision
notes remain private. Source-native AdCP policy from
`media_buy.portfolio.advertising_policies` remains independently applicable; a
legacy pure pass-through storefront without local rules shows that upstream
value read-only.

**`media_kit` (retired API name)** — Historical name for the Business Profile
and its compatibility API. This is not the buyer-visible listing (see
**Listing** above); the ingredient itself is now your product marketing
material. See [Product marketing](/v2/storefront/product-marketing/overview).
As of 2026-09-01, the v3 agent surface spells this same deprecated
compatibility kind and Page `listing` (its canonical wire name); `media_kit`
is still accepted as a deprecated alias for the identical handler. The
rename is wire vocabulary only — despite the name, `get(kind: "listing")` and
`save_media_kit` still return and write the legacy Business Profile, not the
buyer-visible Listing. Every response is marked `deprecated: true` and points
to `get({ kind: "seller", include: ["discoveryCard"] })` and `save_seller`,
which are the buyer-visible Listing.

**Media billing entity** — The legal entity Apostra invoices for an
organization's media spend, distinct from the organization's interchange-fee
payer. Configured at up to three levels — advertiser, account, organization —
resolved most-specific-first; every media-transacting organization always has
one at the organization level (the mandatory backstop). Country is identity
metadata (tax, currency) and never routes an invoice. See
[Media billing entities](/v2/buyer/billing/media-billing).

**Media Buy** — One AdCP transaction with one sales agent, spawned when a
campaign executes (one per agent). Not directly creatable; tuned through the
campaign update endpoint. See the [Media Buys guide](/v2/buyer/campaigns/media-buys).

**Media buy status (AdCP)** — The per-buy lifecycle status carried on the AdCP
wire: `pending_creatives` (accepted but no approved creative attached, so not
launchable), `pending_start` (creatives ready, flight not yet started), `active`
(live and delivering), `paused` (halted, resumable), `completed` (flight
finished or fully delivered), `rejected` (source declined), `canceled` (stopped
before completion). A buy a source is still moderating stays `pending_creatives`
and resolves through a [submitted task](/v2/guides/tasks). This AdCP wire status
is distinct from the higher-level Apostra buyer rollup (`PENDING_APPROVAL`,
`ACTIVE`, …) on the [Media Buys guide](/v2/buyer/campaigns/media-buys#status).
See [Media buy lifecycle](/v2/concepts/media-buy-lifecycle).

**Material** — A versioned teaching source a seller adds from a URL, site,
upload, crawl manifest, inline text, or prior work. A Material keeps the exact
source revision, relevance and confidentiality scope, review suggestions, and
confirmation receipts; it is evidence for Seller configuration rather than a
replacement for products, pricing, Playbook, AI Business Rules, signals, or Seller
identity. See [Seller workflows](/v2/setup/v3/seller-workflows#add-and-inspect-seller-material).

**Material candidate** — An evidence-backed suggestion extracted from one
exact Material revision for a seller to review. A writable candidate names the
existing save tool and schema-valid arguments that can confirm it; an
unwritable candidate explains what is missing or unsafe. Reading, rejecting,
or correcting a candidate does not change Seller configuration.

**Material confirmation receipt** — The bounded record returned after a seller
explicitly confirms a writable Material candidate through the save tool named
in it. The receipt links the saved record to the Material ID, source revision,
candidate ID, and destination identity, and is available from
`get(material)`.

**Merchandising** — Training your storefront agent to sell: pulling the right
products, reference material, and policy together to answer a buyer brief. This
is the *how* of selling, distinct from a **Product**, which is *what* gets sold.
Three inputs steer it — **Product Marketing**, **Playbook**, and **AI Business Rules** — and
each owns a different fact. See
[Merchandising](/v2/concepts/merchandising).

**Merchandising Agent** — Former name for the **storefront agent**. Older
changelog entries, API descriptions, and screenshots may still use it; the two
terms mean the same agent. See [The storefront agent](/v2/concepts/storefront-agent).

**Merchandising claim** — Retired name for a **Selling point**. See
[Product marketing](/v2/storefront/product-marketing/overview).

**Modular source** — An inventory source assembled from individual modules — an
avails feed, a booking ledger, creative handoff, trafficking, status sync,
reporting import, and human work — when inventory and execution do not come from
one compliant upstream agent. Manual and back-office supply belongs here
because each lifecycle responsibility needs an explicit module or human owner.
Registered as `executionType: MODULAR_SOURCE`. See
the [Modular lifecycle guide](/v2/storefront/inventory-sources/modular-lifecycle).
**Custom modular sources** is the customer-facing name for customer-specific
source composition included with Premium and Enterprise through the
Merchandising profile. Its stable internal feature key is `modular-sources`; it
is not a separate entitlement. Standard managed integrations are included with
every seller plan.

**Murph** — The assistant you talk to. Murph helps you set up, train, and coach
your **storefront agent** in plain language — never by hand-editing config —
and operates the platform for buyers and operators too. Same Murph everywhere,
different powers per role. See [Ask Murph](/v2/setup/ask-murph).

## N

**Negotiation posture** — The stance the storefront agent takes when shaping
an offer and responding to buyer asks — one of `direct_fit`, `hold_value`,
`value_preserving_compromise`, `tradeoff_ladder`, `price_first`, or
`wholesale_mirror`. The agent derives a *recommended* posture from history and
can save a **Learned default posture**; how that learning is converting is the
**Posture conversion** readout. See [Seller analytics](/v2/storefront/analytics).

**Notification subscription**: The authored record behind an Apostra alert. It
names what it watches (scope and content), when it fires (a schedule, or a
typed condition), where it goes (route references), and who may change it
(provenance: `user`, `contract`, `plan`, or `system`, each with its own
mutability over disabling it, its trigger, or its routes). A subscription
decides whether and when you're told something; the resulting notification,
and your read or acknowledged state on it, are separate records. No trigger
type fires yet — an Intelligence Unit (IU) allowance-consumption condition is
the first one planned. See
[Notifications](/v2/guides/notifications#notification-subscriptions).

## O

**Organization API key** — A WorkOS-managed credential shared by a script or
automation owned by an organization rather than one person. Existing organization
keys remain available during migration, but new integrations use user API keys. See
[Authentication](/v2/authentication#existing-account-owned-keys).

**Organization IU Rate Card** — The versioned offer that defines one billing
organization's IU plan sizes, list prices, corporate discount, rollover,
overage, term, and activity prices across buyer, Seller Account, Murph, and other
rated workloads. It is separate from legacy media-pricing arrangements. The
standard Rate Card is not yet published, and its pilot prices and IU
denomination are not final; an authorized administrator will see and accept the
exact effective version before it takes effect. See the [Organization IU
Rate Card guide](/v2/buyer/billing/organization-iu-rate-card).

**Operating Instructions** — The internal versioned guidance behind Playbook.
Exactly one version is active at a time; sellers manage it as **Playbook
guidance**. Each version also carries the storefront's **Selling Doctrine**.
See the [Storefront guide](/v2/object-guides/storefront).

**Storefront adapter** — A supported expert integration that dispatches the
entire buyer-facing storefront directly. It is configured as storefront
`ADAPTER` routing, not as an inventory source. Contrast with an external sales
agent, which remains private upstream supply behind the storefront. See
[Choosing a source](/v2/storefront/inventory-sources/choosing-a-source).

**Operator** — The organization that owns and manages an account — who the
account holder *is* for commercial purposes. It applies to **both sides**: on the
**sell side** the operator owns a storefront (a publisher, sales house, or ad
network); on the **buy side** the operator manages a buyer account (an agency,
trading desk, or DSP house). Its **operator domain** is the brand/company domain
where the operator's identity lives — where we pick up the logo and company
description (via **`brand.json`** / AAO), and often the domain the operator's
email points to (e.g. `raptive.com`, `groupm.com`). On the buy side it is
confirmed on the buyer account and remains separate from the WorkOS
organization domains used for sign-in, SSO, invitations, and membership. It is the account-owning
entity, **not** inventory: on the sell side it is distinct from a **Publisher**
(a domain of inventory the operator adds), and the operator domain is **never**
itself a product's coverage — Raptive is the operator (`raptive.com`) and adds
the publisher `cafemedia.com`. (The storefront setup form currently labels the
sell-side operator domain *"Storefront domain."*) Do not use **Operator** as a
synonym for **Seller**. On the buy side, an **Advertiser** is a Brand Reference
care of this operator. When a brand buys directly from an account registered to
its domain, its own organization is the operator; self-serve is only the
interface used to do so. A current v2 buyer account with no confirmed or legacy domain
uses `interchange.io` as a temporary platform-operator fallback.

**Organization** — A container that groups explicitly attached Buyer and Seller
accounts and can own a sales agent offering. It owns the shared contract, Terms
of Service, IU plan and wallet, billing **Standing** (**Funded balance**,
**Credit line**), and organization administrators. A standalone account is not
silently attached because its email domain or CRM company matches. Not to be
confused with an **Organization account**, which is an ad-platform manager
container (a Google MCC or Meta Business Manager), not an Apostra entity.

**Organization account** — See **Manager account**. The `organization` account
type on a discovered platform account marks a manager container that can never
be selected, mapped, or used for buys. Distinct from an **Organization**, Apostra entity that owns your accounts.

## P

**Participant roster** — The list of provider identities observed in an
account-owned support channel. Presence on the list is review evidence, not
Apostra account authorization. See [Review support channel participants](/v2/features/channel-participant-review).

**Pair** — A brief joined to its response, seller commentary, and commercial
outcome. An endorsed pair is an evaluation example; a response without a brief
is a standalone shape example, not an evaluation. See
[Responses and pairs](/v2/storefront/library#responses-and-pairs).

**Promoted** — The state a managed video or managed audio source reaches after
its uploaded bytes pass digest and media inspection against the exact pinned
storage generation. Only a promoted source can be published as a hosted HTTPS
URL for a hand-built creative or adopted directly into a creative manifest;
anything earlier has not been verified. See [Managed video source](#m) and
[Managed audio source](#m).

**Playbook** — The seller Page for how a storefront sells. Its versioned
instructions steer packaging, naming, selection, and explanation; its structured
pricing holds current value anchors, floors, ceilings, and currency. Instructions
may refer to those facts but may not copy them into prose. See
[Playbook pricing](/v2/storefront/playbook/overview).

**Pacing / Pacing Period** — *Pacing* is how spend is spread over time (`even`,
`asap`, `front_loaded`). A *pacing period* is a labeled time window within the
flight with its own weight or budget; each product becomes one package per
period at execute. See the [Pacing periods guide](/v2/guides/pacing-periods).

**Package** — One product for one pacing period inside a media buy, carrying its
own budget, pacing, bid price, and optimization goals. Spawned at execute. Its
`packageId` is stable for the life of the package but is an opaque string: the
trailing number on a storefront-minted id is a dispatch-order position, not the
pacing period, so identify a period from `pacingPeriod.index`/`label` rather
than the id. See [Package identity and the id numbering
scheme](/v2/buyer/campaigns/packages#package-identity-and-the-id-numbering-scheme).

**Performance campaign** — A platform-managed campaign where the buyer supplies
an objective and Apostra controls cross-seller allocation toward that
objective. It is `mode: "performance"` on the shared campaign resource.

**Pinned duration** — A `duration_ms_exact` value on a canonical format option
(`duration_ms_exact: 15000`). How closely a creative must match it depends on
where the value came from:

* **A pin carried over from a legacy format id** — a seller still publishing
  `format_ids` like `audio_15s`, whose duration is part of the *name* — is matched
  **within 100ms either side**. Duration measurement is not exact to the
  millisecond: an MP3 without a Xing header is measured from its byte rate, so
  re-tagging the same audio moves the number, and with a Xing header the value
  snaps to the MPEG frame grid (26.12ms at 44.1kHz, so exactly 15000ms is not even
  representable — 574 frames is 14994ms and 575 is 15020ms). Both a 14994ms and a
  15047ms master satisfy such a pin.
* **A pin the seller declared directly** in a canonical `format_options` entry is
  their stated requirement and is matched **exactly**.

The 100ms is measurement tolerance, not licence to deliver a different length: it
is three orders of magnitude inside the gap between the two closest standard spot
lengths, so a wrong-length file is still rejected — and the rejection quotes the
declared spot length. Deliver the length the pin names.

A `duration_ms_range` carries no tolerance in either case; a seller who states a
window has stated its edges, and both ends are enforced as written. **Sellers:**
if you accept a genuine range, declare `duration_ms_range` rather than an exact
pin.

When a product declares several options of the same `format_kind` that differ
only by pinned duration, name the one you want with `format_option_refs[]` — a
creative that carries only `format_kind` is ambiguous against such a product and
will not attach.

**Payout details** — The bank account a Seller Account operator saves so Apostra can
pay them: beneficiary name and address, account number or IBAN, one bank
identifier (Fedwire/ABA routing number, CHIPS ABA, SWIFT-BIC, or local bank
code), and payout currency. Entered once in Settings → Billing or via
`set_payout_details`; encrypted at rest, used only to execute payouts, and the
account number is never displayed after save (reads return the last four
characters). Required for **`agent` billing** on media buys. See
[Set payout details](/v2/storefront/billing/tasks/set-payout-details).

**Payout entity (payee)** — A legal entity within a seller organization that
receives payouts into its own bank account. Organizations selling through
multiple legal entities (for example, separate companies per market) register
one payee per entity and payout currency under Settings → Billing → Payout
entities (or via `set_payout_payee`); the beneficiary name on each account must
match that legal entity. Each payee carries its own encrypted account details
and is paid independently. See
[Set payout payee](/v2/storefront/billing/tasks/set-payout-payee).

**Brief** — The canonical artifact for buyer intent across live discovery,
uploads, CRM intake, synthetic evaluation, and prospective demand. It carries
origin provenance and anchors product composition and proposals.

**Pitch** — The written argument a proposal pass can carry alongside its
plan: the thesis, the buyer's brief mirrored back, the plan told as roles in
a strategy, how success will be measured, the case for the price, an honest
counter for what your catalogue lacks, and the invitation. Every sentence
cites at least one real source — the buyer's brief, your inventory and
product data, your Playbook pricing, or your Playbook instructions — or it is
dropped before it renders; nothing composes unsourced. Seller-side only
today: it renders on your [demand inbox](/v2/storefront/demand-inbox#the-proposal-pass)
pass, not on what a buyer's agent receives from `get_products`. See
[The pitch](/v2/storefront/pitch).

**Posture conversion** — The learning readout in seller analytics: which
negotiation posture the storefront agent actually used (the *selected*
posture) is booking, and whether following the history-derived *recommended*
posture booked better than diverging from it (*followed* vs *diverged* win
rate). See [Seller analytics](/v2/storefront/analytics).

**Principal** — A seller-issued identity for one caller, named by an opaque
`principal_id` (for example `prin_yq8Kd…`). A principal is a routing and audit
handle, never a credential and never a grant: every principal reports **empty
authority**, so holding one gives no advertiser, account, spend, payment, or
Terms access. Two kinds exist — a **buyer-agent principal** (one automation your
organization runs, which holds credentials you administer) and an **operator
principal** (your organization acting as itself, created the first time an
organization credential calls Apostra, holding no administrable
credentials). Its **lifecycle state** is `active`, `suspended`, or `retired`; a
buyer agent is suspended once it has no active credential left, and its
`principal_id` is retained for audit and never reissued. See
[Buyer-agent credentials](/v2/setup/buyer-agent-credentials).

**Credential fact** — Any identifier that describes a *credential* rather than
the **Principal** it authenticates: an OAuth client ID, an API key ID, an issuer
URL, a WorkOS organization ID, an operator domain, a `brand.json` or JWKS URL, a
signing key ID, a key fingerprint. Credential facts change when a credential is
rotated or replaced while the `principal_id` stays the same, and two credentials
associated with one buyer agent have different facts. A credential fact is
therefore never identity and must not be used as one. See
[Buyer-agent credentials](/v2/setup/buyer-agent-credentials#what-identifies-a-buyer-agent).

**Prepay** — A funding posture where an organization spends only against a
**Funded balance** it has deposited, with no **Credit line** (`creditLimit` is
`null` or `0`). To spend beyond the funded balance, the organization applies for
credit or contacts Apostra to be granted a positive limit.

**Product** — A packaged, sellable unit: one or more **Components** plus the
business rules around them — rate card, who approves, what bundles. The
storefront agent composes products in real time when it answers a brief.
Contrast with a **Component**, which is the raw, unpackaged material, and with
**Merchandising**, which is the act of selling the product. Two kinds reach
buyers, told apart by id prefix: a **composed product** (`cf_…`) is built to a
brief at discovery time, and a **Wholesale product** (`wh:…`) is one you authored.

**Composed product** (`cf_…`) — A product the storefront agent **builds to a
brief** at discovery time, from your wholesale products and components plus your
business rules. You do not author or manage one: it exists because a buyer asked
a question, and its id prefix (`cf_`) is how you tell it apart from a wholesale
product (`wh:`) in reporting and in a media buy. Requires [product
composition](/v2/storefront/products/product-composition) to be enabled.

**Passthrough product** — A product that belongs to a **third-party sales
agent** you have connected, offered to buyers as that agent returns it. It is
*not* a composition input and it is not yours to author — the agent is the system
of record, and Apostra reads and forwards. Contrast with a **Wholesale
product**, which you author, and a **Composed product**, which is built from
yours. See [Choosing a
source](/v2/storefront/inventory-sources/choosing-a-source).

**Wholesale product** — A product **you author** on a managed sales-agent
source: name, description, inventory selectors, creative formats, and pricing,
with a `draft` → `active` → `archived` status. It is what AdCP returns for
`get_products(buying_mode: "wholesale")`, and it plays two roles depending on your
storefront. On its own it is **directly sellable** — an `active` wholesale product
is discoverable by buyers. With [product
composition](/v2/storefront/products/product-composition) enabled it is also an
*input*: the storefront agent draws on your wholesale products to build
composed products for a brief. Distinct from a **Component**, which is raw
material you never author, and from a third-party agent's own buyer-facing
products, which are passthrough and are not composition inputs. See
[Create products from ad-server inventory](/v2/storefront/inventory-sources/create-products).

**Product marketing** — Your own marketing material — media-kit site,
template decks, one-sheets, package menus, case studies, audience cards, spec
sheets, seasonal calendars — taught to the storefront agent as versioned
entries (by link or upload), so it learns how you merchandise. Confirming the
same source again lands as a new version rather than a duplicate. What it
teaches the agent is a **Selling point**; each checkable one is reconciled
against your live inventory and verdicted **Backed** or **Not backed** (the
API reports the latter as `gap`), holding back a proven not-backed selling
point from shaping proposals. Retired names: **Media Kit**, **Product
marketing corpus**. See
[Product marketing](/v2/storefront/product-marketing/overview).

**Property** — An individual site or app under a **Publisher** (e.g.
`recipeswithessentialoils.com`); a publisher has 1:N properties. Each carries its
own `publisher_domain`, `property_id`, and tags in the publisher's
**`adagents.json`**, and is the unit an AdCP `publisher_properties` selector
resolves to. Distinct from the **Publisher** it lives under and the **Operator**
that sells it. See
[Publisher properties and coverage](/v2/storefront/inventory-sources/publisher-properties-coverage).

**Property List** — A named buyer-owned include or exclude set of domains, apps,
or CTV identifiers. Buyers use property lists to shape where campaigns run; a
seller's agent receives an ADCP `PropertyListReference` and resolves it on
demand. See [Property Lists](/v2/guides/property-lists) and
[Property-list briefs for sellers](/v2/storefront/property-list-briefs).

**Property Roster** — The storefront's canonical list of the properties it
sells or claims to sell: every **Property** its publishers declare plus the
domains the seller has claimed, grouped by publisher, each carrying its
authorization state (`authorized`, `unauthorized`, or `unknown`, resolved from
the publisher's **`adagents.json`**; a domain whose file is still being
resolved shows as pending), any publisher-declared **AdCP Collections**, and the
creative formats discovered for each publisher — each labeled with its
provenance, declared by the publisher or imported from the AAO community
registry.
Authorization is a per-publisher state on the roster, not an admission
requirement — a seller can claim domains before their publishers formally
authorize the agent, and an unauthorized result warns during setup and product
authoring rather than blocking them. Buyer-facing surfaces are stricter:
storefront discovery hides unauthorized publishers, and managed product
coverage (`publisher_properties`) disclosed by Apostra's embedded agent is
limited to the authorized set. A third-party agent's complete products carry
that agent's own declared coverage. The roster answers
"which sites, apps, and channels do I sell — and which of their publishers
have formally authorized me?" See
[Publisher properties and coverage](/v2/storefront/inventory-sources/publisher-properties-coverage)
and [Identity documents](/v2/concepts/identity-documents#blocks-vs-informs).

**Proposal** — A recommended media plan a seller returns from discovery —
named budget allocations across products, with rationale and brief alignment —
that a buyer can apply to a campaign in one step. Storefronts with product
composition author draft proposals when a brief supports a multi-product plan.
A draft proposal can be **finalized** (a `get_products` refine with
`scope: "proposal", action: "finalize"`): the storefront re-validates that
every product in the plan is still available at current pricing and commits
the proposal with an `expires_at` deadline. A committed proposal is a price
and composition commitment — not an inventory reservation — and can be
executed in one step by passing its `proposal_id` (with a `total_budget`)
to `create_media_buy` before it expires; each committed proposal executes at
most once. Distinct from a **storefront proposal**, which freezes a discovery
offer into a shareable `proposalCode` a buyer redeems later (see
[Storefront proposals](/v2/storefront/proposals/overview)). See the
[Discovery guide](/v2/guides/discovery).

**Proposal Evaluation Pass** — A managed evaluation of up to 10 valid proposal
or proposal-less product candidates under buyer instructions. Each candidate is
accepted, rejected, or sent through bounded seller refinement; accepted results
can carry buyer-owned enrichment. The meter is currently calibrating and
reports no charged IUs. See
[Evaluate proposals across storefronts](/v2/buyer/discovery/multi-storefront-get-products#evaluation-metadata-and-cost).

**Publisher** — A domain an **Operator** adds to its storefront as inventory
(e.g. `cafemedia.com`); a storefront has 1:N publishers. It hosts an
**`adagents.json`** — directly, or as a `managerdomain` that fans out to many
managed sites — from which we resolve the publisher's **Properties**. A product's
coverage is keyed off its publisher(s), **not** the operator domain. Distinct
from the **Operator** (the selling entity): Raptive is the operator
(`raptive.com`); `cafemedia.com` is a publisher it adds. See
[Identity documents](/v2/concepts/identity-documents).

**Publisher domain** — The domain that identifies a publisher property in
coverage and authorization flows, such as `wholesomeyum.com`. It is distinct
from the seller's operator domain and from a network's manager domain. Buyers
see publisher domains in product `publisher_properties`. See
[Publisher properties and coverage](/v2/storefront/inventory-sources/publisher-properties-coverage).

**Run-of-network (RON)** — A product or offer covering the seller's full
authorized publisher-property set for the relevant source, rather than a
seller-authored subset. RON coverage is derived from publisher identity and
authorization; an ad-server mapping is not proof of RON coverage.

## Q

**Quick RFP** — A seller RFP origin with bounded preset dimensions. Live Quick
RFPs with a typed preset can reuse a dependency-versioned response skeleton
while rescanning and reloading current commercial facts and applying current
request inputs. Draft and evaluation turns, bounded legacy presets, and Quick
origins without a preset compose normally but bypass caching. See
[Seller RFP lifecycle](/v2/setup/v3/rfp-lifecycle#use-a-quick-rfp-preset).

## R

**Recruitment** — Getting an organization to join the marketplace at all — a
seller signing, a buyer connecting. It is a demand signal to go land the
relationship, not engineering work: nothing needs to be built for a new
organization to join, only sold.

**Rendition (Material)** — A versioned, derived view of one immutable Material
source revision. It preserves supported page, slide, or sheet structure,
semantic blocks, and reusable visual assets with stable source locations and
extraction provenance; per-facet completeness states make unsupported or
degraded interpretation explicit.

**Reusable slide** — A slide from an uploaded deck or one-sheet that a seller
marks reusable. It cannot carry a price of its own; a slide with pricing stays
non-reusable until that figure is replaced with a rate-card value. See
[Reusable slides](/v2/storefront/library#reusable-slides).

**Retraction** — A cancel of a media buy that has not yet been committed to a
source (no forwarded leg, no reserved inventory). The pending request is
withdrawn and forwarded directly as a cancel with no operator approval. Contrast
with **Cancellation approval**, which applies to committed guaranteed buys. See
[Media buy lifecycle: Cancellation](/v2/concepts/media-buy-lifecycle#cancellation).

**RFP** — A seller-side record of one buyer request as it moves through
response composition, review, release, feedback, and commercial outcome. It is
not the buyer's canonical AdCP Proposal. Revisions add immutable RFP turns
instead of rewriting prior work. See the
[Seller RFP lifecycle](/v2/setup/v3/rfp-lifecycle).

**RFP turn** — One immutable request-and-response revision inside an RFP. A
turn records its purpose, origin, terminal response state, evaluation, exact
composition receipt, feedback, and outcome attribution. See the
[Seller RFP lifecycle](/v2/setup/v3/rfp-lifecycle).

## S

**Shape projection** — The safe part of an endorsed pair the agent can use for
a different buyer: block selection and order, seller positioning, and seller
commentary. It excludes the other buyer's identity, contacts, brief, budget,
rates, and response text. See [How your agent uses the
Library](/v2/storefront/library#how-your-agent-uses-the-library).

**Selling Doctrine** — A seller's strategy for when to answer a brief and how
hard to argue: a minimum category fit to respond, a counter appetite, and a
floor posture, alongside the Playbook prose that shapes the argument itself.
Versioned and activated as part of Operating Instructions rather than as a
separate object, so reverting is activating the prior version. Ships with named
starting points — `premium_scarcity_house`, `volume_partner`, and
`consultative` — that a seller adopts or edits. A storefront that has never set
one has no qualification gate at all and keeps pitching every brief it can
compose for; that state reads back as `house_default`, whose numbers are
display values rather than active thresholds, and is not adoptable by name
because it IS the absence of a doctrine. Doctrine governs judgment, never truth: it
selects and shapes claims, it cannot mint facts. See
[Selling doctrine](/v2/storefront/operating-instructions/selling-doctrine).

**Selling point** — One statement from your **Product marketing** material
about how you package, position, or prove your inventory — kept in your own
words, with the attribution it actually has: the verbatim quote and location
when it came from a document we parsed, the stated reason when that document
had nothing quotable, or "from you" when your agent presents it to buyers as
your own claim — because it's your account of a page (media-kit links are not
fetched today), or, for a case-study story, material that hasn't yet been
matched to an exact quote, whether that story came from a page or a document.
A selling point that makes a
checkable promise (a channel, a creative format, an audience signal) carries a
verdict against your live catalog — **Backed** or **Not backed** (the API
reports the latter as `gap`); a selling point with nothing checkable, or one
not yet checked, carries no verdict at all. A **Not backed** selling point is
held back from shaping proposals until you add the inventory it promises or
withdraw it. Retired name: **Merchandising claim**. See
[Product marketing](/v2/storefront/product-marketing/overview).

**Settlement currency / Payment currencies** — An Apostra-cleared Seller Account
confirms a primary settlement currency (`defaultCurrency`, ISO-4217) before going
live, and may also list additional **payment currencies** (`paymentCurrencies`) —
the full set of currencies it will be **paid in** (the primary is always
included). For those Seller Accounts, a media buy must be denominated in one of these
currencies unless the marketplace admits the buyer currency via FX. On a settled
currency there is **no FX**, so the currency a buyer pays in is exactly the
currency the seller is paid in, and a Seller Account cannot sell a pricing option in
a currency outside the set. Discovery only surfaces a product to a buyer in a
currency the Seller Account can transact, and returns no products (not an error) when
it can transact none of the buyer's currency. Empty `paymentCurrencies` falls
back to `defaultCurrency`, so a single-currency Seller Account need not set it. Direct
sales adapter Sellers run by our expert agents skip seller settlement
currency because Apostra does not pay the seller on that path; the buyer's
declared media-buy currency is forwarded to the downstream platform account. The
marketplace may additionally accept a buyer currency outside an Apostra-cleared
Seller Account's payment set via FX — see **Cross-currency buying**.

**Cross-currency buying (FX)** — Lets a buyer transact in a currency the Seller Account
does **not** settle in. The operator decides which currencies its Seller Account
settles in (`paymentCurrencies`, no FX); the **marketplace** decides which buyer
currencies it accepts via FX — a global set Apostra curates, covering the major
traded currencies plus key emerging markets. FX is therefore global and automatic:
no per-Seller opt-in. When it applies, the source keeps being paid in its own
(settlement) currency (unchanged); Apostra sits on the curation edge and converts
each source cost to the buyer's currency before quoting, at the platform spot rate
(ECB-backed, refreshed daily). The rate is the same for every buyer at a given time
(not a per-buyer rate), and it is snapshotted onto a media buy when the buy is
created — billing the source and settling the campaign at the locked rate for its
whole life. The source never sees a second currency; the cross-currency
relationship is entirely a property of the Seller Account's curation edge. See the
[Cross-currency buying guide](/v2/concepts/cross-currency).

**Sales Agent** — An AdCP-compatible seller endpoint that answers discovery and
executes media buys. `status` (`ACTIVE`, `PENDING`, `COMING_SOON`) says whether
the agent is live; `requiresAccount` says whether this buyer must register
credentials before using it. These are independent. For a Seller Account, an
external sales-agent *source* is a separate AdCP agent registered by URL
(`executionType: AGENT`) — distinct from the hosted **Seller** buyers reach and
from an **Ad Server** source. It can be used as a
live passthrough source, as a component source for merchandising, or both. See
[Choosing a source](/v2/storefront/inventory-sources/choosing-a-source).

**Seller** — The supply-side participant offering inventory through a
**Seller Account**. A seller may be a publisher, sales house, ad network, or platform
partner. Use **Seller** when the point is the role in a transaction or release
audience (`buyers` / `sellers`); use **Operator** only when the point is the
account-owning organization.

**Seller Account** — An Apostra **Account** whose role is `SELLER`: the
private workspace where members, permissions, API keys, inventory, policies,
and seller operations live. It also supplies the public commercial identity
and transaction surface that buyers see as a **Seller**. Legacy v2 APIs call
this object a **Storefront**. Do not
use this term for an external ad-platform or AdCP account connected by a buyer;
that is a **Connected provider account**.

**Seller-managed campaign** — Retired product name. What it described is now a
**tracked campaign** (`management: "tracked"`): a read-only shell mirrored from
a connected provider account the platform did not set up. The compatibility API
value remains `mode: "directed"`. See
[Campaigns on connected provider accounts](/v2/buyer/campaigns/directed-campaigns).

**Selector** — An address for inventory inside a connected ad server, such as a
custom-targeting key/value, ad unit, or placement. A seller-authored property or
tag mapping can point to a selector for execution addressing; it does not grant
publisher authorization or define buyer-visible coverage. The same ad unit is a
**Component** when the subject is what you sell and a selector when the subject
is where it runs — see the note under **Component**.

**Sandbox** — The safe, non-production path every reasoning step has. Agents
declaring `sandbox: true` are exercised through sandbox endpoints; demo
reporting is one query parameter away (`?demo=true`). New skills land on sandbox
and graduate to production explicitly.

**SESOFI (single-endpoint-single-object-full-intent)** — The architectural
pattern keeping the surface coherent: each high-level intent maps to one
endpoint that accepts one object describing the full intent. It cuts agent
round-trips and eliminates partial-state bugs. See the
[Philosophy primer](/v2/concepts/philosophy).

**Signal** — A targeting or optimization input — audience, contextual, or
outcome. A seller **authors** a signal by choosing and combining source-native
targeting primitives; it is then storefront-ready and travels as a `signal` on
the AdCP/API wire. One word for the whole lifecycle: what you author and what
ships are the same object. Contrast with **Ad-server targeting**, the raw
material you author *from*. See the [Signal guide](/v2/object-guides/signal).

<Note>
  Earlier docs and some in-product copy call this a **signal component**. It is
  the same thing. Every API operation has always used `signal` (`create_signal`,
  `list_esa_signals`), and the docs now match.
</Note>

**Property signal** — A **Signal** whose job is addressing rather than
targeting. A property is identified inside an ad server by a custom-targeting
key-value (in Google Ad Manager, `domain=<url domain>`), so the platform carries
that mapping on the same rail as any other signal: the key is synced on the ad
server source, and the values resolve storefront-side. It is not something a
buyer targets and it will not appear in a brief — it exists so a **Property** you
declared in `adagents.json` can be found in the ad server that serves it. The
default mapping is computed from your currently-authorized properties, not
stored, so it cannot drift; only your own overrides (aliases, `www`-vs-apex, apps)
persist. Distinct from a **Signal** in the ordinary sense (audience, contextual
or outcome) and from **Coverage**, which is *which* properties a product may run
on rather than how each one is addressed. See [Publisher properties and
coverage](/v2/storefront/inventory-sources/publisher-properties-coverage).

**Ad-server targeting** — Source-native targeting available through an ad
server source, such as GAM audience segments, custom targeting keys, and custom
targeting values. Browsing this material does not create or import a signal;
the seller chooses and combines it when authoring one. This is the raw material
a signal is built *from* — it is what a **Selector** addresses on the inventory
side and what you pick from on the signal side.

**Signal RAG** — Retrieval-augmented matching that surfaces the most relevant
signals for a brief or audience instead of requiring an exact lookup. See the
[Signal guide](/v2/object-guides/signal).

**Signal source** — A source that carries signals rather than inventory: audience
segments, taxonomies, or measurement. A peer source type alongside inventory and
creative sources. See [Choosing a source](/v2/storefront/inventory-sources/choosing-a-source).

**Source** — The connection layer: where a component comes from. A source is the
*pipe* you connect, credential, and test; the component is the *material* that
flows through it. Sources come in families by what they carry — inventory
sources (ad server, external sales agent, **Linked source**, **Modular source**),
**Creative source**, and **Signal source** — each set by `executionType`. Don't
confuse a source (the connection) with bare "inventory" (the stock). See
[Inventory sources](/v2/storefront/inventory-sources/overview).

**Sponsored Ads profile (Amazon)** — An Amazon Sponsored Ads profile: retail
media (Sponsored Products, Sponsored Brands, Sponsored Display), one profile
per marketplace/country, tied to a seller or vendor account. Typed
`sponsored_ads`; contrast with **DSP advertiser (Amazon)**. See
[Ad Platform Accounts](/v2/concepts/ad-platform-accounts).

**Standing** — An organization's funding and verification posture, returned on
the account for admins: its **Credit line** (`creditLimit`), the currency it is
denominated in, and a verification level. A `null` or `0` `creditLimit` means no
credit line (**Prepay**); a positive value is the granted ceiling.

**Setup credit** — The planned one-time 100-IU credit for a billing organization
accepting an IU plan for the first time, valid for 60 days from the commercial
signup commit once an effective Rate Card makes the offer available. Being an
existing customer does not disqualify an organization; having already received
the credit does. Seller Account provisioning may complete asynchronously without
moving that window. It is one lot in the organization's shared IU wallet and may
be spent on any IU-priced activity. It does not roll over or stack, and is not
currently available while the standard Rate Card remains unpublished. See the
[Organization IU Rate Card](/v2/buyer/billing/organization-iu-rate-card).

**Storefront agent** — Your storefront's seller: the agent Apostra hosts for you
that meets buyers and buyers' agents, lists your products, reads briefs, composes
priced proposals in your voice, and runs the deal through. It does five jobs —
Represent, Offer, Govern, Transact, Learn. You train it by working with
**Murph**. It sells whatever you put behind it: an ad server, a **Sales Agent**
you build or bring, or a **Modular source**. Formerly called the Merchandising
Agent. See [The storefront agent](/v2/concepts/storefront-agent).

**Storefront** — The legacy v2 name for a **Seller Account**, retained in v2
paths, operation names, response fields, and internal storage. New product and
v3 language uses **Seller Account** for the sell-side workspace and **Seller**
for the buyer-facing counterparty. See the legacy
[Storefront guide](/v2/object-guides/storefront).

**Storefront selection** — The account-wide decision that a buyer account
wants one Storefront available for activation. **Always include** and **Always
exclude** override automatic selection; **Return to default** restores it.
Selection is not owned by an advertiser, although advertiser markets and
channels are inputs to automatic selection. See
[Storefronts](/v2/buyer/storefronts/overview#manage-storefront-connections).

**`storefrontReviewStatus`** — The per-creative status of a publisher's operator
review, returned on each entry in `mediaBuys[].creatives[]` from `get_campaign`.
Values: `pending` (in the review queue), `approved` (publisher accepted),
`rejected` (publisher declined), `revoked` (previously-approved creative pulled
by the publisher). Null on Seller Accounts that run automatic creative review
(`creativeApproval: auto`). See [Creative approval](/v2/buyer/creatives/approval)
and **Creative review** in this glossary.

**Syndication** — Distributing a storefront's inventory so it reaches buyers
across Apostra through a single registration rather than per-buyer
integrations.

## T

**Task (async)** — A long-running operation the platform tracks asynchronously
(`~60s` to `Minutes-Days`). The caller polls or listens for completion rather
than blocking — discovery, execution, and approvals can all run as tasks.

**Test Cohort** — A held-out or experimental group configured on a campaign so
the platform can measure incremental lift against a control. Configured as part
of the campaign's full intent.

**TMP (Trusted Match Protocol)** — The open AdCP standard for request-time
targeting signals — cross-publisher frequency capping, audience activation, and
contextual/URL targeting — delivered by the **TMP Router**, which fans a small
request out to context- and identity-match providers, merges the responses, and
returns targeting signals without making the buying decision. Generalizes the
single-vendor RTD module — one provider, header-bidding only — into a
multi-provider, multi-surface standard. Sellers connect via the prebid module
or by self-hosting the router container. See [Real-time targeting (TMP)](/v2/storefront/tmp/overview).

**Tracked campaign** — A campaign with `management: "tracked"`: mirrored from a
connected provider account the platform did not set up. The shell is derived from
the media buys underneath it, read-only by construction, and updates
automatically as the upstream campaign changes — the platform observes and
accounts, it never acts. It remains tracked and read-only. A **managed
campaign** is created through the canonical buyer product and media-buy
lifecycle instead.

## U

**User API key** — A WorkOS-managed credential that acts as the user who
created it. Its effective access is the intersection of that user's current
account and resource authorization in the key's organization with the key's selected action scopes. A
dedicated service user can own a durable headless integration. See
[Authentication](/v2/authentication#user-api-keys).

**Unreachable mapping** — An **Advertiser mapping** whose platform ad account
no active connection reaches — typically after the only connection that
reached the account was unlinked. The mapping is kept, not deleted; it is
excluded at buy time, so a buy or generation request that needs it is rejected
until you relink the platform or re-map the account rather than silently using
another account. The mapping then recovers automatically. See
[Ad Platform Accounts](/v2/concepts/ad-platform-accounts#unlinking).

## W

**Workflow skill** — A bounded, versioned set of instructions that teaches an
AI agent how to complete a client job safely with Apostra. A workflow skill
can declare required tools, supporting assets, applicability, and evaluation
scenarios; it does not grant permissions or prove completion. See
[AI Agent Skills](/v2/skill).

**Work item** — Something the platform is waiting on a seller for. Three kinds
share the term: a **creative review**, a **media-buy approval**, and a
**modular source follow-up** — a source-side task a modular inventory source
raises for itself, such as confirming avails or resolving a trafficking error.
The first two are *decisions* and use `pending`/`approved`/`rejected`/
`revoked`; the third is a *task* and uses
`OPEN`/`IN_PROGRESS`/`BLOCKED`/`COMPLETED`/`CANCELLED`. Deciding is not the
same as delivering: an approved media buy carries its own forwarding evidence,
and an approval with no forwarding timestamp is reconciliation work rather than
a completed one. See [v3 Agent Surface (preview)](/v2/setup/v3-preview).