Cinco cosas que aprendes conectando un bot a las reservas
La documentación de un motor de reservas describe el camino feliz en dos páginas y parece que la integración es cosa de una tarde. En AltioraIA las tenemos en producción, y estas son las cinco cosas que solo aparecen cuando ya hay clientes reales escribiéndole al bot.
Respuesta directa. Conectar un bot a un motor de reservas de hostelería falla en sitios que la documentación no menciona: crear una reserva son dos llamadas y no una, el borrado por API puede fallar siempre, la fecha no viene en el recurso que la nombra, y el identificador del local acaba incrustado en el código.
1. Crear una reserva son dos llamadas, no una
Lo primero que rompe el esquema mental. En los motores de reservas de hostelería —CoverManager o Eveve, por poner dos que un restaurante español usa a diario— reservar no es un POST y ya está. Si lo que buscas es antes el mapa de qué se conecta con qué, empieza por ahí y vuelve luego.
Son dos pasos: primero se crea una retención de la mesa, y después se confirma. Entre uno y otro la mesa está bloqueada pero la reserva no existe todavía observado en producción, 2026.
Para una web con formulario esto da igual: los dos pasos ocurren con medio segundo de diferencia. Para un bot conversacional lo cambia todo. Tu usuario está escribiendo por WhatsApp, y entre que retienes la mesa y le preguntas «¿te confirmo?» pueden pasar tres minutos, o puede no contestar nunca.
Así que el bot necesita algo que la documentación no te va a dar: una política de retenciones huérfanas. Nosotros la fijamos antes de escribir una línea de código —cuánto aguanta una retención sin confirmar y qué la libera— porque añadirla después obliga a rehacer la conversación entera. Qué pasa con la mesa bloqueada cuando la conversación se muere. Si no la tienes, vas bloqueando mesas que nadie ocupa, y un viernes por la noche eso es dinero del restaurante. Es el mismo problema que hay detrás de reducir los no-shows: una mesa reservada que no se ocupa cuesta igual.
2. El borrado por API puede fallar siempre
Este es el que más horas cuesta, porque el error no parece un error de diseño.
Nos encontramos con un motor de reservas cuyo endpoint de borrado devolvía error de servidor de forma sistemática, en todas las llamadas y con todos los parámetros observado en producción, 2026. No intermitente, no según el estado de la reserva: siempre.
La reacción natural es asumir que lo estás llamando mal, y ahí se van las horas. No lo estás llamando mal: esa vía no funciona. La cancelación va por otro sitio, normalmente un enlace de cancelación que la propia plataforma te devuelve en la respuesta cuando creas la reserva.
Y de ahí sale la consecuencia cara: ese enlace te lo dan una sola vez, en la creación. Si tu integración no lo guardó, no puedes cancelar esa reserva por medios automáticos. Punto. Toca entrar al panel a mano.
Nosotros persistimos el enlace de cancelación en el primer paso, junto al resto de la respuesta de creación, precisamente porque te lo dan una sola vez y sin él no puedes cancelar. Es una línea de código y un campo en base de datos; descubrir que falta son seis meses de reservas que hay que cancelar a mano.
3. El dato que no viene donde lo buscas
Uno esperaría que consultar una reserva devuelva, entre otras cosas, el día de la reserva. No siempre.
Nos encontramos con que el recurso que devuelve las reservas de un cliente no incluía la fecha; estaba solo en el historial del comensal, que es otro recurso distinto observado en producción, 2026.
El efecto práctico es que una operación que suena trivial —comprobar si el cliente ha cambiado su reserva de día— exige cruzar dos llamadas a dos recursos distintos y casar los registros entre ellas. Eso multiplica la latencia del bot y mete un punto de fallo donde no lo habías presupuestado.
Antes de dar un plazo, haz una cosa: coge los cinco mensajes que tu bot va a recibir más veces y comprueba, uno a uno, si los datos que necesitas para responderlos están en una sola llamada. Normalmente no lo están.
4. El identificador que parece configuración y es producción
Este es el más silencioso y el que más miedo da.
En una auditoría de una integración de reservas encontramos el identificador del local incrustado en el código de las llamadas, y en dos generaciones distintas del mismo flujo: una versión antigua con un identificador y una corregida con el bueno observado en producción, 2026. Lo grave no es el error, es cómo se comporta: las llamadas contra el local equivocado no fallan. Devuelven 200. La API existe, el identificador existe, la respuesta es válida. Simplemente es de otro restaurante.
Un panel de monitorización que mire códigos de error te dice que todo va bien. Y va bien: está consultando perfectamente el sitio que no es.
Y hay un segundo nivel, que es el que lo convierte en artículo: alguien ya había detectado el problema y había construido la versión corregida. Pero esa versión vivía en una rama del sistema que ningún disparador llamaba. El diagnóstico estaba hecho, la corrección estaba escrita, y aun así producción seguía ejecutando la versión vieja.
Si sacas una sola cosa de este artículo: un identificador de local no es configuración, es la clave de multi-tenencia del sistema. Va en una variable de entorno, nunca escrito dentro de una llamada, y se comprueba en el arranque.
5. Las ramas que nadie ejecuta
Los flujos de automatización acumulan nodos huérfanos a una velocidad que sorprende a cualquiera que venga de programar en un repositorio con control de versiones.
En la misma auditoría, la mayoría de las llamadas que apuntaban al identificador equivocado estaban en ramas sin ninguna conexión de entrada: copias de nodos hechas al depurar, ramas de pruebas, versiones anteriores que nadie borró observado en producción, 2026. No las ejecutaba nada.
Esto tiene una consecuencia metodológica que cuesta cara si no la sabes: buscar por texto no sirve para auditar un flujo. Si buscas una cadena y te salen veinte resultados, no tienes veinte problemas: tienes veinte apariciones, de las cuales puede que tres se ejecuten. La pregunta correcta no es «¿dónde aparece esto?», sino «¿se llega hasta aquí desde algún disparador?».
Auditar bien es rastrear alcanzabilidad nodo a nodo hacia atrás, hasta un webhook o un disparador vivo. Es lento y no hay atajo, y es exactamente el trabajo que distingue una integración que aguanta de una que parece que funciona.
Qué preguntar antes de presupuestar una integración
Si estás pidiendo presupuesto para conectar tu motor de reservas con un bot, estas cinco preguntas te dicen en dos minutos si quien tienes delante ha hecho esto antes:
¿Crear una reserva es una llamada o son dos? Si te dicen que una, no han llegado a producción.
¿Qué pasa con una mesa retenida si el cliente deja de contestar? La respuesta tiene que ser una política concreta con un tiempo, no «eso lo gestiona la plataforma».
¿Cómo se cancela, y qué guardáis en el momento de crear? Si no mencionan guardar nada de la respuesta de creación, van a tener el problema del punto 2.
¿Dónde vive el identificador del local? Si la respuesta no es «en una variable de entorno», tienes el punto 4 esperándote. Y comprueba de paso que tu plataforma expone lo que hace falta: tanto CoverManager como Ágora publican su catálogo de integraciones por categorías.
¿Cómo comprobáis que una rama del flujo se ejecuta de verdad? Aquí se separa quien ha auditado un sistema en producción de quien solo ha construido uno.
Y si todavía estás antes de esa fase, decidiendo por dónde entrar, el orden lo da el mapa de las tres capas de un restaurante: reservas, sala y TPV no se automatizan igual ni a la vez.
Ninguna de las cinco va sobre tecnología. Van sobre si alguien ha estado delante de un restaurante un viernes por la noche con el bot parado. Que es, al final, lo único que se paga.
Nosotros las contestamos así: son dos llamadas; la retención tiene política y tiempo desde el primer día; guardamos toda la respuesta de creación, enlace de cancelación incluido; el identificador del local va en variable de entorno y se comprueba al arrancar; y la alcanzabilidad se audita rastreando hacia atrás desde cada disparador, nodo a nodo.
Si quieres que miremos tu integración —la que tienes o la que te han presupuestado—, escríbenos desde nuestra página de servicios. Si está bien montada, te lo diremos igual.
Quién firma esto
AltioraIA. Montamos y operamos automatizaciones para restaurantes y pymes: reservas integradas con las plataformas que ya usan, atención por WhatsApp y agentes de voz. Lo que se cuenta aquí sale de sistemas funcionando con clientes delante, no de documentación.
Fuentes
Consultadas el 22 de septiembre de 2026.
- CoverManager — Integraciones. Catálogo por categorías: TPV, Channel Manager, pagos, CRM, centralita telefónica. https://www.covermanager.com/es/integraciones/
- Ágora — Integraciones y alianzas. Catálogo desde el lado del TPV, con gestión de reservas y asistente telefónico de reservas entre sus categorías. https://www.agorapos.com/integraciones/
- Observación propia en integraciones de producción, 2026. Los cinco hallazgos técnicos de este artículo proceden de integraciones reales entre motores de reservas de hostelería y bots conversacionales, y de auditorías sobre esos mismos sistemas. Van marcados uno a uno como
[observado en producción, 2026].
No se identifica a ningún cliente, ni se publican identificadores, nombres de flujo ni credenciales. Los casos se describen por tipo y tamaño de negocio. El artículo describe clases de problema y qué preguntar, no una guía de implementación.