Authentication

PostgreSQL & Supabase

Authentication is now handled internally using Supabase's authentication process.

You can now obtain an Access Token from the V3 Dashboard, Access Tokens will expire after 60 minutes, if you wish to make requests from your application you will need to create a backend function that refreshes the access token using the Refresh Token which can also be obtained from your V3 Dashboard.

Company API Key

Managing multiple Companies has become easy as 1-2-3 with OnSched V3. Instead of managing multiple client credentials for each OnSched Company that you create, you can instead create Companies under the same user Account in the Dashboard, then access them using the same access token!

The Company API Key (included in the request as the x-xpi-key header) will define which of your Companies to fetch data from. The Company (authenticated with the access token) must be a part of your Organization to return a successful response. The Company API Key must be used in conjunction with a valid access token or the Public Client ID, and therefore may be exposed.

Securing Multiple-Company Data

If your Organization is responsible for managing bookings for more than one company, you may wish to keep the Company API Key's private by storing them as an environment variable to be used in requests made from your backend. By proxying the requests made on your front end within your own backend you will ensure that all Company Keys are held privately, restricting malicious use within the valid timeframe of an access token.

Credentials

In OnSched V3 there are 3 different keys that will be important to keep:

1. Access Token (obtained using the Refresh Token)
   An access token is a short-lived credential that must be included as a Bearer token authentication header on all requests to the OnSched API.
2. Company API Key
   The Company API Key (included in the request as the x-xpi-key header) will define which of your Companies to fetch data from.
3. Public Client ID
   The Public Client ID (included in the request as the x-client-id header) fetch data from public endpoints only. These include requests such as GET /availability and POST /appointment. You may disable use of the Public Client ID by deleting the ID via the API.

In order to find your client credentials, please navigate to the OnSched Dashboard and follow the below steps:

Expiration

Session tokens expire after 60 minutes, for security reasons this cannot be changed. We recommend that you decode the JWT to determine the expiration in a Higher Order Component (HOC) before refreshing the token with each mount.

Request URIs

Request URIs will change based on your environment (eg. Sandbox or Production). In Sandbox, you will always see a -stage at the beginning of your URI. When in Production the URIs change to "v3". For example:

API: https://api-stage.onsched.com/

...becomes

API: https://v3.onsched.com/

Headers

When requesting a token, check the following headers to be sure that they are configured as follows:

• content-type: application/x-www-form-urlencoded
• grant_type: client_credentials
• x-api-key: your_company_api_key
• x-client-id: your_public_client_id (only if using public endpoints)

Using the Bearer Token

Once you have successfully returned a valid API token you can begin making OnSched Rest API requests by including the Bearer Token in your request.

curl --location --request POST 'https://sandbox-api.onsched.com/consumer/v1/locations'
   -H "Accept: application/json"
   -H "x-api-key: {your_company_api_key}"
   -H "Authorization: Bearer {token}"