Skip to main content
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).
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: 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.
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. 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:
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:

​
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; 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.
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.