REST API

Zeitwart should not be the only software that knows anything about your rooms. Through the REST API other systems ask which rooms exist and when they are occupied – for an intranet, a display board, a reporting tool or an application of your own.

Signing in with a token

Access runs through a bearer token that you create on a user account. The token carries exactly the permissions of that account – it is not a master key but inherits the normal permission structure of roles and organisational units.

For an integration it is therefore best to create a dedicated service account with a tightly cut role, rather than using an administrator's personal account. If the token falls into the wrong hands, the damage is limited to what that account was allowed to do anyway.

For security reasons the token is displayed exactly once and cannot be read afterwards. If it is lost, you create a new one.

What can be queried

• the rooms and resources visible to the account

• their bookings for a period you choose

• the associated master data including custom attributes

Detailed documentation of every endpoint – including a Postman collection to try things out – is available from support.

When the API is the right tool

The API is the way when your system asks Zeitwart. For the opposite direction – Zeitwart reporting an event to your system, for example at the start of a booking – webhooks are the better mechanism. And anyone who only wants to display appointments usually gets there faster with an iCal feed.

For permanently installed devices without a sign-in there is also an IP-bound login URL on the account.

Benefits at a glance

• access through a bearer token created on a user account

• the token inherits the permissions of its account – no master key

• dedicated service accounts with tightly cut roles recommended

• detailed endpoint documentation including a Postman collection

• complements webhooks for the other direction and iCal for pure display