Bookings overview

Bookings is an object we have invented to control the flows and data before events are saved to a calendar.

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

You must choose the flow that suits your use-case the best. We can help you choose, but you must provide us with a description of your use-case and the steps your customers follow, that includes booking.

You set the graph when creating a booking /bookings

You can also configure webhooks through our admin interface. These webhooks will be triggered when a booking transitions into one of the configured states. You can use webhooks if you want to handle sending emails, for instance confirmation emails, yourself instead of relying on the emails that Timekit provides out-of-the-box. Webhooks

Each bookings flow defines a set of action that you can perform on the booking through /bookings/:id/:action Along a set of states that can trigger a webhook.

Timekit currently operate with these booking flows:

Instant graph
For when a booking request should immediately make the booked timeslot unavailable.

Confirm_decline graph
For when the booking request should be confirmed, before the booked timeslot is no longer available.

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 Group_customer graph

Instant_payment graph
For when an instant booking is required to be paid before the booked timeslot is no longer available.

Group_customer_payment graph
For when each seat in a group-owner graph, need to be paid before the seat is no longer available.