Skip to main content
The BrandWallet API uses a two-credential exchange to produce access tokens. You send your API key — which identifies your integration — and an API secret — which identifies the merchant organization — to receive a Bearer token scoped to that organization. Every subsequent API call includes this token in the Authorization header. Two auth endpoints cover the whole lifecycle:

Credentials

Your API key and secrets grant access to merchant data. Never embed them in client-side code or expose them in a browser. Only transmit them over HTTPS.

Get a token

Call POST /auth/token with your credentials as request headers — no request body is required. Both credentials are validated as a pair: a valid key with a secret that belongs to another integration is rejected. The token is issued on behalf of the organization’s service account and is scoped to that organization.

Request headers

string
required
The API key issued to your integration.
string
required
The API secret issued for the connected organization.

Response fields

string
The JWT access token. Pass this value as Bearer in the Authorization header on all API requests.
string
The token type. Always Bearer.
number
Token expiry expressed as a Unix epoch timestamp in milliseconds. Compare this value against the current time to determine when to refresh.
string
A token you can use to renew the session without re-sending your credentials. See Refresh a token below.

Call the API

Include Authorization: Bearer <accessToken> on every subsequent request. BrandWallet validates this token on each call and rejects requests with missing, expired, or malformed tokens. When your token expires, either refresh it or request a new one with your credentials.

Refresh a token

Instead of re-sending your credentials every time a token expires, call POST /auth/refreshtoken with the current accessToken and refreshToken pair. BrandWallet returns a new token pair and immediately invalidates the old refresh token.
Refresh tokens are rotated — each successful call invalidates the token you send and returns a brand-new pair. Always replace both stored tokens immediately after a successful refresh. Replaying an old refresh token fails with _invalid_refresh_token.

Body parameters

string
required
The access token issued together with the refresh token. This may be expired — the refresh endpoint accepts it regardless of expiry status.
string
required
The refresh token from the same token response. Must be the latest token in the rotation; previously used tokens are invalidated.
The response has the same shape as POST /auth/token: a new accessToken, tokenType, expiresIn, and refreshToken.

Error codes

For the complete list of error codes returned across all endpoints, see the Error Reference.
Last modified on August 6, 2026