Cómo Construí OrderBridge: Resolviendo la Conexión Delivery-a-POS
Hace unos meses, un cliente llegó a mí con un problema simple de describir y que parecía bastante directo. Necesitaban conectar las principales plataformas de delivery con su propio sistema POS mediante un handshake automatizado con OAuth 2.0.
Este proyecto comenzó como un brief real de cliente. La solicitud llegó en español: “Queremos conectar los servicios de domicilios de nuestros clientes (DoorDash, etc.) a StreamOrder utilizando OAuth. Una vez que StreamOrder esté conectado y autenticado, las cuentas de los servicios de entrega de los clientes se conectarán a nuestro sistema POS.” En resumen: necesitaban conectar las cuentas de delivery de sus clientes a su sistema POS a través de la API de socios de StreamOrder — de forma automática, vía OAuth, sin intervención manual. Analicé los requisitos, leí la documentación del partner de StreamOrder y me puse a trabajar.
La Propuesta al Cliente
Antes de escribir una sola línea de código, preparé una propuesta formal. Eso forzó claridad en ambos lados — el cliente entendía exactamente lo que iba a recibir, y yo entendía exactamente lo que iba a construir.
PROPUESTA DE PROYECTO
Integración de Apps de Delivery al POS
Middleware API · StreamOrder · OAuth 2.0
Maximiliano B. Torres
February 27, 2026
DESCRIPCIÓN
Este proyecto establece un "Puente Digital" seguro y automatizado — una Middleware API entre el agregador StreamOrder y el sistema de Punto de Venta (POS) del cliente, permitiendo que los pedidos de delivery fluyan automáticamente al POS sin intervención manual.
OBJETIVO
Implementar OAuth 2.0 como capa de autenticación, garantizando que los datos permanezcan seguros mientras los pedidos se sincronizan automáticamente desde las plataformas de delivery al POS.
FLUJO DE ARQUITECTURA
Cronograma de 4 Semanas
Semana 1
Seguridad y el Handshake Digital
Objetivo: Conectar las cuentas del cliente de forma segura.
Resultado: StreamOrder oficialmente vinculado; datos protegidos por llaves OAuth cifradas.
Semana 2
El Puente de Automatización
Objetivo: Hacer que los sistemas se comuniquen.
Resultado: Traductor y listener de webhooks funcionando en entorno de prueba — pedidos capturados y traducidos al instante.
Semana 3
Dashboard y Lanzamiento en Vivo
Objetivo: Visibilidad y preparación para producción.
Resultado: Puente activo, pedidos imprimiéndose en el POS, dashboard de monitoreo en vivo entregado.
Semana 4
Refinamiento y Monitoreo
Objetivo: Estabilidad bajo condiciones reales.
Resultado: Ventana de monitoreo en vivo de 7 días; cambios de API de StreamOrder o plataformas de delivery parcheados de inmediato.
Entregables Principales
PRERREQUISITOS DEL PROYECTO
El Caos de los Pedidos Manuales
Antes de automatizar esto, el flujo de trabajo era tedioso y doloroso. La mayoría de las cocinas ocupadas tienen un mostrador lleno de tablets de diferentes apps de delivery.
Un empleado tenía que:
- Leer el pedido en la tablet.
- Escribirlo manualmente en el POS.
- Esperar no haberse saltado un modificador como "sin cebolla".
En una tienda tranquila es aburrido. En una cocina con 80+ pedidos al día, es un problema operativo muy doloroso.
LAS MATEMÁTICAS
50 pedidos al día × 2.5 minutos de captura manual × $18/hr = más de $1,100 perdidos cada mes en una tarea que no debería involucrar a ningún humano.
Construyendo el Pipeline
Una vez que el ROI quedó claro, diseñé el pipeline. La lógica tenía que ser a prueba de fallos:
Ingerir webhooks de delivery
Recibir POST HTTPS de cada plataforma de delivery.
Verificar firmas
Verificación HMAC-SHA256 — seguridad antes que todo.
Traducir schemas
Mapear payloads JSON dispares a un formato POS unificado.
Inyectar el pedido
POST a la API del POS con reintentos de backoff exponencial.
Transmitir actualizaciones
Push WebSocket al dashboard en vivo — sin polling.
Primero Escribir el Spec
Empecé con una Especificación de Requisitos de Software (SRS) antes de escribir una sola línea de código. Es mucho más fácil corregir un error en un documento que reescribir código de producción después. El SRS forzó tanto a mí como al cliente a acordar exactamente qué significaba "listo" — sin ambigüedad, sin cambios de alcance.
El sistema debe actuar como proveedor OAuth 2.0 — emitiendo, validando y renovando tokens conforme al RFC 6749.
El sistema debe aceptar webhooks HTTPS POST de plataformas de delivery y verificar cada solicitud con validación de firma HMAC-SHA256.
El sistema debe mapear todos los payloads de delivery entrantes a un formato POS unificado, con fallo elegante y logging en SKUs no mapeados.
El sistema debe hacer POST de pedidos traducidos a la API del POS con reintentos de backoff exponencial — ningún pedido se pierde en silencio.
El dashboard debe reflejar cambios de estado de pedidos vía push WebSocket. Sin polling.
Los tokens OAuth deben sobrevivir reinicios del servidor, almacenados cifrados en reposo.
El Tech Stack
Qué herramientas usaría para este tipo de proyecto:
Estoy seguro de que Python también hubiera funcionado muy bien aquí. Personalmente prefiero trabajar con módulos de node y npm antes que con pip y entornos virtuales.
Express es el default de siempre, pero Fastify está construido para el rendimiento moderno. Validación JSON schema integrada, menor sobrecarga. Para una Middleware API donde cada milisegundo cuenta, Fastify gana.
Infraestructura
Los tres servicios están desplegados de forma independiente — cada uno con su propio host, su propio dominio y su propia responsabilidad. Esto refleja cómo se estructuraría una integración de producción real.
VISIÓN GENERAL DE INFRAESTRUCTURA
UI de monitoreo en tiempo real — desplegada en edge, disponible globalmente.
Motor middleware principal con el servidor OAuth, ingesta de webhooks, traductor de schemas e inyector al POS. PostgreSQL almacena tokens OAuth, mapeos de menú y logs de pedidos.
Simulador de POS aislado ejecutándose como un servicio completamente separado — su propio flujo de consentimiento OAuth, su propio terminal de pedidos.
POR QUÉ SERVICIOS SEPARADOS
Mantener MockPOS en su propio servicio de Railway no era solo conveniente — era el punto. Demuestra que la integración funciona a través de un límite de red real, no solo entre dos funciones en el mismo proceso.
Traducción y Confianza
El Traductor fue la parte más difícil de este proyecto. DoorDash, Uber Eats y GrabFood tienen ideas muy distintas de cómo describir una "hamburguesa sin pepinillos". Mapear estos payloads inconsistentes a un SKU de POS estandarizado mientras se mantiene una tabla de MenuMapping requirió un manejo profundo de casos extremos. Si el mapeo falla, el sistema tiene que fallar elegantemente — no dejar caer el pedido en el vacío.
Luego estaba el Servidor OAuth 2.0. Una cosa es usar OAuth; otra muy distinta es ser el proveedor. Construir los endpoints de autorización, la lógica de tokens y el almacenamiento cifrado conforme a las especificaciones RFC costó más canas que el resto de la app combinado.
Presentando OrderBridge
Disfruté tanto la arquitectura del proyecto del cliente que construí OrderBridge — una versión refinada e independiente para mi portafolio. No es solo una copia; es una evolución. Un demo end-to-end completo que simula todo el flujo sin necesitar infraestructura real.
El Codebase Completo
Los tres componentes principales son open-source y están disponibles en GitHub:
Pruébalo
Ambos servicios están activos y listos para usar:
¿Listo para Explorar?
Explora el código fuente, observa los sistemas en vivo, o revisa el caso de estudio completo.