API integration for Calendly
We build your Calendly connector
We integrate the Calendly API to capture the booking, create it from your product, and push the invitee into the CRM.
- Senior product team
- booking flows in production
- from scoping to monitoring
What does the Calendly API do and when should you integrate it into an application?
Calendly is the most widely used appointment scheduling tool in France for sales and consulting teams. Its API lets your application create a booking without redirecting to the Calendly site, receive an immediate notification each time a meeting is booked, and sync the meeting details into your CRM. You integrate it when the sales team is already using Calendly and meetings need to automatically feed a pipeline, trigger an email, or create an activity without any manual re-entry.
What our clients build on the Calendly API
Voice agent that confirms the slot
POST /invitees during the call. No link to click later. That is the use case the vendor highlights, and it requires a paid plan.
Portal that books in its own UI
Slots render in your interface. The booking goes out through the API. Calendly stays the engine, the journey stays yours.
CRM fed on invitee.created
Contact, deal, custom-question answers, UTM. No re-keying after a "you will get a Calendly".
Catch-up on cancel and no-show
invitee.canceled and invitee_no_show.created trigger a follow-up, a requalification, a new slot. What nobody does by hand.
What this changes in your booking
The engineering serves a measurable result: a meeting in the file, fewer no-shows, a cost per held appointment.
The meeting is no longer a naked link
It opens the file. Answers to custom questions arrive structured, not in a confirmation email.
You book without showing Calendly
Scheduling API: the prospect stays in your product or on the call. The iframe is no longer a given.
A cancellation has a sequel
A dropped slot follows up. A no-show requalifies. Planning and pipeline stay aligned.
UTM follows through to the held meeting
The tracking block ties the campaign to actual attendance. You measure cost per held meeting, not per form.
How we deliver your Calendly connector
Scoping
Read-only or Scheduling API, user or organization scope, PAT or OAuth, a real paid plan. We settle this before promising POST /invitees.
Development
Signature over t + raw body, short handler, full URIs, booking idempotency, a queue for slot refusals. A demo every week.
Acceptance
403 on organization scope with a user role, slot already taken, signature outside the 3-minute window, PAT of someone who left. Replay before cutover.
Monitoring
state and retry_started_at on subscriptions, alert if a webhook leaves active. Reconciliation via GET /scheduled_events. A dead webhook produces no error on your side.
What the Calendly API allows
- Event types and meetings
- event_types, scheduled_events, invitees, scheduling_links. Everything is addressed by URI (https://api.calendly.com/event_types/<UUID>), not by a stripped UUID.
- Scheduling API
- POST /invitees creates the booking: event_type (URI), available UTC start_time, invitee (name, email, timezone), plus location, guests, questions, UTM. Paid plan required.
- Signed webhooks
- invitee.created, invitee.canceled, invitee_no_show.created. Calendly-Webhook-Signature (t=...,v1=...), HMAC-SHA256, 3-minute tolerance in the official example.
- Organization, roles, compliance
- users, organizations, memberships. A webhook GET at organization scope returns 200 for an admin, 403 for a user. Invitee deletion endpoints for erasure.
Calendly API vocabulary
- Resource URI
- Canonical identifier, for example https://api.calendly.com/event_types/<UUID>. Extracting the UUID and injecting it back breaks the first endpoint that expects the URI.
- POST /invitees
- Scheduling API. Books a slot with no Calendly UI. Minimal body: event_type, start_time, invitee. Paid plan required. This is not a forced booking.
- Calendly-Webhook-Signature
- t=<unix>,v1=<hmac>. HMAC-SHA256 of t + "." + raw body. 3-minute tolerance. The Express or Nest JSON parser must leave the raw body, or verification fails 100% of the time.
- scope
- user: events for that user only. organization: the whole account, admin token, otherwise 403. This is bug number one of Calendly integrations.
- invitee.created
- Webhook fired on booking. Carries the invitee, questions, tracking. This is what creates the deal, not polling scheduled_events.
- retry_started_at
- Subscription field that signals Calendly is retrying. A webhook that leaves active with no alert is a deaf sales pipeline.
The real constraints of the Calendly API
You do not own availability
Buffers, notice, daily caps: all live at Calendly. You read and you book a free slot. An atypical business rule (pair, travel, night) is a Cal.com conversation.
The paid plan is a condition
The Scheduling API is explicitly reserved to apps on a paid plan. A prospect on the free plan cannot receive POST /invitees. We say it at scoping, not at acceptance.
A user webhook is not the account
user scope explains "we are not getting every meeting". Switching to organization without an admin token produces 403. Two causes, one symptom, tested before production.
A PAT survives a departure poorly
A personal token is named. OAuth is the only clean scheme for multi-tenant. Business idempotency on POST /invitees, and an alternative shown if the slot was just taken.
Calendly API or Cal.com API?
Two booking engines. The right one depends on who owns the availability rules.
| Criterion | CalendlyThis page | Cal.comOpen source |
|---|---|---|
| Where the rules live | At Calendly, you read them | With you if self-hosted, first-class API |
| Booking via API | POST /invitees, paid plan | Create, reschedule, cancel, reassign |
| Hosting | Calendly SaaS | Cal.com cloud or your instance (AGPL to scope) |
| Webhook signature | Calendly-Webhook-Signature, 3 min | x-cal-signature-256, secret to enforce |
| Event catalogue | created, canceled, no-show | Booking, meeting, recording, M365 delegation |
| Estate already there | Often already used by sales | To install, or already chosen for control |
| The right case | Capture a Calendly already in place | Atypical rules, self-hosting, ICS |
Google Calendar and Outlook are the work calendar, not the booking engine. The three combine: Calendly takes the meeting, Calendar or Graph writes it for the collaborator.
What we measure on a Calendly integration
The other calendar APIs
If Calendly is not the right engine, these options belong in the scoping conversation.
CalendlyWe build your Calendly connectorThis page
Google CalendarWorkspace work calendar, not booking.
Microsoft OutlookGraph calendar and mail, Microsoft 365 estate.
Cal.comOpen-source alternative when you must own the rules.We combine Calendly with
The stack around Calendly on our projects.
Calendly integration: your questions
OAuth (multi-tenant) or PAT (internal), store event-type URIs, webhook subscription at organization scope if you want the whole account, HMAC on the raw body, a worker to create the deal. If you book from the product: POST /invitees with a paid plan, handle slot refusal, a business idempotency key. The hard part is not the first GET, it is scope, signature and watching retry_started_at. This is a scoping call, written down before the first request, not an acceptance surprise.
Yes. The Scheduling API (POST /invitees) books a slot with no iframe and no redirect. Body: event_type URI, actually available UTC start_time, invitee (name, email, timezone), optional location, guests, questions, UTM tracking. A paid plan is required. This is not a forced booking: between list and insert, the slot can go. Plenty of online content still claims the opposite; the Calendly developer portal documents the endpoint.
A first useful flow, typically invitee.created into the CRM with questions and UTM, ships in two to three weeks. Adding POST /invitees in a portal or voice agent, plus subscription monitoring and GDPR erasure, is closer to four to six weeks. The Calendly account's paid plan must be confirmed before the quote, or the project dies at acceptance. This is a scoping call, written down before the first request, not an acceptance surprise.
Calendly if the engine is already there and you want to capture the booking (webhooks, optionally Scheduling API). Cal.com if you must own the rules (rotas, pairs, night), self-host, or handle MEETING_ENDED / ICS / recordings. Both then talk to Google Calendar or Outlook. We sometimes recommend Cal.com against a Calendly quote: same scoping, not two religions. This is a scoping call, written down before the first request, not an acceptance surprise.
POST /webhook_subscriptions with invitee.created, canceled, no_show. Verify Calendly-Webhook-Signature (t.body, 3 minutes). Return 2xx immediately, dedupe on the invitee URI, create contact / deal / task in the worker. Watch state and retry_started_at. Reconcile with GET /scheduled_events. A user scope on an account with several salespeople explains most "the CRM does not have the meeting" reports.
A Calendly integration project?
Let's talk. 30 minutes to scope webhooks, Scheduling API, the paid plan, and tell you plainly if Cal.com is not the better tool.
Discuss my Calendly project