So sum up from introduction to bookings, in Timekit terms a booking is a request to occupy 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 occupying 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:

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

Confirm_decline graph
For when the booking request should be confirmed, before the time-slot is added to the resource's calendar.

Group_owner graph
For when you have a limited number of "seats" at a given time. Each seat-booking then follows the group_customer graph.

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

Group_customer_payment graph
For when each seat in a group-owner graph, needs to be registered as paid for to remain booked by the customer.

If you are unsure which graph fits your use case. Just hit the chat button in the lower right corner and we'll help you choose. 

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 graph, 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.

Did this answer your question?