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

# Account Access & Signup

> How signup lets you buy media, sell inventory, or offer a sales agent; creates or claims an identity; and grants the first admin.

# 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

| Choice                  | What you receive                                                                                                                                |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **Buy media**           | A Buyer account for demo/onboarding first; Organization proof, Terms, plan, standing, and the exact payment route determine later capabilities. |
| **Sell inventory**      | A Seller account with one storefront for inventory the operator owns, represents, or manages.                                                   |
| **Offer a sales agent** | An organization with a sales agent offering for registration and certification. Commercial Partner access is approved separately.               |

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.

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

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.

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.

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.

## Roles

| Role       | Can do                                                                                                           |
| ---------- | ---------------------------------------------------------------------------------------------------------------- |
| **Admin**  | Invite and manage members, connect integrations, and manage settings within the selected organization or account |
| **Member** | Use the product within the organization or account they joined                                                   |

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**

```http theme={null}
GET /api/v2/me/mcp-grants
```

Response body:

```json theme={null}
{
  "data": {
    "grants": [
      {
        "grantId": "grant_…",
        "clientId": "client_…",
        "clientName": "Claude",
        "connectedAt": "2026-01-15T10:30:00.000Z",
        "lastRefreshedAt": "2026-09-01T08:00:00.000Z"
      }
    ]
  },
  "error": null
}
```

**Revoke a grant**

```http theme={null}
DELETE /api/v2/me/mcp-grants/{grantId}
```

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