> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chift.eu/llms.txt
> Use this file to discover all available pages before exploring further.
# Authenticate with Chift API
Every Chift API request is authenticated with a short-lived JWT bearer token. You exchange your API key credentials for a token, then send that token on every call.
If you use one of the [Chift SDKs](/developer-guides/sdk), token acquisition and refresh are handled for you — you only configure the three credentials below. The rest of this page is for direct HTTP integrations.
## 1. What you need
An API key gives you three values, used together on every token request:
| Field | Type | Description |
| -------------- | ------ | -------------------------------------------------------------------------- |
| `accountId` | uuid | Your Chift account identifier. Shown at the top left of the API Keys page. |
| `clientId` | string | Identifies the API key. |
| `clientSecret` | string | Secret for the API key. Shown **once**, at creation time. |
Create and manage keys from the [API Keys page](https://chift.app/api-keys) — see [Create and manage API keys](/back-office/getting-started/create-api-key) for key creation, rotation, and restricting a key to specific consumers.
## 2. Base URL and environments
All requests go to the same base URL:
```
https://api.chift.eu
```
There is no separate sandbox host. **The API key determines the environment**: a key created in Sandbox reaches your sandbox consumers, a key created in Production reaches your production consumers. Using a sandbox key against production data (or the reverse) fails with a `401`.
Build against Sandbox first, then create a separate key in Production when going live. Sub-environments under Sandbox and Production are available on request — see [Multiple environments](/back-office/platform/multi-environment).
## 3. Get a token
`POST /token` is the only Chift endpoint that does not require authentication.
```bash theme={null}
curl -X POST https://api.chift.eu/token \
-H "Content-Type: application/json" \
-d '{
"clientId": "YOUR_CLIENT_ID",
"clientSecret": "YOUR_CLIENT_SECRET",
"accountId": "YOUR_ACCOUNT_ID"
}'
```
Response:
```json theme={null}
{
"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"token_type": "bearer",
"expires_in": 1800,
"expires_on": 1754402400
}
```
* `expires_in` — token lifetime in seconds.
* `expires_on` — expiry as a Unix timestamp in seconds.
This is **not** a standard OAuth2 client-credentials flow: credentials are sent as a JSON body, there is no `grant_type` parameter, and no form encoding. Generic OAuth2 client libraries will not work against this endpoint — send a plain JSON `POST`.
See the [Get access token](/api-reference/endpoints/general/get-access-token) reference for the full schema.
## 4. Token lifetime and refresh
A token is valid for **30 minutes**. There is no refresh token — you request a new one from `POST /token`.
Cache the token in your application and reuse it until it expires. Do not call `POST /token` before every API request.
A workable strategy:
1. Store the token together with its `expires_on`.
2. Reuse it while `now < expires_on`, ideally with a small safety margin (e.g. 60 seconds) to absorb clock skew and in-flight requests.
3. Request a new token when it is about to expire, or when a call returns `401`.
The [Chift SDKs](/developer-guides/sdk) already implement this: you configure `clientId`, `clientSecret`, and `accountId` once, and the SDK fetches, caches, and renews the token internally. Don't build it twice.
## 5. Call the API
Send the token in the `Authorization` header of every other request:
```bash theme={null}
curl https://api.chift.eu/consumers \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN"
```
The scheme is `Bearer` (JWT). Requests without a valid token are rejected.
You can also try endpoints without writing code using the [API Explorer](/back-office/getting-started/api-explorer) in the platform.
## 6. Troubleshooting
| Status | Code | Cause | Fix |
| ------ | ---------------------------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| `401` | `ERROR_CHIFT_AUTHENTICATION_ERROR` | Wrong `clientId` / `clientSecret` / `accountId` combination, deleted key, or a key from the other environment. | Re-check the triplet, and that the key belongs to the environment you are targeting. |
| `401` | `ERROR_CHIFT_AUTHENTICATION_ERROR` | Token older than 30 minutes, or malformed `Authorization` header. | Request a new token; make sure the header is `Authorization: Bearer `. |
| `422` | — | Missing or malformed field in the request body (for example an `accountId` that is not a valid uuid). | Check the response body: it lists the offending fields. |
Full list of codes: [Error codes](/developer-guides/errors).
Chift does not rate-limit your calls, so token renewal will not be throttled — see [Rate limits](/developer-guides/rate-limits).
## 7. Security
The `clientSecret` is a server-side secret. Never embed it in a browser application, mobile app, or any client you distribute — anyone who obtains it can read and write your consumers' financial data. Perform the `POST /token` exchange from your backend and keep the resulting token server-side too.
* Store credentials in a secret manager or environment variables, never in source control.
* Rotate keys regularly; see [Create and manage API keys](/back-office/getting-started/create-api-key).
* Restrict a key to a single consumer when an integration only needs that consumer's data.
## Next steps
Create a consumer and link it to a connector.
Python and Node.js SDKs, and the OpenAPI file for Postman.
Try endpoints from the platform, no code required.
Full reference of Chift error codes.