Understanding bookings

Booking graphs are blueprints for which steps a booking transitions through.


Working with the API

Take a look at our API reference to learn more about the different endpoints in the API.

➡️ Graphs API reference

Introduction to booking graphs

To sum it up, in Timekit terms a booking is a request to reserve a time-slot in a calendar. Based on the use-case a booking needs to go through a number of steps, before the requested time-slot is reserving time in the resource's calendar, making the resource unavailable at that time.

To really harness the full power of Timekit, you need to comprehend these different steps called states, that a booking transitions through. The change of state over time constitute a flow and the configuration of each flow is controlled by graphs.

To get the best fit between your use-case and Timekit, its important that you choose the most fitting graph.

Timekit currently operate with these booking graphs:


For when a booking request should immediately reserve time in the resource's calendar, thus making the time-slot unavailable.

Instant (payment)

For when you need to register the payment in order to keep the time-slot unavailable for bookings.

Confirm / decline

For when the booking request should be confirmed, before the time-slot is reserving time in the resource's calendar.

Booking Graphs + Webhooks

If you have enabled webhooks, they will be triggered when a booking reaches the relevant states. So when a booking transitions into a state for which a webhook has been configured, the webhook is triggered, with all meta data for the booking as part of the payload.

Webhooks are great for getting creative. Have Zapier catch them and turn them into Slack channel notifications, have Twilio turn them into a text message or send custom emails.

Read more about webhooks here

Understanding "actions"

Actions are are commands you issue to the booking, in order for it to transition between the steps in the workflow, such as confirming, declining or cancelling a booking.

Every time you want to move a booking further down the graph, you issue the next action command, using the [PUT] /bookings/:id/:action endpoint.

For a reference of which actions are available at which states, please refer to our API reference.