Skip to content

Authentication and sub-partners

Abi API requests use bearer access tokens generated from your partner API key. Authentication belongs in your server-side integration.

  1. Send your x-api-key to the create access token operation. Its JSON body is optional; include subPartnerName only when the token must be scoped to a configured sub-partner.
  2. Store the returned access and refresh tokens in your server-side secret store.
  3. Send the access token in the Authorization: Bearer <token> header.
  4. Refresh the token before or after expiry using the refresh access token operation. The refresh request uses the current access token in Authorization and the refresh token in the separate refresh-token header.

Send the partner API key in the x-api-key header. The request body may be omitted:

Terminal window
curl -X POST '{{url}}/partner/authorization/token' \
-H 'x-api-key: {{x_api_key}}'

To scope the token to a configured sub-partner, include the optional body:

{
"subPartnerName": "..."
}

The refresh request requires both headers below. The body is optional and supports the same subPartnerName scope:

Terminal window
curl -X POST '{{url}}/partner/authorization/token/refresh' \
-H 'Authorization: Bearer {{access_token}}' \
-H 'refresh-token: {{refresh_token}}' \
-H 'Content-Type: application/json' \
-d '{"subPartnerName":"..."}'

Omit the Content-Type header and body when no subPartnerName is needed.

Access tokens expire after one hour. Refresh tokens expire after 24 hours; when a refresh token has expired, request a new token with the partner API key. An expired access token returns 401 Unauthorized.

Where an integration operates multiple brands, services, or environments, Abi can scope a token using subPartnerName. When that scope is embedded in the token, requests should not duplicate the value in individual request bodies unless the API contract requires it.