Scheduling API-first : ton calendrier est une base de données, pas une app

La plupart des outils de scheduling traitent l'UI comme le produit. Le calendrier vit à l'intérieur de l'app, et la seule manière d'y accéder est de se connecter et de cliquer. Si tu veux faire quelque chose que le designer n'avait pas imaginé — tirer les réunions de la semaine prochaine dans ta revue hebdo, auto-créer des heures de bureau depuis un CSV, laisser l'extension Raycast d'un collègue réserver quelque chose pour toi — tu es bloqué.

WhenToMeet prend la vue opposée. Le calendrier est une base de données. L'UI est une vue de cette base. Si tu veux une autre vue, écris-la.

C'est à ça que sert l'API REST v1.

Ce qu'il y a dans l'API

La surface v1 sur /api/v1/ est volontairement petite. Elle couvre les choses que les gens automatisent vraiment :

• Events — lister, lire et créer des scheduling polls et des direct events. /api/v1/polls
• Bookings — lire les rendez-vous entrés via tes booking pages. /api/v1/bookings
• Calendar events — une vue unifiée de tous les calendriers que tu as connectés, plus tes propres scheduling events et bookings. /api/v1/calendar/events
• Conflict checks — demander si un créneau proposé entre en conflit avec quelque chose que tu as déjà
• Profile — récupérer ton propre profil, fuseau horaire, tier et réglages

L'authentification est un Bearer token. Tu génères une clé sk_… dans tes réglages de compte, tu l'envoies en Authorization: Bearer sk_…, et tu es dedans. Chaque endpoint est scopé pour qu'une clé ne voie que ce qu'elle a le droit de voir.

Il y a un spec OpenAPI. Les docs sur docs.whentomeet.io listent chaque endpoint avec les formes de requête et de réponse, donc tu peux y pointer un générateur de code et récupérer un client typé dans le langage que tu utilises déjà.

Pourquoi gated pour Pro

L'accès API est une fonctionnalité Pro. La raison honnête, c'est qu'une API est une surface de support — les clés fuient, les scripts bouclent, les rate limits se touchent — et on préfère supporter ça soigneusement pour ceux qui en ont vraiment besoin plutôt que de l'étaler finement sur tous les comptes gratuits. Les rate limits sont par clé et volontairement souples pour de l'automatisation normale. Tu ne les toucheras pas avec un digest hebdomadaire.

Ce que ça change

Une fois que le calendrier est un vrai endpoint, le travail qu'il générait disparaît dans des scripts :

• Le stagiaire ne copie plus les réunions de la semaine prochaine dans le wiki de l'équipe. Un cron job le fait.
• Tu ne transfères plus les notifications de booking vers ton CRM. Un poll en style webhook les écrit.
• Le lead engineering n'est plus le PM du scheduling. Un script partagé crée le standup hebdo en une commande.

Rien de tout ça n'est nouveau dans l'esprit — les développeurs collent du SaaS avec des APIs depuis quinze ans. Ce qui est nouveau, c'est que les outils de scheduling refusaient historiquement d'être dans cette pile. Il y avait Calendly le produit et rien d'autre. Avec une vraie API, le produit devient un client parmi d'autres.

Si tu construis quelque chose

Commence sur docs.whentomeet.io, génère une clé, appelle GET /api/v1/polls avec, et tu verras tes propres scheduling polls revenir en JSON. Tout le reste est composition à partir de là.

Si tu préfères confier les clés à un agent plutôt que d'écrire le script toi-même — Claude, ChatGPT, Cursor — le serveur MCP sur /api/mcp emballe les mêmes endpoints dans un protocole que ces clients parlent déjà. Même auth, mêmes rate limits. On en parle dans le prochain billet.