> ## Documentation Index
> Fetch the complete documentation index at: https://www.text.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Users and accounts

> Who participates in Text conversations, how they're grouped for routing, and how identity works across accounts and organizations.

## Users

Three types of users can participate in a chat:

<CardGroup cols={3}>
  <Card title="Agents" icon="headset">
    The people on your team. When an agent joins a chat through the Text
    interface or via the API, they become a participant. Their messages are
    events.
  </Card>

  <Card title="Customers" icon="user">
    The people your team talks to. A customer starts a chat and sends messages.
    They can have custom properties attached — like their order ID or account
    tier.
  </Card>

  <Card title="Bots" icon="robot">
    Automated participants that act on the agent side. A bot can send messages,
    close chats, and handle routing — just like a human agent, but
    programmatically.
  </Card>
</CardGroup>

<Accordion icon="code" title="Creating bots and issuing bot tokens">
  Bots are created through the Configuration API. Once you've created one, use
  the [`Issue Bot Token`](/api/configuration/v3.6/bots/issue-bot-token) method
  to get a token for it, then pass that token as a Bearer token — the same way
  you'd use a human agent's access token. At the protocol level, the Agent Chat
  API treats bots and agents identically.
</Accordion>

## Teams

Teams group agents for routing — determining who handles an incoming chat or ticket. The two team types are independent of each other:

* **Chatting teams** — handle live chat conversations, managed through the [Configuration API](/api/configuration/).
* **Ticketing teams** — handle tickets, managed through the [Ticketing API](/api/ticketing).

## Accounts

Text's identity layer is called **Global Accounts**. It's the system that manages accounts and organizations across the platform, and it's exposed through the [Global Accounts API](/api/global-accounts/).

An **account** is a single identity — one person, one set of credentials — that can access Text.

Every account has a unique ID. When your code makes an API call, it's always acting as a specific account — the one that owns the token being used.

<Accordion icon="code" title="How accounts are identified">
  Every account has a unique `account_id` (a UUID) that appears in every token response and authorization-related API call.

  To look up the account tied to the current token, call [`GET /accounts/me`](/api/global-accounts/accounts/get-an-account) — `me` resolves to whoever owns the token making the request.
</Accordion>

## Organizations

An **organization** is the workspace that holds a team together. Think of it as the equivalent of what you see in Text as "your company" — the thing with the agents, chats, and settings.

A few things to know:

* Every organization has at least one account, and at least one owner.
* An account can belong to **multiple organizations** at once. A consultant working across several client accounts, for example, has one login but can switch between organizations.
* Each account has a **default organization** — the one it lands on at login.
* Organizations track which Text products are installed on them.

<Accordion icon="code" title="Organization IDs and useful endpoints">
  Every organization has an `organization_id` (a UUID). Both `account_id` and `organization_id` are included in every OAuth token response, so you always know which account and organization a token belongs to.

  Two endpoints are worth knowing: [`GET /organizations/my`](/api/global-accounts/organizations/get-an-organization) returns the organization tied to the current token, and [`GET /info`](/api/global-accounts/tokens/introspect) introspects the token itself — returning its scopes, expiry, `account_id`, and `organization_id`.

  Organizations also have an invitation mode. The default, `lax`, lets all paid roles send invitations. Set it to `strict` to limit that to privileged roles only.
</Accordion>

## Why this matters for integrations

When you use a personal access token, it's tied to your account and implicitly scoped to your default organization. Simple.

When you build an OAuth integration — one where other users authorize your app — the token you receive represents a specific account acting within a specific organization. Both are part of every authorization response.

<Tip>
  If you're using a personal access token for a personal script or internal
  tool, you don't need to think about this much. This becomes important when
  you're building for other users.
</Tip>

<Accordion icon="code" title="Handling multiple organizations per user">
  If your app serves multiple Text customers, don't use `account_id` alone as the key for a workspace context — an account can belong to more than one organization. Store `(account_id, organization_id)` pairs instead.

  When issuing a customer access token through the cookie grant flow, `organization_id` is required — the auth server needs it to know which organization the customer belongs to.

  [`POST /organizations`](/api/global-accounts/organizations/create-an-organization) creates both a new organization and an account in a single call, and doesn't send any email notifications.
</Accordion>