---
title: Roles
description: Which role a token needs for each part of the API, and where the role must be granted.
---

A token can do only what its roles allow. An organization administrator grants roles to an Application. An installed connector gets the roles its app asks for when the organization installs it.

Each role is granted in one operational context. It holds there and in every context below it.

| Role | Granted at | Opens |
| --- | --- | --- |
| `Booking Integration` | A business | [Booking](/guides/surfaces/booking): sell that business's bookable resources. Only an organization's own Application can hold it. |
| `Billing Integration` | The organization | [Billing](/guides/surfaces/billing): the invoice queues and outcome reports. |
| `Signing Integration` | A business | [Signing](/guides/surfaces/signing): the signing queues and outcome reports. |

Two parts of the API need no role:

- `GET /v1/operational-contexts` lists the contexts the token's roles reach. A token with no roles gets an empty list.
- `/v1/integrations` answers an installed connector about its own installation only.

A token with no roles is still issued. Every route that needs a role then answers `403`.