Authentication at a Glance
| API | Auth mechanism | Token type | Lifetime |
|---|---|---|---|
| JTL Cloud API | OAuth 2.0 Client Credentials | Short-lived JWT | ~1 hour (refresh before expiry) |
| OnPremise ERP API | Proprietary registration flow | Static API key | Permanent |
| SCX Channel API | Refresh token exchange | Short-lived access token | ~1 hour (refresh before expiry) |
Two Types of Tokens (Cloud)
If you’re building on the Cloud platform, you’ll use two tokens:| Token | How you get it | What it’s for | Who creates it |
|---|---|---|---|
| Access token (JWT) | Client credentials grant > JTL Identity Provider | Authenticating your backend’s API calls to JTL | Your app’s backend |
| Session token | appBridge.method.call('getSessionToken') | Identifying which merchant (tenant) and user is interacting with your app | JTL App Shell (via AppBridge) |
Check out the Cloud Apps: Authentication & Login guide to learn more about Cloud Apps authentication (JWKS, AppBridge integration).
- JTL Cloud (OAuth 2.0)
- OnPremise (API Key)
Cloud Authentication (OAuth 2.0)
The Cloud API uses the OAuth 2.0 Client Credentials Flow. Your app’s backend authenticates with a client ID and secret, receives a short-lived JWT, and uses that JWT as a Bearer token for all API requests.Prerequisites
Your app must be registered in the Partner Portal. Registration creates an OAuth client with aClient ID and Client Secret.How the Flow Works
- Your backend sends its client credentials to the JTL Identity Provider
- The Identity Provider returns a short-lived JWT access token
- Your backend includes that token (along with the tenant ID) in every API request
Token Endpoint
| Component | Value |
|---|---|
| Method | POST |
| Content-Type | application/x-www-form-urlencoded |
| Authorization | Basic <Base64(clientId:clientSecret)> |
| Body | grant_type=client_credentials |
| Field | Description |
|---|---|
access_token | The JWT to use in API requests |
token_type | Always Bearer |
expires_in | Token lifetime in seconds. Request a new token before this expires. |
Reference Examples
Making Authenticated API Requests
Once you have an access token, include it in every API request along with the tenant ID.Base URL:| Header | Value | Description |
|---|---|---|
Authorization | Bearer <JWT> | The access token from the client credentials flow |
X-Tenant-ID | <tenantId> | The JTL Cloud tenant ID (identifies which merchant’s data you’re accessing) |
Check out the Cloud Apps: Authentication & Login guide to see how to get the tenant ID.
Token Lifecycle
Access tokens are short-lived and expire after a set period (typically 1 hour). Your app needs to handle this:- Cache the token and reuse it until it’s close to expiry
- Refresh proactively (e.g. when < 5 minutes remain)
- Handle
401 Unauthorizedby refreshing once and retrying
Security Schemes
Cloud endpoints are secured using one of two schemes:| Scheme | When it applies |
|---|---|
Wawi AND oauth2-cloud-id-accessCode | User-bound access: the request is tied to a specific user’s session |
Wawi AND oauth2-application | Machine-to-machine access: your backend calls the API directly using client credentials |
JTL Cloud vs. OnPremise Comparison
| Feature | Cloud | OnPremise |
|---|---|---|
| Auth mechanism | OAuth 2.0 (Client Credentials) | Proprietary API key flow |
| Token type | Short-lived JWT Bearer token | Permanent static API key |
| Registration | Partner Portal | JTL-Wawi desktop Admin >> App Registration |
| Credentials | ClientId + ClientSecret | Registration ID >> API key |
| Tenant identification | X-Tenant-ID header required | Not required (local connection) |
| Base URL | https://api.jtl-cloud.com/erp/v2/ | http://127.0.0.1:<port>/api/eazybusiness/ |
| Authorization format | Bearer <JWT> | Wawi <PERMANENT_API_KEY> |
| Token refresh | Re-request with client credentials before expiry | Not needed (key is permanent) |
SCX Channel API Authentication
The SCX Channel API uses the same client credentials mechanism as the Cloud-ERP API. You request an access token, use it for API calls, and request a new one before it expires. This section applies only to Marketplace Channel integrations. Base URL:How the Flow Works
Requesting an Access Token
| Field | Description |
|---|---|
scope | The scope of the token (e.g. CHANNEL) |
authToken | The access token for authenticating requests |
tokenExpireAt | Expiration timestamp in ISO 8601 format |
expiresIn | Time in seconds until the token expires |
Using the Access Token
Include theauthToken as a Bearer token in all subsequent requests:
Token Lifecycle
SCX access tokens have a TTL (Time To Live) of 1 hour. Your app should:- Cache the token and reuse it until it’s close to expiry
-
Monitor the
expiresInvalue and refresh proactively (e.g. when less than 5 minutes) - Refresh tokens before they expire to avoid failures during requests.
Best Practices
These practices apply regardless of which auth mechanism you’re using: Credential storage- Never hardcode credentials in source code. Use environment variables or a secrets manager.
- Never commit
.envfiles to version control. - Rotate credentials if you suspect they’ve been compromised.
- Cache tokens and reuse them. Don’t request a new token for every API call.
- Refresh proactively before expiry, not after receiving a 401 error.
- On a 401 response, refresh the token and retry the request once.
- Always use HTTPS for Cloud and SCX API calls.
- Validate session tokens server-side. Never trust tokens received from the client without verification.
- Request the minimum required scopes. Don’t request broader access than your app needs.
Next Steps
API Keys & Tokens
Deeper dive into JWT structure, session tokens, and token management
patterns.
Scopes & Permissions
Understand which scopes are available and how to request the right level
of access.
Cloud Apps: Authentication
Implementation guide for authentication in Cloud Apps: AppBridge,
session tokens, and the setup handshake.
Error Handling
How to handle auth errors, expired tokens, and common failure modes.