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

# Concepts

> How organizations, projects, sessions, credentials, messages, webhooks, and Sandbox fit together.

Polymorfa keeps account administration separate from messaging access. Start
with the organization and project hierarchy, then choose the credential that
matches the operation you need.

## Organizations and projects

An organization is called a **team** in parts of the Console. It owns members,
billing, organization keys, projects, and organization-level audit history.
Current member roles are **Owner**, **Admin**, and **Member**.

A project groups messaging resources such as sessions, project tokens,
webhooks, templates, campaigns, and integration settings. Project tokens are
bound to one project, so they cannot authorize access to another project's
resources.

## Sessions

A session represents one connected number. Each session has a stable
identifier used in Messaging API paths such as `/api/{session}/messages/send`.

The public Messaging API types use three connection states:

| Status         | Meaning                                                                  |
| -------------- | ------------------------------------------------------------------------ |
| `CONNECTING`   | The connection is being established.                                     |
| `CONNECTED`    | The session is ready for supported messaging operations.                 |
| `DISCONNECTED` | The session is not connected. Pair, start, or inspect it before sending. |

Testing sessions use identifiers beginning with `test_`. They are created in a
development project and do not start a real WhatsApp connection.

## Credentials

| Credential       | Prefix or format | Use                                                                          |
| ---------------- | ---------------- | ---------------------------------------------------------------------------- |
| Organization key | `titan_…`        | Trusted server access across resources authorized for an organization.       |
| Project token    | `titan_pt_…`     | Trusted server access restricted to one project and an explicit scope set.   |
| Client token     | `titan_ct_…`     | Short-lived browser or mobile access restricted by session and client rules. |
| Dashboard bearer | JWT              | Signed-in Console and account requests.                                      |

Public `/v1/*` Platform API operations accept an organization key or verified
dashboard bearer. They reject project tokens. Messaging API, MCP, and
bridge operations accept only the credential kinds stated in their generated
reference.

Every service credential is a bearer secret. Keep organization keys and project
tokens on trusted servers, request the narrowest scopes needed, and revoke a
credential when it may have been exposed. See [Authentication](/api/authentication)
for the current scope names and audience rules.

## Messages and webhooks

Messaging endpoints use typed request and response bodies for text, media,
location, contact, poll, reaction, and other supported operations. Use the
generated Messaging API reference for the exact fields and formats.

Webhooks deliver events to your HTTPS endpoint. Native deliveries use
`X-Webhook-Signature`; Meta-compatible deliveries use
`X-Hub-Signature-256`. Verify the signature against the raw request body before
parsing it. The [Webhooks guide](/api/webhooks) lists the current event names,
formats, and retry settings.

## Versioning

Messaging API requests can pin the current date version:

```http theme={null}
Titan-Version: 2026-03-20
```

Meta-compatible paths use their own `vNN.0` version. See [Versioning](/api/versioning) for
the current defaults and response headers.

## Sandbox

Sandbox provides testing-number workflows for development projects. Free
testing numbers have a 5 messages-per-second limit, 0.25 GB of included storage,
and do not include campaigns, calls, or serverless executions. Sandbox pool,
claim, device, and message operations have their own documented routes; do not
assume every production operation has a simulated equivalent.

## Where to go next

<Columns cols={2}>
  <Card title="Quickstart" icon="rocket" href="/quickstart">
    Make your first authenticated request.
  </Card>

  <Card title="API overview" icon="code" href="/api/overview">
    Choose the correct API contract.
  </Card>

  <Card title="Authentication" icon="lock" href="/api/authentication">
    Match credentials and scopes to routes.
  </Card>

  <Card title="Sandbox" icon="flask" href="/sandbox/introduction">
    Test with development-project numbers.
  </Card>
</Columns>