Intégration API Calendly
Nous développons votre connecteur Calendly
Nous intégrons l'API Calendly pour capter la réservation, la créer depuis votre produit, et pousser l'invité dans le CRM.
- Équipe produit senior
- prise de RDV en production
- du cadrage au monitoring
À quoi sert l'API Calendly et quand l'intégrer dans une application ?
Calendly est l'outil de prise de rendez-vous le plus utilisé en France pour les équipes commerciales et de conseil. Son API permet à votre application de créer une réservation sans redirection vers le site Calendly, de recevoir une notification immédiate à chaque rendez-vous pris, et de synchroniser les informations du rendez-vous dans votre CRM. On l'intègre quand les commerciaux utilisent déjà Calendly et que les rendez-vous doivent alimenter automatiquement un pipeline, déclencher un email ou créer une activité sans ressaisie.
Ce que nos clients construisent sur l'API Calendly
Agent vocal qui confirme le créneau
POST /invitees pendant l'appel. Pas de lien à cliquer plus tard. C'est le cas d'usage mis en avant par l'éditeur, et il exige un plan payant.
Portail qui réserve dans sa propre charte
Les créneaux s'affichent dans votre interface. La réservation part par API. Calendly reste le moteur, le parcours reste le vôtre.
CRM alimenté à invitee.created
Contact, affaire, réponses aux questions, UTM. Plus de ressaisie après un « vous allez recevoir un Calendly ».
Rattrapage d'annulation et de no-show
invitee.canceled et invitee_no_show.created déclenchent relance, requalification, nouveau créneau. Ce que personne ne fait à la main.
Ce que ça change dans votre prise de rendez-vous
La technique au service d'un résultat mesurable : un RDV dans le dossier, moins de lapins, un coût par rendez-vous tenu.
Le rendez-vous n'est plus un lien nu
Il crée le dossier. Les réponses aux questions personnalisées arrivent structurées, pas dans un e-mail de confirmation.
Vous réservez sans montrer Calendly
Scheduling API : le prospect reste dans votre produit ou dans l'appel. L'iframe n'est plus une fatalité.
L'annulation a une suite
Un créneau lâché relance. Un no-show requalifie. Le planning et le pipeline restent alignés.
L'UTM suit jusqu'au rendez-vous tenu
Le bloc tracking relie la campagne à la présence réelle. Vous mesurez un coût par rendez-vous, pas par formulaire.
Comment nous livrons votre connecteur Calendly
Cadrage
Lecture seule ou Scheduling API, scope user ou organization, PAT ou OAuth, plan payant réel. On tranche avant de promettre POST /invitees.
Développement
Signature t + corps brut, handler court, URI complètes, idempotence sur la réservation, file de refus de créneau. Démonstration chaque semaine.
Recette
403 sur scope organization avec rôle user, créneau déjà pris, signature hors tolérance de 3 minutes, PAT d'un compte qui part. Rejeu avant bascule.
Monitoring
state et retry_started_at des abonnements, alerte si un webhook quitte active. Réconciliation GET /scheduled_events. Un webhook mort ne produit aucune erreur chez vous.
Ce que permet l'API Calendly
- Types d'événement et rendez-vous
- event_types, scheduled_events, invitees, scheduling_links. Tout s'adresse par URI (https://api.calendly.com/event_types/<UUID>), pas par UUID isolé.
- Scheduling API
- POST /invitees crée la réservation : event_type (URI), start_time UTC disponible, invitee (name, email, timezone), plus location, invités, questions, UTM. Plan payant requis.
- Webhooks signés
- invitee.created, invitee.canceled, invitee_no_show.created. Signature Calendly-Webhook-Signature (t=...,v1=...), HMAC-SHA256, tolérance 3 minutes dans l'exemple officiel.
- Organisation, rôles, conformité
- users, organizations, memberships. Un GET webhook en scope organization renvoie 200 pour un admin, 403 pour un user. Endpoints de suppression des données d'invités pour l'effacement.
Le vocabulaire de l'API Calendly
- URI de ressource
- Identifiant canonique, par exemple https://api.calendly.com/event_types/<UUID>. Extraire l'UUID et le réinjecter casse le premier endpoint qui attend l'URI.
- POST /invitees
- Scheduling API. Réserve un créneau sans UI Calendly. Corps minimal : event_type, start_time, invitee. Plan payant requis. Ce n'est pas une réservation forcée.
- Calendly-Webhook-Signature
- t=<unix>,v1=<hmac>. HMAC-SHA256 de t + "." + corps brut. Tolérance 3 minutes. Le parseur JSON d'Express ou Nest doit laisser le brut, sinon la vérif échoue à 100 %.
- scope
- user : événements de cet utilisateur seulement. organization : tout le compte, jeton admin, sinon 403. C'est le bug n°1 des intégrations Calendly.
- invitee.created
- Webhook émis à la réservation. Porte l'invité, les questions, le tracking. C'est lui qui crée l'affaire, pas un polling des scheduled_events.
- retry_started_at
- Champ de l'abonnement qui signale que Calendly retente. Un webhook qui quitte active sans alerte est un pipeline commercial sourd.
Les contraintes réelles de l'API Calendly
Vous ne possédez pas la disponibilité
Tampons, préavis, plafonds journaliers : tout vit chez Calendly. Vous lisez et vous réservez un créneau libre. Une règle métier atypique (binôme, trajet, nuit) se discute plutôt avec Cal.com.
Le plan payant est une condition
La Scheduling API est explicitement réservée aux applications sur plan payant. Un prospect en plan gratuit ne peut pas recevoir POST /invitees. On le dit au cadrage, pas à la recette.
Un webhook user n'est pas le compte
scope user explique « on ne reçoit pas tous les rendez-vous ». Passer en organization sans jeton admin produit 403. Deux causes, un même symptôme, à tester avant la prod.
Le PAT survit mal à un départ
Un jeton personnel est nominatif. OAuth est le seul schéma propre en multi-clients. Idempotence métier sur POST /invitees, et alternative affichée si le créneau vient d'être pris.
API Calendly ou API Cal.com ?
Deux moteurs de prise de rendez-vous. Le bon dépend de qui possède les règles de disponibilité.
| Critère | CalendlyCette page | Cal.comOpen source |
|---|---|---|
| Où vivent les règles | Chez Calendly, vous les lisez | Chez vous si auto-hébergé, API de premier rang |
| Réservation par API | POST /invitees, plan payant | Créer, reporter, annuler, réattribuer |
| Hébergement | SaaS Calendly | Cloud Cal.com ou instance à vous (AGPL à cadrer) |
| Signature webhook | Calendly-Webhook-Signature, 3 min | x-cal-signature-256, secret à imposer |
| Catalogue d'événements | created, canceled, no-show | Booking, meeting, recording, délégation M365 |
| Parc déjà là | Souvent déjà utilisé par les commerciaux | À installer, ou déjà choisi pour la maîtrise |
| Le bon cas | Capter un Calendly déjà en place | Règles atypiques, auto-hébergement, ICS |
Google Calendar et Outlook sont l'agenda de travail, pas le moteur de réservation. Les trois se combinent : Calendly prend le RDV, Calendar ou Graph l'écrit chez le collaborateur.
Ce que nous mesurons sur une intégration Calendly
Les autres API d'agenda
Si Calendly n'est pas le bon moteur, ces options se discutent au cadrage.
CalendlyNous développons votre connecteur CalendlyCette page
Google CalendarAgenda de travail Workspace, pas la prise de rendez-vous.
Microsoft OutlookAgenda et courrier Graph, parc Microsoft 365.
Cal.comAlternative open source quand vous devez posséder les règles.On combine Calendly avec
La stack qui entoure Calendly sur nos projets.
Intégration Calendly : vos questions
OAuth (multi-clients) ou PAT (interne), stockage des URI de types d'événement, abonnement webhook en scope organization si vous voulez tout le compte, vérification HMAC sur le corps brut, worker pour créer l'affaire. Si vous réservez depuis le produit : POST /invitees avec un plan payant, gestion du refus de créneau, clé d'idempotence métier. La partie sensible n'est pas le premier GET, c'est le scope, la signature et la supervision de retry_started_at.
Oui. La Scheduling API (POST /invitees) réserve un créneau sans iframe ni redirection. Corps : URI du event_type, start_time UTC réellement disponible, invitee (name, email, timezone), options location, guests, questions, tracking UTM. Un plan payant est requis. Ce n'est pas une réservation forcée : entre le listage et l'insert, le créneau peut partir. Beaucoup de contenus en ligne affirment encore l'inverse ; le portail développeur Calendly documente l'endpoint.
Un premier flux utile, typiquement invitee.created vers le CRM avec questions et UTM, se livre en deux à trois semaines. Ajouter POST /invitees dans un portail ou un agent vocal, plus la supervision des abonnements et l'effacement RGPD, demande plutôt quatre à six semaines. Le plan payant du compte Calendly doit être confirmé avant le devis, sinon le projet s'arrête à la recette. C'est un arbitrage de cadrage, écrit avant le premier appel, pas une surprise de recette.
Calendly si le moteur est déjà là et que vous voulez capter la réservation (webhooks, éventuellement Scheduling API). Cal.com si vous devez posséder les règles (tournées, binômes, nuit), auto-héberger, ou traiter MEETING_ENDED / ICS / enregistrements. Les deux parlent à Google Calendar ou Outlook ensuite. On conseille parfois Cal.com contre un devis Calendly : c'est le même cadrage, pas deux religions.
POST /webhook_subscriptions avec les événements invitee.created, canceled, no_show. Vérifier Calendly-Webhook-Signature (t.corps, 3 minutes). Répondre 2xx tout de suite, dédupliquer sur l'URI de l'invité, créer contact / affaire / tâche dans le worker. Contrôler state et retry_started_at. Réconcilier avec GET /scheduled_events. Un scope user sur un compte à plusieurs commerciaux explique la plupart des « le CRM n'a pas le rendez-vous ».
Un projet d'intégration Calendly ?
Parlons-en. 30 minutes pour cadrer webhooks, Scheduling API, plan payant, et vous dire franchement si Cal.com n'est pas le meilleur outil.
Parler de mon projet Calendly