Skip to main content

​
Account Access & Signup

Signup asks what you want to do, then resolves whether your verified email may create or claim the matching organization or account. Product intent and company classification are separate: choosing to buy media, sell inventory, or offer a sales agent does not set a CRM segment.

​
Choose a product context

​
The four-choice chooser

When you create a new organization or account, signup shows one of two pickers. Accounts enrolled in the chooser rollout see a four-choice chooser, Choose your starting experience. Everyone else sees the account-type list above. The chooser works the same whether you sign up with email and password, Google, or single sign-on. Your choice sets what the new account starts as. It does not grant access to an existing organization. Offering a sales agent always creates a new organization with its own Developer account; it never takes over an account that already exists for your email domain, so a domain that already has an account needs an invitation from that account’s administrators. People joining an existing company, through an invitation, a claimable account, or an access request, still see the account-type picker, and the invitation or the claimed account decides what they receive. Buyer and Seller accounts created through self-serve signup are standalone. They do not inherit another organization’s Terms of Service, billing, standing, or administrators merely because their email or CRM company matches. Attaching an account to an organization is a separate, explicit conversion; see Turn a standalone account into an organization.

​
What grants product access

A Buyer account receives setup access after an eligible verified signup or an approved access request. Live buying still follows the account’s plan, standing, and payment requirements. A Seller account receives product access when it is created or claimed through Seller signup, an invitation, or a support-led Seller setup workflow. Real Seller setup and operating history also remain valid evidence. An account label or an empty historical storefront is not access evidence. If an older account was classified as a Seller without completing Seller setup, sign-in and product API operations remain blocked until Apostra verifies the Seller setup or approves a separate Buyer account. An already-issued MCP credential may retain only get_status and switch_account, so its operator can identify and leave the blocked account; it cannot run product operations. Contact Apostra support with the organization, intended product, and first administrator so the correct account can be prepared without reusing an ambiguous legacy identity. Pages and Tasks opened in the web app always act on the account shown in its account picker. On V3, a tool call in Claude or ChatGPT acts in the account it names with accountId; nothing carries over from one call to the next, and no other connection or the web app changes. The retired switch_account tool still runs from tool lists that hosts cached earlier, and moves only the connection it was called on. See Name the account on every call. A parent organization is a navigation and administration container. Signing in at the parent lets a user choose an admitted child account; it does not give the parent Buyer or Seller product access. A live account owns its domain. A Buyer account is never created on top of an account that is still in use, whether by signup or by Scope3 on someone’s behalf. Adding a Buyer next to a live account is an organization promotion, and only that account’s own administrator does it: they can create a Buyer child account or convert the account to an organization themselves. If you are not yet a member, request access to the existing account and its administrators are notified. The one exception is a live Seller account that nobody administers: a verified signer on its domain who chooses Buy media becomes its administrator first, as described under “How signup resolves an organization or account”. Scope3 can invite a named Buyer administrator when the organization’s only older Seller account is dead. A dead Seller account has no live Storefront, no administrator, no contract, payment setup, or other commercial record, no active API credential, and no media buy or billing activity. It was either created at least 90 days ago or has no members and no pending invitations at all. Scope3 retires it first. The account is deactivated, its domain is released to the new Buyer account, and its remaining non-admin members and invitations end. Nothing is deleted, and Scope3 keeps a record that lets the account be restored. The named person is then invited as administrator of a new standalone Buyer account. They accept and verify the email address named in the invitation to enter Buyer Setup, and they can accept the Terms of Service and invite colleagues. No organization is created at invitation time. If they accept a plan that gives an organization capacity for more than one account, Apostra converts the Buyer account into an organization first. They become its organization administrator and the plan applies to the organization. If the Seller account is not dead, Scope3 does not invite a Buyer administrator; the account’s own administrator adds the Buyer. A matching verified email domain alone cannot claim a child account or its parent billing authority. An unchanged standalone Seller account with an archived Storefront still supports verified-domain reclaim.

​
How signup resolves an organization or account

Your verified email domain is evidence for identity resolution (for example, @mediamark.co.za). It is not, by itself, permission to join every account with that domain.

​
1. New domain → create the selected organization or account

If no matching organization or account exists, signup creates the selected standalone Buyer or Seller account, or an organization with a sales agent offering, and makes you its first admin.

​
2. One enabled, ownerless organization or account → claim it

When Apostra has pre-provisioned one enabled organization or account for the domain and it has no administrator, the first verified user whose signup choice is compatible may claim it and becomes its admin automatically. This is the safe path for a nominated administrator signing up after setup. Child accounts are not claimable from an email domain alone. They retain their existing organization and history, and require an explicit invitation or support-led recovery instead. An archived Seller account is recoverable from its registered domain, including when it already has an administrator. The first new user with a verified email on that domain can claim the account. Apostra makes that user an admin and restores the existing storefront so the seller can continue setup without losing its identity or history. If you want to buy media on a domain that currently resolves to a Seller account, select Buy media. When that Seller account is dead (it has no live Storefront, no administrator, no contract, payment setup, or other commercial record, no active API credential, and no media buy or billing activity, and it was either created at least 90 days ago or has no members and no pending invitations at all), verifying your email retires it and creates a standalone Buyer account for you. You become its administrator, so you can accept the Terms of Service and invite colleagues, and the domain now belongs to your Buyer account. The old Seller account keeps its history and archived Storefront but is deactivated, and its remaining non-admin members and invitations end. Apostra keeps a record that lets the account be restored. Signup never creates an organization for this and never gives you access to the Seller account. If the Seller account is live but nobody administers it (it has a live Storefront or a commercial or billing record, and no administrator), and your verified work email is on its domain, choosing Buy media claims it. Before you finish, signup tells you that you also become administrator of your company’s existing Seller account. You become its administrator, the Seller account becomes an organization that you administer, and your new Buyer account is created inside it. The Seller account keeps its Storefront, history, and everything else it holds, and nothing is retired. If the account’s plan does not cover a Buyer account, signup says so. You are still the Seller account’s administrator, and you add the Buyer account once the plan allows it. If the Seller account has an administrator, the domain has more than one active account, the Seller account is a child account, or the domain is reserved for a designated Buyer contact, it owns its domain: signup creates no account and nothing is retired. You get the existing-account outcome instead. Ask its administrator to add you, or request access, which notifies the account’s administrators (or Scope3 when it has none). Your request does not claim the Seller account, reactivate an archived Storefront, or grant Seller or organization administrator access. An exact Buyer invitation takes you directly to the invited account instead. A historical membership does not reactivate an inactive account during signup. Support can retire invalid access while retaining the account’s audit history. If the nominated administrator uses a different email domain, Apostra must invite that exact address manually. If several identities match the domain, signup does not guess; an invitation is required.

​
Designated owner for an organization’s Buyer signups

When Apostra’s review designates an owner for an organization’s new Buyer accounts, that person owns signup for the organization’s company domains. A company domain is any domain Apostra associates with the organization. This includes the registered domain of each of the organization’s accounts, which is added automatically once the account is linked to the organization; it is not limited to domains added by hand. Anyone else who verifies an email on one of those domains is not offered account setup, and signup is refused with a message to ask the organization’s admin for an invitation. A Buyer signup link claimed with an email on a domain that belongs to a different organization than the link’s is sent to Apostra for review instead of completing. The claimant does not need to try again.

​
3. An administered organization or account exists → request or accept access

If your domain belongs to an established organization with an admin, signup does not make you another admin. When the organization’s registered primary domain is verified, matching-domain access requests are approved automatically as ordinary member access by default when that domain identifies one organization. An organization admin can disable primary-domain auto-join. If auto-join is disabled, or if the domain is not verified, you’ll be routed to Request Access for manual approval. Manual approval also applies when several organizations share a domain and no organization has explicitly enabled auto-join. Child accounts remain separately controlled: joining the organization does not grant access to every account beneath it.

​
The “Request Access” screen

If you reach Request Access, submitting it notifies your organization’s admins, who can approve you. A verified primary-domain request may instead be approved immediately when auto-join is enabled.
  • Fastest path: ask an admin on your team to send you an invitation directly. An invitation supersedes a pending request and lets you sign in with the role they choose.
  • No admin yet? If exactly one enabled organization or account matches your verified domain and your signup choice is compatible, signup claims it as described above. Otherwise, contact Apostra support for an explicit invitation.
Organization admins manage organization members, admins, pending invitations, and pending access requests under Settings → Organization → Members, from the organization or any of its accounts. An admin of an administered standalone account manages access in that account’s Account members settings. Joining an organization does not grant access to all of its accounts. An account’s member list and membership settings require direct admin membership on that account or its parent organization. A basic account role shown after an organization admin switches into a child account does not remove the admin’s direct organization authority. Advertiser access does not grant permission to manage the organization or its accounts. When organization billing terms need acceptance, a direct organization admin can confirm them in Plan & Billing while viewing a child account. The acceptance applies to the parent organization and its child accounts. A child account admin without direct organization admin membership cannot accept the parent organization’s terms.

​
Where organization settings live

Organization functions live in Settings, in the same rail as your other settings, in every account; there is no separate organization page. In the organization itself, an organization administrator finds Accounts, Members, Plan & billing, API keys and Advertisers under Organization. From one of its accounts, Organization holds Accounts, Members and Plan & billing; API keys stays under the account with that account’s own credentials, and the Advertisers page stays where it is. An administrator of a standalone account finds the same functions in the account section, without an Organization label; Accounts there is where they add a second account, which also creates the organization that manages both. Members and administrators of a child account only see who manages the organization’s billing, and nothing else about the organization. Advertiser-scoped access, sponsored buyers, API keys and service credentials never show organization settings. See Organization settings in place for the full list of what each kind of user sees. The account switcher in the top bar lists the accounts you can open and any pending invitations. Everyone sees it, including someone with only one account. An organization is never an entry of its own. Below the accounts it lists actions on the account you are in: Add account for administrators who can add accounts (it opens Settings → Accounts), Agents and Partner where the account has them, and View as. Every organization setting is in Settings. When an authenticated admin sends, approves, or resends an invitation, that admin receives a copy of the invitation email unless they are also the invitee. The copy provides visibility into what was sent, but it does not grant access: only the invited email identity can accept the invitation. Accepting an invitation creates your membership straight away, but access to the account usually takes up to a minute to become active. The invitation page waits while that happens, then opens the account for you. If access is still not active after about a minute, the page says so and offers Try again; your invitation is already accepted, so trying again only reopens the account and does not need a new invitation. If it keeps failing after a few minutes, contact Apostra support. The invitation keeps the email design associated with the destination account, including when an admin resends it. If the invitee already has a saved interface language, that preference is used for the message. New invitees and unsupported language preferences receive English. Company name, email domain, and market are not used to guess a language. Signup includes a language selector preselected from the browser locale. The selection is saved to the user profile and remains separate from organization market settings. An admin or governed provisioning workflow can also provide an explicit invitation language before the invitee has a profile.

​
Turn a standalone account into an organization

A standalone account is its own billing boundary, with no organization above it. Converting it creates a new organization and makes your account that organization’s first account. Convert when you want to manage more than one account under one organization, or before setting up a sales agent offering, which only an organization can hold. An administrator of the standalone account converts it in Settings → Account configuration by selecting Convert into an organization. Only administrators of the standalone account see the option. Adding a second account from a standalone account (Add account) also converts it, in the same step. Apostra can convert an account on your behalf. What moves to the organization:
  • your contract, billing authority, and agreement documents;
  • your plan, its feature access, and the number of accounts it allows;
  • any current plan offer you have not accepted yet, so an organization administrator can review and accept it in Plan & Billing;
  • an existing sales agent offering;
  • your card and its Stripe customer, including a card setup that has not finished, so charges keep going to the same card;
  • your metered plan record, your free, rollover and referral credit, your credit standing and payment terms, and any billing currency override;
  • your billing contact, which is copied to the organization. The account keeps its own copy.
Stripe is not touched: your Stripe customer and card keep the same identifiers, and nothing is charged or re-entered because of the conversion. The one case that stops a conversion is an organization that already has its own Stripe customer, because two cards cannot be reconciled by a rule. If the organization already holds a plan record, standing, payment terms, currency override or free credit of its own, the organization’s stays as it is and the account’s stays on the account as history. An account that has a charge, a closed billing cycle or an invoice in progress, a payment collection in progress, an open standing hold, a plan with a monthly commitment, a credit application, a referral, or funds on its Apostra balance cannot be converted yet. The conversion is refused and names which one; contact Apostra support. What stays with the account: its storefront, advertisers, campaigns, media buys, history, domain, and members. Media billing entities, whether owned by the account or attached to one of its advertisers, stay with the account and keep resolving for its advertisers. Who sees billing afterwards: the card, invoices and standing belong to the organization, so only organization administrators see and manage them. An account member who is not an organization administrator saw them before the conversion and no longer does. Because the administrators of the account become organization administrators, the people who managed billing keep managing it. Who administers it:
  • Every administrator of the account becomes an organization administrator when it converts, whoever starts the conversion, including when Apostra converts it for you. The card, invoices and standing move to the organization and only organization administrators see them, so the people who managed billing keep managing it. An administrator of the account is someone who holds the administrator role on it directly. A person who was removed or demoted before the conversion does not become one.
  • Other account members stay account-only unless separately invited to the organization.
  • Organization administrators can manage every account in the organization.
Standing (your credit line and verification level) moves to the organization with the account, so the organization has the standing the account had. Your plan stays the same: it moves to the organization together with the account, so converting on its own is never refused for plan coverage. Adding an account or a sales agent offering afterwards is checked against the plan as usual, including its account allowance; see Which plan holds which accounts. Converting cannot be undone in self-service. Detaching an account from its organization needs a dedicated migration of contract, billing, standing, and administrator authority; contact Apostra support. Through the API, a signed-in account administrator calls POST /api/v2/accounts/convert-to-organization with confirmOrganizationConversion: true. API keys and service credentials cannot convert an account, because the person who confirms becomes an organization administrator. Repeating the call after a failure finishes the same conversion; repeating it after success returns the existing organization. In the web app, if converting does not finish, the same settings section shows Finish conversion in the browser you started from; otherwise contact Apostra support, which can finish it for you.

​
Which plan holds which accounts

A billing organization has one plan. That plan also decides which accounts the organization may hold: No plan limits how many Buyer or Seller Accounts an organization holds. The plan decides only which kinds of account it may hold; see Accounts in an organization. Every plan also covers one Developer account for the organization’s own agents. An organization holds one Developer account, and it holds any number of agents. A second Developer account is refused. Every organization shows a Developer account row in its Accounts settings. If it has not been created yet, an organization administrator can select Create from that row. The usual account-creation approval applies. Creating it from a standalone account first converts that account into an organization, with the same confirmation as adding any other account. A Seller account counts here only while its storefront is live. A Seller account whose storefront is archived is not counted, so an organization that holds a Buyer account beside an archived Seller account needs only a buyer plan. If the storefront is restored, the Seller account counts again. Agentic Media Company plans are the plans listed under Merchandising in the plan chooser. They cover only storefronts on Agentic Media Company, not a storefront on Just list (Listing only). A Listing plan keeps covering a storefront that is already on Agentic Media Company, which the organization held before. But an organization on a Listing plan can’t add a Storefront agent account, move one in, or switch an account to Storefront: that needs the Standard plan, and the refusal names it as the next step. Agentic Media Company plans don’t cover Listing-only storefronts. Global Market Maker is a seller plan, not a plan for a sales agent offering. It fits any organization that holds a Seller Account, on either seller product (Listing only or Agentic Media Company), including one that also holds Buyer Accounts or a sales agent offering. That makes it the one plan on which a Listing-only seller may also hold Buyer Accounts: Agentic Media Company organizations that buy need Global Market Maker today, so it covers buying for every seller it covers. An organization with no Seller Account can’t hold it. Certified Agent Developer is the only plan for an organization that holds a sales agent offering and nothing else. It can also hold one Seller Account with a Listing-only storefront, so an agent developer can test its agents against a storefront of its own. Developer is a public plan with no monthly commitment for an organization whose accounts are all Developer accounts. It covers building, testing and certifying the organization’s own agents. To add a Buyer or Seller Account, or to operate agents for other companies, the organization changes to a plan that covers it. Coverage comes from the terms of the plan the organization accepted. A plan accepted under earlier terms keeps covering what those terms covered; accepted terms are never rewritten. An organization with no accepted plan in force has not chosen a plan, and nobody is placed on one for it. It is asked to choose a plan at every sign-in. Choosing a plan is not a condition of adding an account, and accounts it already holds are never removed. When an organization chooses a plan, the chooser offers only plans that cover everything it holds, and Get in touch when none does. Once it has a plan, that plan decides which accounts it can add, as described below. A Buyer organization on Connect & Buy, for example, would become a buy-and-sell organization if it added a Seller Account. That needs an Agentic Media Company plan, or Global Market Maker by arrangement.

​
When a change is refused

Apostra refuses an account change before it happens when the organization’s accepted plan does not cover the result. This applies to:
  • creating an account, including turning a standalone account into an organization with a second account;
  • Apostra adding a Buyer Account to an existing Seller account, or moving an account into the organization;
  • switching the seller product from Agentic Media Company to Listing only, or from Listing only to Agentic Media Company on a Listing plan.
Restoring or reactivating an account the organization held is not adding one, so it is never refused for the plan. The refusal names why the change is refused and, for members of the organization, the plan it is on now. When the change would make the organization both buy and sell, it names that reason and the plans that cover it. For example: “Adding a Buyer Account would make Northwind Media both buy and sell. Organizations that buy and sell need an Agentic Media Company plan, or Global Market Maker by arrangement. Northwind Media is on Listing.” It returns 409 Conflict with the reason plan_does_not_cover_account and adds details.wouldBecomeBuyerAndSeller: true for that case. A billing administrator of the organization also gets the next step, including details.planSwitch with a link to Plan & Billing → Plan & pricing whenever the next step is to change the plan. Anyone else is told that only an administrator of the organization can change its plan. Someone outside the billing organization, such as an administrator of one child account only, is not shown the current plan.

​
Upgrading to hold Buyer and Seller Accounts

A Listing organization that wants a Buyer Account or a Storefront account moves to the Standard plan. The refusal names that as the next step (details.nextPlan is standard), and the organization account’s get_status lists it as the next step for each account type the Listing plan does not allow. Until Standard can be accepted in Plan & Billing, select Get in touch there. An organization that already holds a Buyer Account can still take that step, so it can move to a plan that covers what it holds. A Seller Account added to an organization on an Agentic Media Company plan starts on the Agentic Media Company seller product when you don’t choose one; on a Listing plan, or with no accepted plan, it starts on Just list (Listing only). Choosing Listing only on an Agentic Media Company plan is refused, because a Listing-only storefront needs a Listing plan.

​
Roles

Admin is granted when you create an identity, claim an unowned pre-provisioned identity, or accept an admin invitation. Joining through an automatically or manually approved access request grants ordinary membership; ask an admin to elevate you if you need admin rights. Members can have Basic or Premium access. A Basic member can view information their existing read permissions allow and use Murph chat, but the app and API refuse changes; when asked to make a change, Murph immediately says that write access is needed. Premium and Admin members can continue to make the changes their other permissions allow. On the Account members page, Premium access is shown as Operator and Basic access as Member. Any member can view the product as a lower role than their own: choose View as in the account switcher in the top bar, then the role. This only reduces what they can do and never grants access that their current role does not have. A banner stays at the top while you preview; choose Switch back to return to your own access. When Scope3 staff use view-as-BASIC to check an account, Murph follows the same read-only rule: it answers questions and shows information, but refuses changes.

​
An organization always keeps an admin

Only an organization’s own admins can accept its Terms of Service and manage its members, so an organization with no admin cannot be repaired by the people in it. For that reason Apostra refuses any change that would leave an active organization, or a standalone account that still has members, with no admin. That covers removing the last admin and changing their role to a non-admin role, whoever makes the change. A SUPER_ADMIN counts as an admin. If you see “Cannot remove the last admin” or “Cannot demote the last admin”, make another member an admin first, then repeat the change. If two admins are removed at the same moment, the second removal is refused and one admin remains. An account inside an organization is covered by the organization’s admins, so its own last admin can be removed while the organization still has an admin. Only Scope3 staff, confirmed as staff, can override the refusal for a specific change, and only to recover an account. A customer’s own admins and owners cannot, even with the SUPER_ADMIN role on their own account.

​
Connected apps

The Connected apps page in your account menu lists every AI host — such as Claude or ChatGPT — that has been granted an active MCP connection to your Apostra account. Each entry shows the app name, when it was first connected, and when it last refreshed its credentials. You can revoke a connection at any time. Disconnecting an app immediately invalidates its access and refresh tokens; the next time that app tries to use Apostra it must go through the authorization flow again. Disconnection does not affect your browser session or any other connected app. Grants issued before this feature was deployed appear on the page within one refresh cycle (typically under one hour). Grants on accounts that have never refreshed their tokens since deployment appear on next use.

​
REST API

You can also list and revoke MCP grants programmatically using a browser-session-authenticated request (WorkOS session required). API keys and service tokens receive 403 FORBIDDEN — this endpoint is browser-session only to ensure only a human acting in their own session can enumerate or revoke their own grants. List active grants
Response body:
Revoke a grant
Returns 204 No Content on success, or 404 if the grant does not exist or does not belong to the authenticated user (identical response for both cases — no information leak about ownership).