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

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. Switching accounts in Claude or ChatGPT with switch_account changes the account those assistants act on and does not change the web app. 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. Scope3 can invite a named Buyer administrator even when the organization has an older Seller account whose Storefront is archived. The invitation grants access to the new Buyer account only. The Seller account, its history, members, domain, and archived Storefront remain in place; the invitation does not reopen selling or grant control of the Seller account. The invited person accepts and verifies the email address named in the invitation to enter Buyer Setup. Organization-wide Terms and billing for a Buyer child still require a parent administrator or separate Scope3-assisted setup; a Buyer-only invitation does not grant that authority. After this organization conversion, a new Seller administrator joins the existing Seller child through an invitation or assisted recovery. 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 recoverable Seller account, select Buy media. When the Seller has one archived storefront, no active administrator or pending invitation, no active commercial resources, and one confirmed organization link, verifying your email creates a separate Buyer account under that organization and makes you its Buyer administrator. The Seller account, its members, service tokens, and archived storefront stay attached to the Seller child. Buyer administration does not grant Seller or parent administration. If the organization has another owner, active commercial setup, or ambiguous account history, request Buyer access for review. The review request does not claim the Seller account, reactivate its 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.

​
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 Organization settings → Members. An admin of an administered standalone account manages access in that account’s member 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. 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; in that case you tell Apostra which of the account’s administrators become organization administrators. What moves to the organization:
  • your contract, billing authority, and agreement documents;
  • your plan, its feature access, and the number of accounts it allows;
  • an existing sales agent offering.
What stays with the account: its storefront, advertisers, campaigns, media buys, history, domain, and members. Who administers it:
  • The administrator who converts the account becomes an organization administrator. When Apostra converts it for you, the administrators you named become organization administrators instead.
  • 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): if the account has its own standing, that still takes precedence; otherwise it inherits the organization’s standing. 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: 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 covers a storefront on either seller product, because an Agentic Media Company storefront includes listing. So the compatibility runs one way: Listing plans cover Agentic Media Company storefronts, but Agentic Media Company plans don’t cover Listing-only storefronts. To move a Listing-only storefront onto an Agentic Media Company plan, switch it to Agentic Media Company first. 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 without an accepted plan (Free) can hold any mix of accounts. When it chooses a plan, the chooser offers only plans that cover everything it holds, and Get in touch when none does.

​
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;
  • restoring an archived account;
  • Apostra adding a Buyer Account to an existing Seller account, moving an account into the organization, or reactivating one of its accounts;
  • switching the seller product from Agentic Media Company to Listing only.
The refusal names the plan the change needs and, for members of the organization, the plan it is on now. For example: “Adding a Buyer Account needs an Agentic Media Company plan. Northwind Media is on Listing.” It returns 409 Conflict with the reason plan_does_not_cover_account. A billing administrator of the organization also gets the next step. 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 takes three steps, in order:
  1. Switch the seller product to Agentic Media Company in Settings → How would you like to sell? The Listing plan already covers that storefront.
  2. Accept an Agentic Media Company plan in Plan & Billing, or select Get in touch there. That plan can only be chosen once the storefront is on Agentic Media Company.
  3. Add the Buyer Account.
The refusal always names the next of these steps. Switching the seller product never chooses a plan for you. An organization that already holds a Buyer Account can still take the first 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.

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