Skip to main content
A token’s permission is a module × method matrix. Every API route belongs to a module, and the method is the request’s HTTP verb. For a call to work, the token needs that method enabled on that module.
This token can read and create contacts and read tickets, and nothing else. PUT /contacts/{id} responds 403, as does any call to products, campaigns or CRM.
Permission is the last check performed. Before it, the API confirms that the token is valid, the company is active, the plan includes the API and the request limit has not been reached. So a scope 403 always means the token was valid and the call reached the right endpoint.

​
The modules

contacts

Contacts, extra fields and marketing origin.

tickets

Opening, transferring, closing and wrapping up.

messages

Asynchronous sending and reading of messages.

channels

Channels and templates. Read-only.

webchat

Webchat visitor sessions and messages.

tags

Tags and their link to tickets.

queues

Service queues and their agents.

wrapups

Wrap-up types.

users

Agents, administrators and invitations.

profiles

Permission profiles. Read only.

schedules

Scheduled messages.

quick-messages

Quick replies.

campaigns

Bulk sends and their execution.

crm

Boards, stages, cards and metrics.

products

Catalog, categories and performance.

custom-fields

Custom fields and global variables.

reports

Reports and dashboards.
The methods are GET, POST, PUT and DELETE. No v1 route uses PATCH, so it is not on the list. The profiles module accepts GET only. It exists so you can find the profileId used when inviting or editing a user; profiles are created and edited in the dashboard. The webchat module accepts GET and POST: with it, your system opens a visitor session, sends the visitor’s messages and reads the replies. The webchat is configured in the dashboard.

​
Choosing the scope

Give the token only the permissions the integration needs to work. Some common examples:
Read-only. Even if it leaks, a token like this cannot change any data, so it is a good choice for third-party tools.
Enough to send messages and find the channelId of the outbound channel. You don’t need to include contacts or tickets, because sending already creates the contact and the ticket when needed.
This scope does not include DELETE. If the sync has a bug and deletes contacts, the damage is hard to undo. If the integration needs to delete contacts, use a second token in a separate routine.
Moves cards and records notes. Reads contacts and the catalog without being able to change them.
Write permission on users gives administrator power. With users: ["POST"], the token invites people to the company. With users: ["PUT"], it changes the profile of people who are already part of it and can even promote someone to administrator. Grant these two permissions only to HR or provisioning integrations that really need them.

​
When permission is missing

The message tells you the method and the module that were missing. To fix it, open the token in the panel and check that combination.
The list of modules above is the same one the panel shows when you create a token. If the panel shows a module that is not listed here, treat the panel as the correct reference.

​
What the token never does

Regardless of the permissions checked:
  • It does not manage tokens. Creating, editing, rotating and revoking tokens requires an administrator session in the panel.
  • It does not switch companies. The company is always the token’s own. A companyId sent in the body is ignored.
  • It does not see the super admin. The platform’s support membership does not appear in GET /users and cannot be changed through the API.