Authentication

Every Bliss API call requires an access token. Request one from the authorization endpoint, then attach it to later requests.

Send your client credentials to the authorization API. The response includes an access token. Put that token in the Authorization header on every subsequent request.

Before you begin, contact our sales team to configure your product settings (or multiple product configurations) for your customers. We provide a Sandbox environment for testing purposes before you transition to production. Each environment includes two identifiers:

client id, a client id provided by Bliss.
client secret, a client secret provided by Bliss.

Keep the client id and secret private. Load them from environment variables or a secrets store. Do not commit them to git.

POST your client id and secret to the token endpoint as a JSON body with two string fields (client_id and client_secret). Sandbox example:

curl --request POST \
     --url https://api.sandbox.blissguarantee.com/api/oauth/token \
     --header 'content-type: application/json' \
     --data '
{
  "client_id": "your_client_id_here",
  "client_secret": "your_client_secret_here"
}
'

A valid pair returns a payload like this:

{  
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.example_access_token",  
  "expires_in": 86400,  
  "token_type": "Bearer"  
}

expires_in is the lifetime in seconds (usually 86400). Cache the token and refresh it a few minutes before that window ends.

The API returns a 401: Unauthorized error when the token expires. A new token is required to complete the API request.

📘
Note: only request a new token when your existing token has expired or is about to expire

token_type is Bearer. Send access_token as Authorization: Bearer <access_token> on later calls. Example — look up a guarantee by id:

curl --request GET  
     --url https://api.sandbox.blissguarantee.com/guarantee/<bliss_id_here>
     --header 'Accept: application/json'  
     --header 'Authorization: Bearer \<your_access_token_here>'