Skip to main content
The API uses two credentials on every request: your API key (x-api-key header) and your TAPI token (x-authorization-token header). Both are required: without x-api-key the request is rejected with 403, and without a token with 401 (see Authentication errors).

The two credentials

string
required
Your integration’s API key on the Tapi API Gateway. Tapi provisions it for you and it is different per environment (development, staging, production). It identifies your application and controls access to the gateway.
string
required
Your TAPI token (a JWT), the same one you already use with the rest of the Tapi platform. It is sent without the Bearer prefix.
The token goes in x-authorization-token, not the standard Authorization: Bearer, and without the “Bearer” prefix. It is a Tapi-specific header used to maintain compatibility with the rest of the platform.

Get your TAPI token

The TAPI token (a JWT) comes from the Tapi login, the same one you already use with the rest of the platform. Send your credentials and you will receive an accessToken:
The response includes the accessToken (your TAPI token) and a refreshToken:
The accessToken expires after ~4 hours. When it expires, log in again (or use the refreshToken with the standard Tapi flow). The login x-api-key is your integration’s key and is not the same one you use against the API.

Test an endpoint

In the API Reference, open any endpoint and use the Send button:
  1. Pick the server in the selector.
  2. Paste your x-api-key and your x-authorization-token into the authentication fields.
  3. Fill in the parameters and press Send.
Your credentials are stored only in your browser and are reused across all endpoints.
Never share or commit your x-api-key or your token to a repository: they are sensitive credentials. In the playground they live only in your browser; in curl, pass them as environment variables.

What your token resolves for you

Starting from your token, Tapi identifies your account and internally resolves the entire internal model (company, modalities, etc.). You work with clear business concepts and never need to send or know that internal data.

Authentication errors

Authentication errors are issued by the API Gateway, before the request reaches the API. That is why they do not use the error envelope and carry no requestId: the body is an object with a single field.
In the permission 403 the field is capitalized (Message), not message. Keep it in mind when typing the response. A missing or invalid x-api-key returns 403, not 401.
Every other API error follows the standard shape: an error object with code and message, plus a requestId that you can share with support to trace the request. See Error handling.

Expired token

If your token expired, refresh it with the same flow you already use for the rest of the Tapi API and retry the request. The API has no refresh mechanism of its own: it reuses the one from the Tapi ecosystem.
Tip: if you use a Tapi SDK, the x-api-key and x-authorization-token headers come preconfigured, so you don’t have to build them by hand.