Scheduling API-first: tu calendario es una base de datos, no una app
La mayoría de herramientas de scheduling tratan la UI como el producto. El calendario vive dentro de la app y la única forma de llegar a él es iniciar sesión y hacer clic. Si quieres hacer algo que el diseñador no imaginó — traer las reuniones de la próxima semana a tu revisión semanal, auto-crear horas de oficina desde un CSV, dejar que la extensión de Raycast de un compañero reserve algo por ti — estás atascado.
WhenToMeet toma la visión opuesta. El calendario es una base de datos. La UI es una vista de él. Si quieres otra vista, escríbela.
Para eso está la API REST v1.
Qué hay en la API
La superficie v1 en /api/v1/ es pequeña a propósito. Cubre las cosas que la gente realmente automatiza:
- Events — listar, leer y crear polls de scheduling y direct events.
/api/v1/polls - Bookings — leer las citas que llegaron a través de tus booking pages.
/api/v1/bookings - Calendar events — una vista unificada de todos los calendarios que has conectado, más tus propios scheduling events y bookings.
/api/v1/calendar/events - Conflict checks — preguntar si un rango horario propuesto colisiona con algo que ya tienes
- Profile — obtener tu propio perfil, zona horaria, plan y ajustes
La autenticación es un token Bearer. Generas una clave sk_… desde tus ajustes, la envías como Authorization: Bearer sk_… y ya estás dentro. Cada endpoint está acotado, de modo que una clave solo ve lo que tiene permiso para ver.
Existe un OpenAPI spec. Los docs en docs.whentomeet.io listan cada endpoint con la forma de request y response, así puedes apuntar un generador de código y obtener un cliente tipado en el lenguaje que ya usas.
Por qué está gated para Pro
El acceso a la API es una feature Pro. La razón honesta es que una API es una superficie de soporte — las claves se filtran, los scripts hacen bucles, los rate limits se tocan — y preferimos dar soporte cuidadoso a quienes realmente la necesitan en lugar de repartirlo poco profundo entre cuentas gratuitas. Los rate limits son por clave e intencionalmente relajados para automatización normal. Con un digest semanal no los vas a tocar.
Qué cambia con esto
Una vez que el calendario es un endpoint real, el trabajo que antes causaba desaparece en scripts:
- El becario ya no copia las reuniones de la próxima semana a la wiki del equipo. Lo hace un cron job.
- No reenvías notificaciones de booking a tu CRM. Un poll con estilo webhook las escribe.
- El engineering lead ya no es el PM de scheduling. Un script compartido crea el standup semanal con un comando.
Nada de esto es nuevo en espíritu — los desarrolladores llevan quince años pegando SaaS con APIs. Lo nuevo es que las herramientas de scheduling históricamente se negaron a estar en esa pila. Tenías Calendly el producto y nada más. Con una API real, el producto se vuelve un cliente entre muchos.
Si estás construyendo algo
Empieza en docs.whentomeet.io, genera una clave, llama GET /api/v1/polls con ella, y verás tus propios scheduling polls devolverse como JSON. Todo lo demás es composición desde ahí.
Si prefieres entregarle las llaves a un agente en lugar de escribir el script tú — Claude, ChatGPT, Cursor — el servidor MCP en /api/mcp envuelve los mismos endpoints en un protocolo que esos clientes ya hablan. Misma auth, mismos rate limits. Lo cubrimos en el próximo post.