Skip to main content

Cal.com workflow guide

How to Test Cal.com Booking Lifecycle Locally

The useful Cal.com flow is not one request. It is the handoff between slots, booking creation, booking lookup, reschedule, cancel, and the events those changes emit.

Apr 20, 2026FetchSandbox Engineering

Scheduling integrations do not usually break on the first request. They break in the gap between /slots, /bookings, and whatever your app assumes after a booking changes.

The onboarded Cal.com spec in FetchSandbox already surfaced a clean core workflow for this: look up slots, create the booking, fetch it again, reschedule it, then cancel it. That is the narrow page worth publishing because it matches the real order developers have to trust, not just one endpoint in isolation.

The booking lifecycle worth testing

  1. Get available slots: GET /v2/slots. Expected status 200. Start from the bookable times Cal.com says are available right now.
  2. Create a booking: POST /v2/bookings. Expected status 201. Turn one of those slots into a real booking with attendee details.
  3. Get booking details: GET /v2/bookings/{bookingUid}. Expected status 200. Verify the booking state and fetch the details your app usually needs next.
  4. Reschedule the booking: POST /v2/bookings/{bookingUid}/reschedule. Expected status 201. Test the state transition that often gets skipped in narrow endpoint mocks.
  5. Cancel the booking: POST /v2/bookings/{bookingUid}/cancel. Expected status 200. Close the loop and confirm cancellation behaves like your app expects.

Why this flow is narrower and better than a broad docs page

The broad docs tell you each endpoint exists. They do not answer the integration question: does the state still make sense after I create the booking, retrieve it, move it, and finally cancel it?

That is the difference between endpoint coverage and workflow confidence. A static mock can make POST /v2/bookings return 201. It will not usually tell you whether the reschedule path still lines up with the booking you just created two calls ago.

Failure modes to force early

  • no available slots for the requested range
  • the slot gets taken between lookup and booking
  • booking not found during reschedule or cancel
  • a cancelled booking gets rescheduled anyway in test logic
  • attendee data passes a form but fails the API contract

These are boring bugs, but they are exactly the ones that turn a clean sandbox demo into a late-night production debugging session. The slot looked available. The booking existed. The next state change is where trust disappeared.

Webhook events around this workflow

  • BOOKING_CREATED
  • BOOKING_RESCHEDULED
  • BOOKING_CANCELLED

Even if your first integration pass is request-driven, the booking flow is not really done until you also know what happens when those follow-up events arrive.

Where to go next

Open the Cal.com docs portal if you want the full reference, or start from the broader Cal.com sandbox page if you want the higher-level overview first.

If you want the workflow-first version, the useful test is simple: run slot lookup, create the booking, fetch it again, reschedule it, and cancel it in one stateful environment so the later calls still know what the earlier ones created.