So sum up from introduction to bookings, 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.
For when the booking request should be confirmed, before the time-slot is reserving time in the resource's calendar.
For when you have a limited number of "seats" at a given time. Each seat-booking then follows the group_customer graph.
For when you need to register the payment in order to keep the time-slot unavailable for bookings.
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.
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.