Intégration API Cal.com
Nous développons votre connecteur Cal.com
Votre produit pilote l'API Cal.com pour réserver, reporter, annuler et facturer le temps réellement tenu, dans votre charte, sans iframe.
- Équipe produit senior
- Cal.com en production chez nous
- du cadrage au monitoring
À quoi sert Cal.com et pourquoi l'intégrer plutôt qu'un outil de calendrier standard ?
Cal.com est un outil open source de prise de rendez-vous en ligne, auto-hébergeable. Son API permet à votre application de créer, modifier ou annuler une réservation directement dans le parcours utilisateur, sans rediriger vers une page externe. On choisit Cal.com quand la confidentialité des données exige un hébergement sur votre infrastructure, ou quand le parcours de prise de rendez-vous doit rester dans votre produit : dans un agent vocal, un portail client, un espace de soin, sans que l'utilisateur sorte de votre interface pour choisir un créneau.
Ce que nos clients construisent sur l'API Cal.com
Réservation entièrement dans le produit
Pas de redirection vers un domaine tiers. Créer, reporter, annuler depuis votre portail, avec votre charte.
Instance auto-hébergée en France
Secteur public, santé, mutuelle : le moteur de disponibilité tourne dans votre infrastructure. Calendly ne ferme pas ce débat.
Facturation à l'heure réellement tenue
MEETING_STARTED et MEETING_ENDED livrent le début et la fin sans job cron de votre côté. La durée théorique du créneau ne facture plus.
Compte rendu automatique vers le CRM
RECORDING_READY puis RECORDING_TRANSCRIPTION_GENERATED. Le cas d'usage IA le plus simple à câbler sur un flux de rendez-vous existant.
Ce que ça change dans votre prise de rendez-vous
La technique au service d'un résultat mesurable : vos règles, votre hébergement, un temps facturé juste.
Les règles atypiques deviennent traitables
Binômes, trajet, plage de nuit : le moteur est ouvert. Chez Calendly, vous contournez. Ici, vous concevez.
L'hébergement est un argument de contrat
Pouvoir dire « les données de rendez-vous restent chez vous » ferme un appel d'offres que le SaaS américain ne gagne pas.
L'invitation calendrier est correcte
Vos e-mails de confirmation portent une invitation ICS utilisable. Le créneau apparaît chez le client sans bricolage.
Un no-show a une suite
Absence ou réaffectation alimentent relance ou refacturation, selon votre règle, pas selon un tableau.
Comment nous livrons votre connecteur Cal.com
Cadrage
Cloud ou auto-hébergé, v2 uniquement, Platform éligible ou pas (fermée aux nouveaux depuis le 15 décembre 2025), licence. On tranche avant l'architecture.
Développement
Secret webhook obligatoire, routeur des deux formes de payload, 120 req/min, rafraîchissement des jetons managed users à 60 minutes.
Recette
MEETING_ENDED sans body.payload, attendees d'une place assise, rotation M365 à 48 h, 401 en milieu de job. Rejeu avant bascule.
Monitoring
Alerte humaine sur DELEGATION_CREDENTIAL_ROTATION_REQUIRED, escalade si ROTATION_FAILED. Un identifiant Microsoft bloqué coupe tous les agendas membres.
Ce que permet l'API Cal.com
- Réservation de premier rang
- Créer, reprogrammer, annuler, marquer une absence, réattribuer un hôte. Le parcours peut vivre entièrement dans votre produit.
- Webhooks riches, y compris temporisés
- BOOKING_CREATED, RESCHEDULED, CANCELLED, PAID, NO_SHOW_UPDATED, REASSIGNED. MEETING_STARTED et MEETING_ENDED sont planifiés à startTime et endTime.
- ICS prégénérés (2026-07-27)
- attendeeIcsContent et organizerIcsContent sur les événements de réservation concernés. Monter de version évite de générer l'ICS vous-même.
- Délégation Microsoft 365
- Cal.com tourne le secret Entra. Trois webhooks : ROTATED, ROTATION_FAILED (blocage après 48 h), ROTATION_REQUIRED. Google n'est pas concerné (pas de secret expirant).
Le vocabulaire de l'API Cal.com
- x-cal-signature-256
- HMAC-SHA256 du corps, clé configurée sur l'abonnement. Optionnelle à la création : un webhook non signé est possible. Notre convention interne l'interdit.
- MEETING_STARTED / ENDED
- Payload plat, champs de réservation à la racine, sans enveloppe payload. Un handler body.payload.uid plante sur exactement ces deux déclencheurs.
- 2026-07-27
- Version de payload qui ajoute attendeeIcsContent et organizerIcsContent sans casser 2021-10-20. À figer dans la config, pas à « prendre la dernière » en silence.
- Managed users
- En-têtes x-cal-client-id et x-cal-secret-key, puis jeton par utilisateur (60 min / 1 an). Liés à l'offre Platform, fermée aux nouveaux depuis le 15 décembre 2025.
- Places assises
- Le tableau attendees ne contient que le participant de la place concernée, pas toute la salle. Une agrégation naïve sous-compte sans lever d'erreur.
- secretRotationBlocked
- Après 48 h d'échec de rotation du secret Entra, l'identifiant de délégation Microsoft 365 se bloque. DELEGATION_CREDENTIAL_SECRET_ROTATION_FAILED doit sortir des logs.
Les contraintes réelles de l'API Cal.com
Platform est fermée aux nouveaux
Depuis le 15 décembre 2025, plus de nouvelles inscriptions Platform. Support entreprise conservé pour les clients existants. Une architecture managed users / Atoms se vérifie commercialement avant la conception.
Trois axes de version, pas un
API v1 et v2 coexistent, Platform est dépréciée, les payloads webhook ont leur propre versionnage. Un projet qui ne fige pas les trois rend la maintenance illisible.
120 requêtes par minute
Par clé API, extensible « raisonnablement » (exemple 200, jusqu'à 800 avec frais). Une reprise d'historique se découpe. Sans ça, la migration depuis un autre outil s'étouffe au premier jour.
Auto-hébergement et licence à écrire
Cœur AGPL-3.0. Le régime des répertoires entreprise se recadre avec un juriste, pas dans une fiche technique. Sauvegarde, secrets hors dépôt, suivi des mises à jour amont : c'est le devis, pas l'après-coup.
API Cal.com ou API Calendly ?
Deux moteurs de prise de rendez-vous. Le bon dépend de qui possède les règles, et de l'hébergement.
| Critère | Cal.comCette page | CalendlySaaS hébergé |
|---|---|---|
| Où vivent les règles | Ouvertes, auto-hébergement possible | Chez Calendly, vous lisez |
| Réservation par API | Premier rang : créer, reporter, annuler | POST /invitees, plan payant |
| Webhooks | Booking, meeting, recording, M365 | created, canceled, no-show |
| ICS | Prégénéré en payload 2026-07-27 | Côté Calendly, pas dans votre mailer |
| Débit | 120 req/min par clé, négociable | 429 + X-RateLimit-*, non chiffré ici |
| Risque commercial | Platform fermée aux nouveaux (15/12/2025) | Plan payant obligatoire pour Scheduling API |
| Le bon cas | Maîtrise, France, règles atypiques | Capter un Calendly déjà en place |
Nous utilisons Cal.com en production sur fragments-studio.com. Google Calendar et Outlook restent l'agenda de travail du collaborateur.
Ce que nous mesurons sur une intégration Cal.com
Les autres API d'agenda
Si Cal.com n'est pas le bon moteur, ces options se discutent au cadrage.
Cal.comNous développons votre connecteur Cal.comCette page
Google CalendarAgenda de travail Workspace, pas le moteur de réservation.
Microsoft OutlookAgenda et courrier Graph, parc Microsoft 365.
CalendlySaaS déjà en place chez les commerciaux, règles chez l'éditeur.On combine Cal.com avec
La stack qui entoure Cal.com sur nos projets.
Intégration Cal.com : vos questions
Figer v2, OAuth ou clé cal_live_, secret webhook obligatoire, handler qui distingue l'enveloppe payload et la forme plate de MEETING_STARTED / ENDED, limiteur à 120 req/min. Le parcours de réservation s'appelle en API de premier rang (créer, reporter, annuler). En auto-hébergement, le devis inclut sauvegarde, secrets et licence. La partie sensible n'est pas le premier booking, c'est le versionnage et la rotation Microsoft 365.
Calendly capte un moteur déjà là ; vous ne possédez pas la disponibilité. Cal.com expose la réservation comme opération native et peut tourner dans votre infra. Les webhooks Cal.com vont jusqu'à la fin réelle de réunion, l'ICS et l'enregistrement. Calendly est plus simple si le commercial a déjà son lien. Cal.com gagne dès que les règles, l'hébergement ou la facturation au réel comptent. Nous le faisons tourner sur notre propre site.
Un premier flux utile, typiquement BOOKING_CREATED vers le CRM, se livre en deux à trois semaines. Un parcours complet dans le produit, avec MEETING_ENDED, ICS 2026-07-27 et supervision de délégation Microsoft 365, demande plutôt six à huit semaines. L'auto-hébergement allonge le devis (exploitation, mises à jour, licence). L'éligibilité Platform se vérifie avant, pas pendant. C'est un arbitrage de cadrage, écrit avant le premier appel, pas une surprise de recette.
Oui, c'est un argument juridique autant que technique. Le cœur est sous AGPL-3.0 ; le régime des fonctionnalités entreprise se recadre avec un juriste avant l'architecture. Nous posons sauvegarde/restauration, secrets hors dépôt et suivi du projet amont dans le devis. Ce n'est pas « docker compose et on verra ». Pour un appel d'offres public ou santé, cette conversation a lieu au premier échange. C'est un arbitrage de cadrage, écrit avant le premier appel, pas une surprise de recette.
Non pour les nouveaux. Depuis le 15 décembre 2025, Cal.com restructure Platform : plus de nouvelles inscriptions, support entreprise conservé pour les clients déjà là. Si votre architecture cible des managed users (jeton 60 minutes, en-têtes x-cal-client-id), il faut vérifier l'éligibilité commerciale avant la conception. Une démo Atoms d'avant cette date ne prouve plus un go-live. C'est un arbitrage de cadrage, écrit avant le premier appel, pas une surprise de recette.
Un projet d'intégration Cal.com ?
Parlons-en. 30 minutes pour cadrer cloud ou auto-hébergé, Platform, et vous dire franchement si Calendly suffit déjà.
Parler de mon projet Cal.com