Skip to main content
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, 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: Create and manage keys from the API Keys page — see Create and manage API keys for key creation, rotation, and restricting a key to specific consumers.

​
2. Base URL and environments

All requests go to the same base URL:
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.

​
3. Get a token

POST /token is the only Chift endpoint that does not require authentication.
Response:
  • 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 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 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:
The scheme is Bearer (JWT). Requests without a valid token are rejected. You can also try endpoints without writing code using the API Explorer in the platform.

​
6. Troubleshooting

Full list of codes: Error codes. Chift does not rate-limit your calls, so token renewal will not be throttled — see 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.
  • Restrict a key to a single consumer when an integration only needs that consumer’s data.

​
Next steps

Connect a consumer

Create a consumer and link it to a connector.

SDKs and tools

Python and Node.js SDKs, and the OpenAPI file for Postman.

API Explorer

Try endpoints from the platform, no code required.

Error codes

Full reference of Chift error codes.