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

# Authentication

> Every e6data API request carries a token in the Authorization header.

Send a token as a bearer token:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
curl -H "Authorization: Bearer <token>" https://<host>/...
```

## Which credential to use

| Caller | Credential | Where to get it |
| - | - | - |
| You, from a script or notebook | Personal access token | [Create, rotate and revoke tokens](/platform/tokens/create-rotate-revoke) |
| Apps, pipelines and CI | Service account key (service token) | Created under **Access Control** in the console. See [Users, groups and service accounts](/platform/identity/users-groups-service-accounts). |
| SQL over REST sessions | Session token from `POST /api/v1/authenticate` | [Authenticate](/api-reference/query-sql/authentication/authenticate) |

The SQL over REST API also accepts a personal access token, or an SSO/OIDC JWT, directly as the bearer token.

## Permissions

Each call is checked against role-based permissions. A `403` response names the permission the call needs, so you can grant least privilege. See [Roles and permissions](/platform/identity/roles-and-permissions) and the [permissions matrix](/platform/reference/permissions-matrix).

## Keep tokens safe

* A raw token is shown exactly once. Store it in a secret manager when you create it.
* Use one credential per consumer. Set an expiry and rotate it before it lapses.
* Never log or commit the secret. Log the token ID instead.

More in [Token security best practices](/platform/tokens/best-practices).


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