Yendo cuando WhatsApp se cae: por qué la gente siguió fichando con la API caída 182 minutos

Lo que pasó el viernes 12/06

A media mañana del viernes 12 de junio, la WhatsApp Business Platform (Cloud API) sufrió una interrupción. Según el tablero oficial de Meta, el incidente duró 182 minutos: durante ese período los mensajes entrantes y salientes a través de la API quedaron degradados o directamente sin entregar. No fue un problema de Yendo, ni de un proveedor nuestro — fue la propia capa de mensajería de Meta.

Podés ver el registro del incidente en el estado oficial: metastatus.com/whatsapp-business-api.

Para cualquier producto que vive dentro de WhatsApp, una caída así es el peor escenario: tu único canal con el usuario se apaga. Y sin embargo, mientras la API estaba caída, en el dashboard seguían apareciendo fichajes válidos, con GPS y hora exacta. La pregunta obvia es ¿cómo?

La idea clave: separar el "hablar" del "escribir"

La conversación por WhatsApp es la capa de control de Yendo: ahí el colaborador dice qué quiere hacer ("entrada", "salida") y el bot resuelve a quién, en qué empresa y con qué intención. Pero el fichaje en sí — el registro inmutable con GPS, dispositivo y, en planes pagos, biometría — no se escribe desde WhatsApp. Se escribe desde la PWA (la mini-web que se abre al tocar el link) contra un webhook transaccional propio, respaldado en Postgres.

Son dos dominios de disponibilidad distintos:

• Plano de conversación: WhatsApp Business API (Meta) → orquestación → clasificación de intención. Si Meta se cae, este plano se cae.
• Plano de escritura (fichaje): PWA en app.yendo.work → webhook ProcessData → Supabase Postgres. Hospedado aparte, no depende de la API de WhatsApp para persistir un fichaje.

El truco de resiliencia es que el plano de escritura no necesita al plano de conversación para funcionar. Si el colaborador ya tiene un link en la mano, puede fichar aunque el bot esté mudo. Lo único que puede demorarse es el mensaje de confirmación de vuelta por WhatsApp — pero el fichaje ya quedó guardado y visible en el dashboard.

Anatomía de un link corto efímero

Cuando el colaborador escribe "entrada", el bot resuelve la intención y genera un deep-link a la PWA con todo el contexto: userId, companyId, actionType, mode, source, lang. Ese link es largo y feo, y nadie quiere tocarlo dos veces. Así que no lo mandamos crudo: lo envolvemos en un link corto.

Detrás de ese link corto no hay un simple redirect estático. Hay un registro efímero que guarda tres cosas: a quién pertenece, la intención que se resolvió en el chat (ingress / egress), y una marca de tiempo. Sobre esa marca corre una ventana de validez de la intención: 15 minutos.

corto:  yen.do/AbC123
   │
   ├─ ≤ 15 min  → honra la intención del chat
   │             302 → app.yendo.work?actionType=ingress&… (un toque y listo)
   │
   └─ > 15 min  → la intención venció
                 → /elegir : "¿Entrada o Salida?"  (el usuario decide)
                 → app.yendo.work?actionType=&…

Dentro de los 15 minutos: camino rápido

Si el colaborador toca el link dentro de la ventana, el link corto lo lleva directo a la PWA ya preparada con la acción que pidió por chat. Comparte ubicación, se valida el GPS y el dispositivo, y ficha. Un solo toque, cero ambigüedad. Es el 95% de los casos.

Pasados los 15 minutos: degradación elegante

Acá está la parte interesante. Si el link se toca después de la ventana, ya no asumimos que la vieja intención sigue vigente — sería peligroso. En vez de fallar o de fichar la acción equivocada, el link cae a una página neutral que pregunta qué querés hacer: ¿entrada o salida? El usuario elige, y recién ahí se arma el fichaje. La validación de GPS, dispositivo y biometría es exactamente la misma; lo único que cambió es de dónde salió la intención.

Esto es graceful degradation de manual: en condiciones ideales el sistema entrega la experiencia óptima (un toque), y cuando una premisa deja de ser segura (la intención envejeció), no se rompe — baja un escalón a una experiencia un poco más manual pero igual de válida.

Por qué esto salvó el viernes

Durante los 182 minutos de caída, varios colaboradores no pudieron iniciar una conversación nueva con el bot. Pero muchos ya tenían un link de Yendo en su chat — el de un fichaje anterior, a veces de horas o días atrás. Lo tocaron por inercia. Como esos links están muy por fuera de la ventana de 15 minutos, no intentaron fichar una acción vieja a ciegas: cayeron en el selector de acción, la persona eligió "salida" (o "entrada"), y el fichaje se registró normalmente contra Postgres. La capa de WhatsApp estaba caída; el plano de escritura, no.

11:48 — La API de WhatsApp empieza a fallar. Los mensajes nuevos al bot no entran.

12:10 — Marta, de una cuadrilla de limpieza, quiere marcar salida. El bot no responde. Sube en el chat, encuentra el link que usó para entrar a la mañana, lo toca.

12:10 — El link tiene 4 horas: está fuera de la ventana de intención. En vez de marcar "entrada" otra vez, la PWA le muestra "¿Entrada o Salida?". Marta toca "Salida", comparte ubicación.

12:10 — El fichaje viaja PWA → webhook ProcessData → Postgres. GPS validado, dispositivo reconocido. Queda registrado. En el dashboard, su salida aparece al instante.

12:11 — El mensaje de confirmación por WhatsApp queda encolado (la API sigue caída). Llega recién cuando Meta se recupera. El fichaje, mientras tanto, ya estaba a salvo.

El mismo patrón arregla el error humano

La caída de Meta fue el estrés-test perfecto, pero este patrón no se diseñó para los días en que WhatsApp se cae. Se diseñó para todos los días, porque resuelve un problema mucho más común: la gente que no es la mejor con los mensajes y toca el link equivocado.

Lo vimos seguido: una persona quiere marcar salida y, en vez de escribirle al bot, sube en el chat y toca el mismo link que usó para la entrada. Si ese link estuviera "duro" — clavado a la acción "entrada" para siempre — registraría una segunda entrada y rompería el par del día. Con el patrón efímero, ese link viejo ya venció su ventana de intención, así que en lugar de repetir la entrada le pregunta qué quiere hacer. La persona toca "Salida" y queda bien. Cero soporte, cero corrección manual del manager.

• Link reusado del día anterior: está fuera de ventana → selector de acción → la persona elige correcto.
• Toca "entrada" queriendo "salida": mismo selector lo encauza, no asume la acción vieja.
• Bot temporalmente caído (Meta): el link ya entregado sigue funcionando por el mismo camino.

Un solo mecanismo — la intención efímera con TTL y el respaldo a un selector neutral — cubre los tres casos. No hay ramas especiales para "WhatsApp caído" ni para "usuario tocó mal": es el mismo comportamiento por defecto, seguro ante la ambigüedad.

Los principios de diseño detrás

1. Separá los planos de disponibilidad. El canal por el que la gente habla (WhatsApp) no debe ser el mismo del que depende escribir el dato crítico (el fichaje). Si comparten destino, comparten caída.
2. La intención caduca; el link no. Un link efímero sigue siendo útil para siempre, pero la suposición de "qué querías hacer" tiene fecha de vencimiento. Separar ambas cosas evita acciones equivocadas.
3. Ante la duda, preguntá — no adivines. Cuando la premisa segura caduca, degradás a un paso extra (elegir acción), no a un error. El usuario casi no lo nota; el dato queda íntegro.
4. La validación vive del lado del servidor. Venga la intención de un camino rápido o del selector, el fichaje pasa por la misma verificación de GPS, radio, dispositivo y biometría. La degradación nunca relaja la seguridad.
5. La confirmación es best-effort; la persistencia es garantizada. El mensaje de "✅ fichaste" puede demorarse si WhatsApp está caído. El registro en Postgres no espera a nadie.

La conclusión

Construir sobre WhatsApp tiene una trampa silenciosa: es tan cómodo que es tentador apoyar todo sobre ese canal. El viernes 12/06 quedó claro por qué no conviene. Yendo trata a WhatsApp como lo que es — una excelente capa de conversación — pero nunca como el lugar donde vive el dato. El fichaje se persiste en una infraestructura que no comparte el destino de Meta, y el puente entre ambos mundos es un link corto efímero que prefiere preguntar antes que equivocarse.

El resultado es un sistema que el usuario percibe como simple — toca un link, ficha — y que por dentro está pensado para los días en que algo, en algún lado, se cae. Porque siempre se cae.