Check Calendly bookings against your logs when a booking flow breaks

Last verified on Nov 8, 2026.

A booking flow touches three systems: your page or API, Calendly, and whoever is meant to receive the meeting. When someone says they booked a demo and nothing arrived, your logs show your side and Calendly shows its own record of events and invitees. The Sazabi agent can read both in one thread and tell you which side dropped it.

What the Sazabi agent can do with Calendly

Sazabi connects to Calendly's hosted MCP server at mcp.calendly.com over OAuth. Calendly does not accept personal access tokens for this server, so you approve access in Calendly's consent screen. The connection acts as the user who approved it. Calendly's tools are named by category and map one-to-one to its REST endpoints. The ones that matter in an investigation:

• meetings-list_events lists scheduled events, and Calendly's endpoint accepts invitee_email, status (active or canceled), and min_start_time and max_start_time filters. meetings-get_event returns one.
• meetings-list_event_invitees and meetings-get_event_invitee show who is on an event, and meetings-get_invitee_no_show reads no-show status.
• event_types-list_event_types, event_types-list_event_type_available_times and availability-list_user_busy_times explain why a slot is or is not offered.
• routing_forms-list_routing_form_submissions reads form submissions, which Calendly marks as requiring a Teams plan or higher.
• notetaker-get_recap_transcript reads meeting recaps if your plan includes Notetaker.

The server also has write tools, including meetings-create_invitee, meetings-cancel_event and event_types-update_event_type, behind a separate mcp:scheduling:write scope. Sazabi's page describes the agent creating scheduling links and managing meetings, so decide before the investigation whether it should only read.

Questions it answers

• Does Calendly have an active event for this invitee email around the time the user says they booked?
• Was the event canceled, and when?
• Does the event type offer available times in the window the user tried?
• Is the host's calendar busy when the booking page claimed it was free?
• Did a routing form submission arrive for this lead?

A worked example: a demo booking that returned a 500

Your logs show POST /api/book-demo failing with a 500 at 15

Our /api/book-demo handler returned 500 at 15:02 UTC for lead@example.com. Check
Calendly for an event with that invitee email starting after 15:00 UTC. If there
is one, give me its status and invitees. If not, list the available times for
the demo event type in that hour and the host's busy times.

The agent finds the failing request in your logs and shows the query. It then calls meetings-list_events filtered by invitee_email and min_start_time. If it finds an event, meetings-list_event_invitees gives the invitee records, and the useful finding is that Calendly booked it and your handler failed after the call, so the 500 is a response-handling bug and the lead exists. If there is none, it calls event_types-list_event_type_available_times for the hour and availability-list_user_busy_times for the host. A slot that is no longer offered, or a host who became busy, is a likely reason meetings-create_invitee would refuse the booking.

Both outcomes narrow the hunt without guessing. For the first, look at what your code does with Calendly's response. For the second, look at how stale your cached slot list is.

How it fits with other integrations

Booking problems usually surface as a lead complaint and a log line, so Slack is where the question lands and Linear is where the fix is tracked. If a lead's CRM record matters, Attio holds it, and Granola covers the meeting afterward. The full list is under integrations, and plans are on pricing.