Every documented operation needs a bearer token in the Authorization header. There are two kinds:
For an integration, use an API key. See Authentication with API keys for scopes, examples, idempotent retries, rate limits and errors.
Sessions are stateless. There is no cookie, no CSRF token, and no server-side session; the token is the whole of the request’s identity.

​
User access tokens

A user access token is an Auth0-issued JWT, sent as a bearer token:
X-Organization-Id names the organization the request acts in. The signed-in person must be a member of it, and their role there decides what they can do. A request to an organization-scoped operation without the header is refused with 403. See Your account for the roles.

​
Requesting a token

The web app requests these Auth0 scopes:
Scopes and permissions are separate. The scopes above are what the frontend asks for. What a request may do comes from the person’s role in the organization named by X-Organization-Id, not from the requested scopes.

​
Streaming endpoints

The two Server-Sent Events endpoints take a user access token. API keys are not accepted there; to collect inbound messages with a key, list them with GET /api/v1/inbound/messages. GET /api/v1/inbound/stream takes the token in the Authorization header like everything else. GET /api/public/inbound/stream takes it as a token query parameter, because the browser EventSource API cannot set request headers.
A token in a query string is recorded in access logs, proxy logs and browser history. Prefer the header variant unless you specifically need EventSource.