Skip to main content
All SCX APIs (Channel, Seller, Public, Auth) use the same token-based authorization flow. You exchange a long-lived refresh token for a short-lived access token, then pass that access token as a Bearer header on every subsequent request.
Refresh tokens are issued during onboarding. If you don’t have one yet, see Seller Management for the sign-up flow.

​
Token Exchange

Call POST /v1/auth with your refresh token to obtain an access token. See the Auth API reference for the full request and response schema. The response includes:
  • authToken: the access token to use as a Bearer credential.
  • tokenExpireAt: absolute expiry in ISO 8601.
  • expiresIn: lifetime in seconds.
  • scope: the authorization scope tied to your refresh token (for example, CHANNEL or SELLER).

​
Using the Access Token

Send the access token as a Bearer token in the Authorization header on every SCX API request: 
Authorization: Bearer eyJ0eXAi....

​
Expiry and Refresh

Access tokens are short-lived. Refresh them proactively before tokenExpireAt rather than waiting for a 401 Unauthorized response.
Do not call POST /v1/auth on every request. The Auth API is rate limited, and hammering it will return 429 Too Many Requests. Cache the access token in memory until close to expiry, then refresh once.
A reasonable pattern:
  1. On first use, call POST /v1/auth and store authToken together with tokenExpireAt.
  2. Before each API call, check whether tokenExpireAt is more than 60 seconds in the future. If yes, reuse the cached token.
  3. If not, call POST /v1/auth again with the same refresh token to obtain a new access token.

​
Next Steps

Rate Limits

Understand the per-endpoint quotas and 429 handling across all SCX APIs.

Auth API Reference

Endpoint-level reference for POST /v1/auth.