Los sistemas y APIs en empresas de hostelería son el TPV, el motor de reservas, la carta y la facturación, más los puentes que intercambian mesa, ticket y cliente. Un caso práctico con criterio de seguridad no conecta todo con todo: elige un flujo (reserva que llega a sala y cierra en caja) y define quién lee, quién escribe y qué dato de cliente sale del recinto. Si el puente no tiene permisos, registro y caducidad, no es integración: es un agujero.
Eso suena abstracto hasta que llega un sábado con dos turnos y un TPV que no se entera de que la mesa 12 ya está asignada. Alguien copia un Excel, alguien llama y alguien escribe el móvil del cliente en un papel junto a la caja. Conectar sistemas y APIs no es capricho técnico: es dejar de improvisar el mismo dato en tres pantallas.
Sistemas y APIs en un restaurante: qué hay de verdad
En sala conviven piezas que no se diseñaron juntas. El motor de reservas vive en la nube del proveedor. El TPV está en caja, a veces con versión vieja y un usuario compartido. Carta digital, pase de cocina y facturación son otras pantallas. Si hay segundo local, multiplica. Cada una guarda un trozo: hora, mesa, alérgeno, ticket, pago.
Una API es el contrato para que una pieza pregunte o escriba en otra sin que un humano copie. Puede ser un webhook de reserva nueva o el conector del fabricante. Importa qué campo viaja, con qué permiso y qué pasa cuando el proveedor se cae a las 21:10.
En un comercio local de Sabadell o Barcelona el mapa es más pequeño que el de una cadena, y por eso se improvisa más. Menos IT, mismas noches. El riesgo no es tener pocos sistemas. Es tenerlos sueltos y pretender que la jefa de sala haga de pegamento. Si el grupo vende a hoteles, ese catálogo B2B no se cuela en el mismo puente que la reserva de sábado.
Caso práctico: reservas, TPV y pase de cocina
Un restaurante con reservas online, dos salas y un TPV que ya funciona. El dolor no es la web. Llega una reserva con nota de alergia, sala no la ve a tiempo, cocina se entera en el pase y caja abre mesa como walk-in. El caso no empieza por integrar el ecosistema. Empieza por un flujo que se señala con el dedo: reserva confirmada, mesa asignada, nota en sala, ticket en TPV, comanda en cocina.
El flujo que sí merece un puente
El primer puente tiene tres movimientos.
- Alta de reserva hacia sala. Nombre, cubiertos, hora, mesa si ya está asignada, nota de alergia o celebración. Nada de historial ni tarjetas.
- Estado de mesa hacia el TPV. Ocupada, libre, fusionada. Para que caja no siente dos partidas en la misma mesa.
- Cierre de ticket hacia el motor de reservas. Un sí o no: esa reserva se sentó y pagó. Sin mandar cada línea de carta si no hace falta para operar.
¿Hace falta un panel interno? A veces: una pantalla de sala con el turno de hoy y las notas, sin cinco logins. Si lo montas, que lea. Que no escriba en todos los sistemas.
Lo que se queda fuera a propósito
Fuera del primer corte: delivery, puntos, gift cards, volcar clientes a un CRM por si acaso, y la contabilidad. También fuera: clonar el catálogo B2B de menús de empresa dentro del motor de reservas de particulares. Si hay dos locales, primero uno, un turno completo, una semana. Copiar las credenciales del A en el B mezcla reservas y luego nadie sabe de quién era el teléfono.
Criterio de decisión: qué conectar en el primer corte
El criterio no es «el proveedor tiene API, luego se conecta». Es más seco.
- Un dueño por campo. La hora la manda el motor de reservas. El total del ticket lo manda el TPV. Si los dos escriben lo mismo, el sábado gana el que gritó último.
- Lectura o escritura, no las dos por defecto. Un webhook que avisa de un alta es más fácil de acotar que un puente que cancela, reasigna y borra clientes.
- Dato personal mínimo. Teléfono y nota de alergia viajan si sala los necesita esa noche. Historial y correo de marketing, no. Si no hace falta para sentar, no sale.
- Caída del proveedor. Si el motor se cae, ¿sala sigue con el TPV y una lista en papel? Si la respuesta es no, el puente es un punto único de fallo.
- Exportación. Si cambias de TPV, ¿sacas reservas y tickets sin pedir un favor por email? Si la API solo entra y no sale, alquilas tu operativa.
El mismo corte vale para un obrador que sirve a hoteles: el pedido B2B no comparte tubería con la reserva de sábado. Dos flujos, dos contratos. Si el puente tiene que vivir en un servidor y no en el PC de oficina, entra cloud y sistemas: credenciales fuera del escritorio y un sitio al que mirar cuando falle a las once. No es mudarse a la nube por moda. Es no dejar la llave en un portátil que se va de vacaciones.
El error habitual: API de reservas con llave de administrador
El error habitual no es elegir mal el TPV. Es pedir «la API» como si fuera un USB. El proveedor entrega una clave con lectura y escritura sobre clientes, reservas y a veces pagos. Alguien la pega en un plugin, en una hoja o en el WhatsApp del encargado. No hay rotación ni registro. El webhook recibe sin firmar. El log guarda el teléfono del cliente en claro «para depurar».
A partir de ahí un perfil que debía ver el turno de hoy lista la base de reservas. Un conector que debía avisar de altas puede cancelar. Otro clásico: sincronizar cada noche todos los clientes a una carpeta de oficina, por si marketing los necesita. Eso no es un puente. Es una copia de datos personales sin dueño. Si hace falta un extracto, se pide el campo concreto y se borra cuando el uso termina.
Sistemas y APIs con criterio de seguridad
Seguridad, aquí, no es un sello. Es recortar lo que el puente puede hacer y saber quién lo hizo. La ciberseguridad de un restaurante se juega en las llaves, no en un banner de cookies.
Permisos mínimos: una clave que solo crea o actualiza reservas, otra si hace falta leer estados, ninguna que administre usuarios del TPV. Si el fabricante solo ofrece una llave dios, no la clones en tres herramientas. Ponla detrás de un servicio tuyo que exponga menos.
Si quien montó el puente se va, la clave se cambia esa semana. El registro guarda quién llamó, qué reserva tocó y el resultado, no el cuerpo del cliente. Firma en webhooks. Entorno de pruebas aparte. La nota de alergia llega a quien cocina esa noche y no se reenvía a marketing. Nada de un usuario «sala» compartido para backoffice y TPV. El puente no disculpa el desorden de logins. Lo hereda.
Mantenimiento y medición después de conectar
Una integración que no se mira se pudre. El proveedor cambia un campo, el TPV actualiza, el webhook deja de firmar y nadie se entera hasta un festivo. El mantenimiento es una ronda corta, cada semana, con números que un encargado entiende.
Mide esto, no visitas de la web:
- Reservas que llegaron a sala frente a las creadas en el motor. Un hueco es altas perdidas o un campo obligatorio mal mapeado.
- Tickets abiertos sin reserva asociada en hora de reservas. No todos son walk-in. Una parte es mesa que el TPV no enteró.
- Reservas marcadas como sentadas sin cierre de ticket. El cubierto se infló o caja no devolvió el estado.
- Errores del puente (rechazos, firmas, caídas) por franja. Un pico a las 21:00 no es ruido: es el servicio.
- Tiempo entre reserva confirmada y nota visible en sala. Si tarda diez minutos, cocina ya va tarde.
Alerta útil: fallos seguidos o desfase de reservas frente a tickets en cena. Alerta inútil: un recuento de llamadas API que no dice si existía la mesa 12. Revisa claves: última rotación, quién las tiene, si las pruebas siguen apuntando a producción. Terraza, eventos o catering B2B son otro puente, otro permiso. No copies conectores a ojo de un local a otro.
Preguntas frecuentes
¿Qué sistemas y APIs necesita un restaurante con reservas?
Los mínimos suelen ser motor de reservas, TPV y, si cocina no mira el TPV, el pase de comandas. La API entra cuando esos tres tienen que compartir mesa, hora y nota sin que sala copie. Carta, delivery y facturación pueden esperar. Si aún no hay dueño de cada campo, no hace falta más software: hace falta decidir.
¿Es seguro conectar el TPV con el motor de reservas?
Es seguro si la clave no es de administrador, el puente escribe solo alta, estado de mesa y sentado o pagado, y los logs no guardan teléfonos ni alergias en claro. Si pegas la llave en un conector genérico con permiso total, abres caja y agenda a quien tenga ese secreto. Firma webhooks y rota la clave cuando cambia el equipo.
¿Hace falta una API propia o basta con la del proveedor?
Basta con la del proveedor si cubre el flujo, permite permisos estrechos y puedes exportar. Una API propia o un panel tiene sentido cuando el fabricante solo ofrece una llave dios, hay dos locales con reglas distintas o sala necesita una pantalla que el backoffice no da. No se construye por prestigio. Se construye para recortar permiso.
¿Qué pasa si el proveedor de reservas no tiene API?
Entonces no hay puente real. Hay CSV, copia a mano o un robot que simula clics. Esas vías fallan en hora punta y suelen pelear con la seguridad. O el proveedor publica un contrato usable, o cambias de proveedor, o aceptas que sala y caja no se hablen solos.
¿Cuánto tarda conectar reservas y TPV en un local?
Con ambos sistemas ya en uso, el primer flujo (reserva a sala, mesa a caja, cierre de ticket) se acota en semanas. Lo que alarga no es el cable: es limpiar usuarios compartidos, decidir el dueño de cada campo y probar un viernes de verdad. Si te venden la conexión en dos días sin mapa de permisos, desconfía.
Si las reservas no llegan a caja o hay claves de más, el trabajo es de sistemas y APIs con corte de seguridad, no de pintar otra landing. En Chocola Studio, en Sabadell, miramos el flujo de sala antes que el catálogo de conectores. Cuéntanos el circuito de un servicio y te decimos qué puente merece la pena y cuál sobra.