> ## 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. # Buyer setup and go-live > Set up your operator once, then see what each seller or buying platform needs. Buyer Setup separates your organization’s platform readiness from the setup for each seller or buying platform. If Scope3 invites you to a new buyer account, the setup email is sent to your named address. Accept the invitation and verify that email to join. The invite opens the account setup path; your organization still completes its domain, plan, terms, and other readiness steps before live buying. Buyer and Seller Setup use the same activation pattern: a neutral status and progress header, one operator-domain editor, and a clear next action. They are separate Pages because the work after identity is different. Buyers configure destinations and advertiser mappings; storefronts configure inventory, publisher authorization, settlement, and payouts. ## Platform go-live You complete these steps once for the buyer account: * confirm the domain of the organization operating the account; * say whether the account represents the whole operator or a specific operating unit; * choose the plan for this buyer account; * accept the current terms; * resolve any account hold; and * once choosing payment terms is available, choose the payment terms sellers are asked for before buying from a seller on consolidated billing (see [Your organization's payment terms](#your-organizations-payment-terms)). These facts unlock real non-spend work such as connections, proposals, and campaign setup. Your billing details are needed only when a transaction's seller bills through Apostra on consolidated billing. Apostra does not grant or manage a buyer credit line — sellers decide credit on their own terms, on their own media. Together, the domain and optional operating-unit ID form the account's AdCP operator identity: | Account scope | Operator identity | | - | - | | The whole operator | The operator domain, with no operating unit | | A specific unit | The operator domain plus a stable `operator_unit.id` | Use a specific unit for a buying seat, office, region, or team that needs to be distinguishable from other accounts under the same domain. Prefer a code your organization already uses. If you do not have one, use a short, readable ID that will remain meaningful over time. Do not use `default`, a temporary display name, a seller's account ID, or an Apostra database ID. The buyer account name is mutable display metadata; the billing-company name is separate and does not identify the operating unit. An account administrator must confirm the scope. Before confirming, review the other buyer accounts under the same operator domain so you do not claim the whole operator when the account actually represents one unit. Buyer Setup lists the confirmed identities visible in your account hierarchy for the domain you enter. Apostra rejects an exact identity already claimed by another buyer account. You can change the operator domain, scope, or unit ID after setup and after connecting storefronts, until an advertiser account is created or bound under that identity. Buyer Setup then reports the identity as locked. In AdCP 3.2, the operator domain and optional operating-unit ID are advertiser natural-key dimensions; pre-3.2 bindings still make the seller-visible operator domain immutable. Changing either requires an advertiser identity migration rather than an ordinary settings update. Apostra compares the operator domain with account membership and the verified organization domain. The Organization must prove control before real operations are available. AAO corporate metadata can suggest or classify the Organization, but a public AAO record is not ownership proof. A buyer operator does not publish `adagents.json`; that document belongs to seller authorization. Buyer setup also does not require `brand.json`. Buyer Setup always shows the current operator. A domain suggested from existing account or work-email information is prefilled, but it is not silently treated as your choice. A sole buyer account may show **The whole operator** as a recommendation; an administrator still confirms it. When the account is a specific unit, Buyer Setup proposes a readable ID from the account name, which you should replace when your organization has an established code. Existing accounts with a proved legacy domain remain able to use their existing buying paths while scope confirmation is pending. Buyer Setup continues to mark the operator-identity step as incomplete, and new AdCP 3.2 provisioning may require the complete confirmed identity. ## If an API call requires Buyer Setup On `/mcp/v3`, call `get_status` first. When `operatorIdentity.usableForBuying` is false, an account administrator can call `save_buyer_operator` with the real non-platform `operatorDomain` and either `operatorScope: "whole_operator"` or `operatorScope: "specific_unit"` plus a stable AdCP `operator_unit` (`{ "id": "east-coast" }`). When the domain is usable but `scopeStatus` is `unclassified` and `locked` is false, reuse that domain and choose its scope. When `locked` is true, follow the support action returned by `get_status` instead. The tool confirms commercial identity only; it does not grant user access or change the login organization. Before that identity is claimed, `/mcp/v3` can still create, update, or archive a test-only advertiser with `save_advertiser` and `sandbox: true`. This exception applies only to the operator-identity check: plan selection, current Terms, and other readiness blockers still apply. Live advertisers continue to require the complete buyer operator identity. Buyer discovery and other new buying operations return HTTP `409` with error code `BUYER_SETUP_REQUIRED` when the account has no confirmed, non-platform operator identity. For a missing identity, the exact structured details are `reason: "missing_operator_identity"`, `readinessCheck: "operator_identity"`, `setupStep: 1`, and `setupPage: "buyer_setup"`. This is a correctable account-readiness task, not a seller outage: open **Buyer Setup**, confirm the operator domain and account scope, then retry the request. ```json theme={null} { "data": null, "error": { "code": "BUYER_SETUP_REQUIRED", "message": "Complete Buyer Setup step 1 by confirming your buyer operator identity before continuing.", "details": { "reason": "missing_operator_identity", "readinessCheck": "operator_identity", "setupStep": 1, "setupPage": "buyer_setup" } } } ``` Apostra never substitutes `interchange.io` for a missing buyer operator. That would combine unrelated buyers under one seller-side natural-key account. If a legacy profile explicitly contains that platform domain, the request uses the same `BUYER_SETUP_REQUIRED` contract with `details.reason: "platform_operator_not_allowed"`. Replace it with your organization’s operator domain in **Buyer Setup**. Changing or confirming the operator affects new discovery and provisioning, but does not rewrite existing transactions. A historical media buy continues to use the exact seller account persisted when the buy was created, including for status, creative re-sync, update, cancellation, and delivery operations. The same identity gates account linking. A production entry on `POST /api/v2/buyer/storefront-accounts/sync` (or the `sync_buyer_storefront_accounts` tool) must name your confirmed operator domain as `operator`; a different domain returns HTTP `403` with `ACCESS_DENIED` and `details.reason: "operator_identity_mismatch"`, and a missing identity returns the `BUYER_SETUP_REQUIRED` contract above. A sandbox entry (`sandbox: true`) is fenced off from production spend and may name any operator. An account grant says whether the seller will transact with you. It does not say whether Apostra uses that seller for a given advertiser. A `GET /api/v2/buyer/storefront-accounts` request (or the `list_buyer_storefront_accounts` tool) that names an advertiser with `advertiserId`, or selects one with the `x-scope3-seat-id` header, also returns `ext.interchange.advertiser_activation`: `seller_on` (whether product discovery and new media buys use this seller for that advertiser) and `reason` (the control that decided it). A named advertiser you cannot read is refused with `403`, and `503` means access could not be checked right now. A seller can have an `active` grant and still be off for the advertiser; turn it on with [Update advertiser Seller preference](/v2/buyer/storefronts/tasks/update-advertiser-activation-preference). The field is omitted when the request names and selects no advertiser, when the advertiser belongs to another account (a sibling account in your organization, or an organization that delegated it), or when Apostra cannot read the advertiser or the decision; the grant list still returns. ### Billing modes and the business entity payload Each `sync_accounts` entry names a `billing` mode: `agent` (Interchange invoices on your behalf; no additional payload needed), `operator`, or `advertiser` (the storefront invoices your operator or advertiser directly). `operator` and `advertiser` entries require a `billing_entity` — the AdCP `BusinessEntity` payload with your legal name and, as applicable, tax/VAT/ registration ids, a postal address, billing contacts, and bank details: ```json theme={null} { "billing": "operator", "billing_entity": { "legal_name": "Acme Media Ltd", "vat_id": "DE123456789", "address": { "street": "Friedrichstrasse 100", "city": "Berlin", "postal_code": "10117", "country": "DE" }, "contacts": [ { "role": "billing", "name": "AP Department", "email": "ap@acme.example" } ] } } ``` `billing_entity.bank` is write-only: send it to provide payment coordinates, but it is never echoed back on a `sync_accounts` or `list_accounts` response — the seller stores it and confirms receipt without returning it. A storefront only accepts the billing modes it has published support for. An entry naming an unsupported mode returns HTTP `400` with `BILLING_NOT_SUPPORTED` and `details.supported_billing` listing the modes the storefront actually accepts: ```json theme={null} { "data": null, "error": { "code": "BILLING_NOT_SUPPORTED", "message": "billing=operator is not supported by this storefront. Supported: agent.", "details": { "reason": "billing_not_supported", "supported_billing": ["agent"], "requested_billing": "operator" } } } ``` ### Payment terms AdCP lets a `sync_accounts` entry request `payment_terms` (for example `net_30` or `net_60`). The protocol does not let a seller silently swap in different terms: the seller accepts the requested terms or rejects the account. When you omit `payment_terms`, the seller's default terms apply. On a storefront that Interchange hosts or manages, requesting terms is not available yet; it launches for every buyer at once. Until then, a request in which any entry sets `payment_terms` is rejected as a whole with the AdCP error `PAYMENT_TERMS_NOT_SUPPORTED`, which names the first such entry in `field` and its requested value in `details.requested_payment_terms`. No account is created or changed; retry without `payment_terms` to accept the seller's default terms. Once requesting terms is available, the requested terms go to the seller with the account request: * **The seller reviews them.** Approving the account accepts the terms you requested, and the account then reports them in `payment_terms`. There is no counter-offer: if the terms don't work for the seller, the seller rejects the account. * **Only the net 60 default can be approved automatically.** A storefront may approve some account requests without a person reviewing them. A request for any terms other than `net_60`, shorter or longer, always waits for the seller to review it, so it can take longer to approve. * **You can change the terms while the request is pending.** Send the same account again with different `payment_terms` and they replace the earlier ones; that account's row returns `action: "updated"` and the seller reviews the new terms. * **A decided account keeps its decision.** Once the seller has accepted or rejected the account, a request naming different terms changes nothing. That account's row returns `action: "failed"` with the AdCP error `PAYMENT_TERMS_NOT_SUPPORTED`, and the account keeps its status and its terms. Other entries in the same request are unaffected. To change the terms on an accepted account, agree them with the seller directly. #### Your organization's payment terms Your organization chooses the payment terms Apostra asks sellers for: `net_15`, `net_30`, `net_45`, `net_60`, or `net_90`. Until you choose, `net_60` applies. Set the choice with `paymentTerms` in [Update billing info](/v2/buyer/billing/tasks/update-billing-info); it applies to every advertiser in the organization. Like the rest of this section, it is available once requesting terms is available. Choosing terms is a go-live step for consolidated billing, so no consolidated-billing buy is placed on terms nobody chose. Until an organization administrator has chosen: * buyer readiness shows a **Payment terms** check (`payment_terms`) that is not complete, and it blocks go-live when you have sellers on consolidated billing; * a seller on consolidated billing shows `needs_commercial_setup`, and a buy from it is refused with the `payment_terms` blocker; and * direct-billed sellers are not affected. If you have already connected a seller on consolidated billing, Apostra holds that seller-account setup until you choose terms, then resumes it automatically. Sandbox accounts are not held. Choose terms explicitly, even to keep the default: send the default value itself. Once chosen, the terms can be changed but not cleared, so `paymentTerms: null` is refused with a validation error and the recorded choice stays in place. When Apostra opens an account for you with a seller (for example, when you turn a seller on for an advertiser or buy from a seller for the first time), the request asks for your organization's terms: * **Longer terms can mean more rejections.** Sellers carry the credit risk on their accounts, so some decline longer terms, and on storefronts Interchange hosts or manages only the `net_60` default can be approved automatically. * **Decided accounts keep their terms.** Changing your choice applies to accounts opened afterwards. An account a seller has already accepted or rejected keeps that decision and its terms; an accepted account keeps working exactly as before. * **A seller can refuse your requested terms.** The account request then fails for that seller, and the connection reports that the seller does not accept your terms. Review the seller's terms before explicitly requesting an account on those terms, or leave that seller disconnected. Apostra does not retry the request on the seller's default terms. `POST /api/v2/buyer/storefront-accounts/sync` (and the `sync_buyer_storefront_accounts` tool) accepts any AdCP `payment_terms` value: `net_15`, `net_30`, `net_45`, `net_60`, `net_90`, or `prepay`. A storefront that routes accounts to the seller's own sales agent forwards `payment_terms` to that agent unchanged, and the seller's agent decides. On the Storefront MCP discovery surface, an explicit opaque `account_id` must belong to the authenticated buyer on that storefront. A missing buyer grant or an ID belonging to another buyer returns the structured AdCP error `ACCOUNT_NOT_FOUND` with `details.reason: "account_not_authorized_for_buyer"`; it is not reported as a missing storefront account context. Retrieve an authorized account with `list_accounts`, or complete the seller's account-linking flow, before retrying. Buyer Setup returns derived capability verdicts rather than a writable Account mode. Before Organization proof, plan selection, and Terms, the Account can use bounded demo and onboarding surfaces. After those steps it can perform real non-spend work. Spend additionally requires the media-buying product entitlement. Seller-direct transactions need nothing further from Apostra. Consolidated-billing transactions additionally need your organization's billing details: a payer name, street address, and country, so Apostra can invoice you. They never need a card or an Apostra credit line, because Apostra takes no credit risk on the seller's media. An organization that already has a verified card or an Apostra credit line on file can keep buying while it adds its billing details. Account holds block every capability. Confirming or changing the buyer operator does not change your WorkOS organization, sign-in, invitations, SSO, account membership, billing company, advertiser, or brand domain. ## Destination go-live Every seller or platform then shows only its own remaining requirement: * A credential-free AdCP seller requires no connection step. * An official adapter may require a free provider connection, account choice, and advertiser mapping. * A seller can be temporarily unavailable even when your connection is healthy. * Direct-billed sellers and platforms bill the operator or advertiser and do not use an Apostra rate card or payment method for that route. * A seller on consolidated billing requires active media pricing supported by the current pricing engine and your billing details before live spend. Add them in **Plan & Billing → Payment & invoices**. Until they are complete, the buy is refused with the `billing_details` blocker, readiness lists `BILLING_DETAILS`, and `commercial.billingDetailsComplete` is `false`. Readiness no longer reports `PAYMENT_AUTHORITY` or the `payment_authority` blocker. Treat any blocker value you do not recognize as blocking. A child account automatically uses the media pricing on its billing organization; the account-delegation placeholder does not control that inheritance. Once choosing payment terms is available, your organization must also have chosen them; see [Your organization's payment terms](#your-organizations-payment-terms). The media rate card used to price a buy is separate from the Organization IU Rate Card. The IU plan remains an invited staging pilot and is not a production buyer-readiness requirement. You can connect destinations, inspect accounts, and view mirrored campaigns without charge. “Can buy now” means the applicable capability verdict is allowed and at least one destination’s actual requirements are complete. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.