For machine-to-machine communication, the Client Credentials Flow is used as specified in section 1.3.4. of RFC6749.

Please note that this flow must not be used in single page applications (SPAs) and native applications under any circumstances. The client secret must be kept confidential and static client secrets could easily be extracted by third parties!

1. A non-browser (e.g. backend service) requests a refresh token from the bookingtime authorization server. Authentication is done either by setting client_id and client_secret as basic authorization header or by submitting these values in the request body. If the parameters are submitted in both ways, the values in the header are used. The request is a POST request with the following application/json encoded parameters:
   • grant_type: The only valid value is client_credentials.
   • client_id: The ID of your client, as submitted when you register your application. Must be App or Module ID, according to the API to query.
   • client_secret: This field is required or not available, depending on the addressed API.
     App API: The secret of your client, as submitted when requested. How to register applications. Currently only possible, if the app will be created before an organization. Please contact the support for help.
     Module API: Not available or empty, both will be accepted.
2. The authorization server validates the credentials and generates a refresh token.
3. The authorization server returns a refresh token to the client.
4. The client requests a access token from the authorization server, using the refresh token. The request is a POST request with the following application/json encoded parameters:
   • grant_type: The only valid value is refresh_token.
   • client_id: The ID of your client, as submitted when you register your application. Must be App or Module ID, according to the API to query.
   • refresh_token: The refresh token you just received.
   • organization_id: (optional) The ID of the organization to query.
5. The authorization server returns a access token to the client.
6. The non-browser client can now perform authenticated requests to the bookingtime APIs as long as the access token is valid.

Example of client credentials to refresh token exchange with cURL:

export var CLIENT_ID=70B9EOUxfSN0p866nCa2zGVKmaaaTEST
export var CLIENT_SECRET=1234567890123456789012345678901234567890123456789012345674444444

curl -X POST \
  -d grant_type=client_credentials \
  -u client_id:$CLIENT_ID
  -u client_secret:$CLIENT_SECRET
  https://auth.bookingtime.com/oauth/token

Example of refresh token exchange for a access token with cURL:

export var CLIENT_ID=70B9EOUxfSN0p866nCa2zGVKmaaaTEST
export var REFRESH_TOKEN=eyJ0...I60
export var ORGANIZATION_ID=f6...gw

curl -X POST \
  -d grant_type=refresh_token \
  -d client_id=$CLIENT_ID \
  -d refresh_token=$REFRESH_TOKEN \
  -d organization_id=$ORGANIZATION_ID \
  https://auth.bookingtime.com/oauth/token

To obtain a new access token using the refresh token, the Refresh Token Flow is used as described in section 1.5. of RFC6749.
This flow can be used by browsers and non-browser based clients.

1. A browser or non-browser requests a refresh token from the bookingtime authorization server. This is done by a POST request using the following application/json encoded parameters:
   • grant_type: The only valid value is refresh_token.
   • client_id: The ID of your client, as submitted when you register your application. Must be App or Module ID, according to the API to query.
   • refresh_token: The refresh token you got with the authorization or client credential flow.
   • organization_id: (optional) The ID of the organization to query.
2. The authorization server validates the refresh token and generates a access token.
3. The authorization server responds with a access token.
4. The client can now make authenticated requests to the bookingtime APIs as long as the access token is valid.

The refresh token will be rejected before expiration in the following cases:

• the user changes his password (see Authorization Code Flow)
• the app/module changes
• the client secret is changed (see Client Credentials Flow)

Example of refresh token to access token exchange with cURL:

export var CLIENT_ID=70B9EOUxfSN0p866nCa2zGVKmaaaTEST
export var REFRESH_TOKEN=eyJ0e...
export var ORGANIZATION_ID=f6dS3eSezWO4ohcznIzoTb5JzzmbTEST

curl -X POST \
  -d grant_type=refresh_token \
  -d client_id=$CLIENT_ID \
  -d refresh_token=$REFRESH_TOKEN
  -d organization_id=$ORGANIZATION_ID