Booking API: Overview

Introduction

Caspeco’s own services use OAuth2 for authentication/login. The login procedure gives you access to a temporary Access Token which must be attached with all requests to the API. The login is never linked to a unique system (customer), but the system to be used is later determined by the system header attached to each request.

In addition to the standard flows supported in OAuth2, there is also the possibility of creating a so-called Personal Access Token (PAT). These special Access Tokens are created manually and last for a very long time, meaning the client does not have to log in every time you need to call the API, or when even the usual Access Token has expired. Furthermore, these Access Tokens can be deactivated if you suspect they may have leaked to a third party, and they will then stop working immediately, unlike regular Oauth2 access tokens that are only short-lived. We recommend all our customers to use Personal Access Tokens in cases where you need to integrate with Caspeco’s API and will therefore only describe how to use these in this document.

API Documentation

You can access all documentation of the Booking API under the API Reference section, where it is also possible to test API methods interactively. For password-protected resources, Oauth2 Implicit Flow is used to log in / retrieve an access token.

System Parameter

Most methods require the following additional header indicating which system/database is intended for this request. If required and missing, a 401 response (unauthorized) is returned. A system is today equal to a Company.
system: <systemnamn> (Ex: se__testbb)

It is also possible to specify system name as a query string parameter, e.g.:
https://rms.caspeco.se/api/booking/v1<metod>?system=se__testbb

Contact Caspeco if you are unsure which system name to use.

Caspeco Booking - Structure

Further details about the booking structure will be documented here.