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

# Account API permissions

> The areas an account token's permissions cover, what each holds, and how read, write and * combine with the person's own role.

An account token carries permissions, one per area of the console. Each area is read (`<area>:read`) or read and write (`<area>:write`, which includes reading it). `*` is every area, now and the ones added later.

A permission is a ceiling, never a grant of its own. The token acts as the person who made it: it can never do more than their role allows in the console, whatever its permissions say. A token with `members:write` made by a member who may not add people still cannot add people (`403 forbidden`, with a `human_action` that asks the owner by name); a token without `members:write` cannot, even for the owner (`403 insufficient_permission`, with the permission it lacks in `needs` and a `human_action` that links the person to the token's page to allow it).

Reads use the area's `read` permission, everything else its `write`. `GET /v1/me` and `GET /v1/operations` need none: any working token may ask who it is and what it may call.

## The areas

| Area | What it covers |
| - | - |
| `account` | The account's settings, the person's own profile and sessions, alerts, the account's record, and the person's tokens (list and revoke) |
| `members` | The account's members: add one, change a role or what they manage, remove one |
| `applications` | Applications: create, edit, logo, products, review, delete; their API keys and webhooks |
| `verify` | Verify's settings, test codes, and the verifications |
| `whatsapp` | The WhatsApp number, its templates and its messages |
| `contacts` | Contacts, tags, imports and opt-in |
| `campaigns` | Campaigns |
| `automations` | Automations |
| `chat` | Tawked Chat: the support team, conversation menus, the auto-attendant |
| `radeef` | Radeef, the AI agent, and its knowledge |
| `email` | Tawked Email: sending domains, the test address, limits, suppressions, messages |
| `wallet` | The balance, the statement, invoices, top-up links, billing details |
| `stores` | The Salla and Zid stores |
| `integrations` | Supabase, WooCommerce, AI assistants, connected apps |
| `clients` | A partner's clients' applications |
| `integration_apps` | A partner's own connected apps |

The console lists the same areas under **Choose per area** when you create a token. `clients` and `integration_apps` do something only for a partner account, and only for a person the console lets into those places.

## Choosing

* **Everything you can do** (`*`): an agent that sets up and runs the account with you. Its consequential calls still wait for you: with **Ask me first** (the default) you approve each one in the console ([Approvals](/account-api/person-in-the-loop#approvals)), and through an assistant's sign-in to the [MCP server](/ai/mcp-server) its chat shows you a preview and waits for your yes.
* **Read only** (every area's `read`): a report, a monitor, an agent that answers questions about the account.
* **Choose per area**: a script with one job, such as `whatsapp:write` for templates, or `email:write` for sending domains.

Permissions say which areas a token may touch; approvals say whether a consequential call in those areas waits for you first. They are set apart, in the same form: [Security](/account-api/security) has every setting of a token.

Narrow the applications too when the job is about one of them. An application outside the token's choice answers `404 not_found`, wherever the request names it. Such a token reads the account's members with their access to those applications only, and may not change the account's members (`403 token_narrowed`). A partner's client applications are the `clients` area's, and the token's choice of applications does not narrow them.

## Reading a permission from the API

`GET /v1/me` answers the token's `permissions` as stored (`["*"]`, or a list such as `["whatsapp:write", "email:read"]`; a read is left out when its area's write is there). Every operation in `GET /v1/operations` and in the reference names the permission it needs: `permission` in the search, `x-permission` in the OpenAPI document. A search lists every matching operation, with `allowed` (whether this token may call it) and, when it may not, `needs`, the permission to add. The MCP server's `search_tawked_api` marks them the same way.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.