API integration for Cal.com
We build your Cal.com connector
Your product drives the Cal.com API to book, reschedule, cancel and bill time actually held, in your UI, with no iframe.
- Senior product team
- Cal.com in production on our site
- from scoping to monitoring
What does Cal.com do and why integrate it instead of a standard calendar tool?
Cal.com is an open-source online appointment booking tool that can be self-hosted. Its API lets your application create, modify or cancel a booking directly within the user journey, without redirecting to an external page. You choose Cal.com when data privacy requires hosting on your own infrastructure, or when the appointment booking flow must stay inside your product: in a voice agent, a client portal, a care platform, without the user leaving your interface to choose a time slot.
What our clients build on the Cal.com API
Booking entirely inside the product
No redirect to a third-party domain. Create, reschedule, cancel from your portal, with your UI.
Self-hosted instance in France
Public sector, healthcare, mutual: the availability engine runs in your infrastructure. Calendly cannot close that debate.
Billing on time actually held
MEETING_STARTED and MEETING_ENDED deliver start and end with no cron job on your side. The theoretical slot length no longer bills.
Automatic notes into the CRM
RECORDING_READY then RECORDING_TRANSCRIPTION_GENERATED. The simplest AI use case to wire onto an existing meeting flow.
What this changes in your booking
The engineering serves a measurable result: your rules, your hosting, time billed fairly.
Atypical rules become tractable
Pairs, travel, night window: the engine is open. At Calendly, you work around. Here, you design.
Hosting is a contract argument
Being able to say "meeting data stays with you" closes a tender the US SaaS does not win.
The calendar invite is correct
Your confirmation emails carry a usable ICS invite. The slot shows up for the customer without a workaround.
A no-show has a follow-up
Absence or reassignment feeds follow-up or rebilling, per your rule, not a spreadsheet.
How we deliver your Cal.com connector
Scoping
Cloud or self-hosted, v2 only, Platform eligible or not (closed to new sign-ups since 15 December 2025), licence. Settled before architecture.
Development
Webhook secret mandatory, router for both payload shapes, 120 req/min, managed-user token refresh at 60 minutes.
Acceptance
MEETING_ENDED without body.payload, seated-event attendees, M365 rotation at 48 h, 401 mid-job. Replay before cutover.
Monitoring
Human alert on DELEGATION_CREDENTIAL_ROTATION_REQUIRED, escalate on ROTATION_FAILED. A blocked Microsoft credential cuts every member calendar.
What the Cal.com API allows
- First-class booking
- Create, reschedule, cancel, mark a no-show, reassign a host. The journey can live entirely in your product.
- Rich webhooks, including timed ones
- BOOKING_CREATED, RESCHEDULED, CANCELLED, PAID, NO_SHOW_UPDATED, REASSIGNED. MEETING_STARTED and MEETING_ENDED are scheduled at startTime and endTime.
- Pre-built ICS (2026-07-27)
- attendeeIcsContent and organizerIcsContent on the relevant booking events. Bumping the version avoids generating ICS yourself.
- Microsoft 365 delegation
- Cal.com rotates the Entra secret. Three webhooks: ROTATED, ROTATION_FAILED (block after 48 h), ROTATION_REQUIRED. Google is not affected (no expiring secret).
Cal.com API vocabulary
- x-cal-signature-256
- HMAC-SHA256 of the body, secret configured on the subscription. Optional at creation: an unsigned webhook is possible. Our internal convention forbids it.
- MEETING_STARTED / ENDED
- Flat payload, booking fields at the root, no payload envelope. A handler on body.payload.uid fails on exactly these two triggers.
- 2026-07-27
- Payload version that adds attendeeIcsContent and organizerIcsContent without breaking 2021-10-20. Freeze it in config, do not "take the latest" silently.
- Managed users
- Headers x-cal-client-id and x-cal-secret-key, then a per-user token (60 min / 1 year). Tied to Platform, closed to new customers since 15 December 2025.
- Seated events
- The attendees array holds only the participant for that seat, not the whole room. A naive aggregation under-counts without raising an error.
- secretRotationBlocked
- After 48 h of Entra secret rotation failure, the Microsoft 365 delegation credential blocks. DELEGATION_CREDENTIAL_SECRET_ROTATION_FAILED must leave the logs.
The real constraints of the Cal.com API
Platform is closed to new customers
Since 15 December 2025, no new Platform sign-ups. Enterprise support kept for existing customers. A managed-users / Atoms architecture is checked commercially before design.
Three version axes, not one
API v1 and v2 coexist, Platform is deprecated, webhook payloads have their own versioning. A project that does not freeze all three makes maintenance archaeology.
120 requests per minute
Per API key, extensible "reasonably" (example 200, up to 800 with fees). A history replay is chunked. Without that, a migration from another tool chokes on day one.
Self-hosting and licence in writing
Core AGPL-3.0. The enterprise-directory regime is recut with a lawyer, not in a tech note. Backup, secrets off-repo, upstream updates: that is the quote, not the aftermath.
Cal.com API or Calendly API?
Two booking engines. The right one depends on who owns the rules, and on hosting.
| Criterion | Cal.comThis page | CalendlyHosted SaaS |
|---|---|---|
| Where the rules live | Open, self-hosting possible | At Calendly, you read |
| Booking via API | First-class: create, reschedule, cancel | POST /invitees, paid plan |
| Webhooks | Booking, meeting, recording, M365 | created, canceled, no-show |
| ICS | Pre-built in payload 2026-07-27 | On Calendly's side, not in your mailer |
| Rate limit | 120 req/min per key, negotiable | 429 + X-RateLimit-*, not numbered here |
| Commercial risk | Platform closed to new (15/12/2025) | Paid plan required for Scheduling API |
| The right case | Control, France, atypical rules | Capture a Calendly already in place |
We run Cal.com in production on fragments-studio.com. Google Calendar and Outlook remain the collaborator's work calendar.
What we measure on a Cal.com integration
The other calendar APIs
If Cal.com is not the right engine, these options belong in the scoping conversation.
Cal.comWe build your Cal.com connectorThis page
Google CalendarWorkspace work calendar, not the booking engine.
Microsoft OutlookGraph calendar and mail, Microsoft 365 estate.
CalendlySaaS already in place with sales, rules at the vendor.We combine Cal.com with
The stack around Cal.com on our projects.
Cal.com integration: your questions
Freeze v2, OAuth or a cal_live_ key, mandatory webhook secret, a handler that distinguishes the payload envelope from the flat MEETING_STARTED / ENDED shape, a 120 req/min limiter. The booking journey is called as a first-class API (create, reschedule, cancel). On self-hosting, the quote includes backup, secrets and licence. The hard part is not the first booking, it is versioning and Microsoft 365 rotation.
Calendly captures an engine already there; you do not own availability. Cal.com exposes booking as a native operation and can run in your infra. Cal.com webhooks go through to the real end of the meeting, ICS and recording. Calendly is simpler if sales already has a link. Cal.com wins as soon as rules, hosting or billing on actuals matter. We run it on our own site. This is a scoping call, written down before the first request, not an acceptance surprise.
A first useful flow, typically BOOKING_CREATED into the CRM, ships in two to three weeks. A full in-product journey, with MEETING_ENDED, ICS 2026-07-27 and Microsoft 365 delegation monitoring, is closer to six to eight weeks. Self-hosting lengthens the quote (ops, updates, licence). Platform eligibility is checked before, not during. This is a scoping call, written down before the first request, not an acceptance surprise.
Yes, it is a legal argument as much as a technical one. The core is AGPL-3.0; the enterprise-feature regime is recut with a lawyer before architecture. We put backup/restore, secrets off-repo and upstream tracking in the quote. This is not "docker compose and we will see". For a public or healthcare tender, that conversation happens at the first exchange. This is a scoping call, written down before the first request, not an acceptance surprise.
Not for new customers. Since 15 December 2025, Cal.com has been restructuring Platform: no new sign-ups, enterprise support kept for customers already there. If your architecture targets managed users (60-minute token, x-cal-client-id headers), commercial eligibility is checked before design. An Atoms demo from before that date no longer proves a go-live. This is a scoping call, written down before the first request, not an acceptance surprise.
A Cal.com integration project?
Let's talk. 30 minutes to scope cloud or self-hosted, Platform, and tell you plainly if Calendly already covers it.
Discuss my Cal.com project