Cuando un sistema del que depende un producto no tiene API pública, la integración debe construirse contra la interfaz que sí expone, aun cuando esa interfaz haya sido diseñada para una persona y no para un programa. En DinDin, una suite de tecnología conectada para restaurantes, esa interfaz era una bandeja de entrada.
01Cómo leer este trabajo
El problema: dos marketplaces, sin API de pedidos
Los restaurantes clientes de DinDin reciben pedidos desde varios canales —su propio sitio, su punto de venta y marketplaces de entrega de terceros— y cada uno de esos pedidos debe llegar a la misma impresora de cocina, al mismo reporte y al mismo flujo de trabajo operativo. Los pedidos de Grubhub y DoorDash eran el vacío: ninguno de los dos marketplaces exponía la API de pedidos que este flujo de trabajo necesitaba. Lo que cada marketplace sí envía, de forma confiable, es un correo HTML de confirmación de pedido a la propia bandeja de entrada del restaurante: el mismo correo que un gerente leería manualmente.
02Cómo leer este trabajo
Construcción de la integración contra la bandeja de entrada
El pipeline se autentica en esa bandeja de entrada compartida y trata cada confirmación entrante como la superficie de integración: analiza el correo HTML de confirmación de pedido, identifica al comercio al que pertenece y extrae el pedido hacia el modelo nativo de pedidos de DinDin. A partir de ahí, resulta indistinguible de un pedido tomado en el propio sitio del restaurante: llega a la misma impresora de cocina y al mismo reporte. La API de Gmail es un punto de referencia razonable de cómo suele construirse una integración autenticada de bandeja de entrada como esta (ver: guías de la API de Gmail, citadas más abajo).
03Cómo leer este trabajo
Deduplicación: la parte que permite volver a ejecutarlo de forma segura
Una integración basada en correo electrónico debe tolerar volver a ejecutarse: una conexión puede caerse a mitad de una descarga, o un mensaje puede reprocesarse. El pipeline elimina duplicados usando el propio número de pedido de cada marketplace, en lugar de derivar una identidad a partir de contenido de texto libre, de modo que reprocesar el mismo correo de confirmación nunca crea un segundo ticket de cocina. Esta es la misma disciplina de solicitudes idempotentes documentada en el diseño de API de pagos, donde se usa un identificador provisto por el cliente específicamente para que una solicitud reintentada no pueda cobrar ni crear dos veces (ver: documentación de solicitudes idempotentes de Stripe, citada más abajo).
04Cómo leer este trabajo
A qué se generaliza esto
La lección general no es específica de los restaurantes ni del correo electrónico: cuando un sistema no expone una API, la integración se construye contra la interfaz más estable que sí expone —aunque esté pensada para una persona— y se vuelve segura de reejecutar con la misma disciplina de deduplicación que usaría una integración de API adecuada. Aquí la bandeja de entrada no es una solución alternativa; tratada con la disciplina correcta, es la integración.
