La ventana de 24 horas de WhatsApp: qué la abre, qué la cierra y dónde falla el cálculo
Toda integración con la Cloud API choca con la misma regla, y la mayoría calcula mal la misma parte. La ventana no empieza cuando tu servidor procesa el webhook: empieza en el timestamp que Meta envió dentro de él.

Lo que te llevas
- Por qué anclar al reloj equivocado produce 131047 en una conversación que tu propia pantalla muestra abierta
- El mensaje entrante que NO abre la ventana
- Por qué los flows y los mensajes interactivos no son una excepción
La regla, sin rodeos
Dentro de la ventana de atención envías lo que quieras: texto, multimedia, mensajes interactivos, flows. Fuera de ella, solo plantillas aprobadas. No hay término medio ni categoría de mensaje que se escape — Meta rechaza con el error 131047 y el mensaje no sale.
La ventana se abre cuando el cliente te escribe y dura 24 horas desde ese mensaje. Cada nuevo mensaje del cliente reinicia el reloj. Fácil de enunciar, y es justamente por parecer fácil que casi toda implementación falla en el mismo detalle.
El reloj correcto es el de Meta, no el tuyo
El webhook de Meta trae un campo timestamp con el momento en que el mensaje llegó a ellos, en segundos Unix. Ese instante es el que abre la ventana. El momento en que tu servidor procesó el webhook no lo es.
Parecen lo mismo y casi siempre lo son, hasta el día en que no. Los webhooks se reentregan. Si Meta reenvía un evento con retraso, o tu cola se acumula durante un incidente, tu cálculo empieza a conceder una ventana más generosa que la real. Tu sistema se convence de que puede enviar texto libre, Meta discrepa, y el 131047 aparece en una conversación que tu propia pantalla dibuja como abierta.
El síntoma es cruel porque la interfaz y Meta cuentan historias distintas sobre el mismo dato, y la interfaz parece confiable. Anclamos la ventana al timestamp del payload después de que una autorrespuesta de bienvenida fallara exactamente así, con la conversación abierta en pantalla.
El mensaje que llega y no abre nada
No todo mensaje entrante abre la ventana. Cuando el cliente envía algo que la Cloud API no sabe representar — ciertos tipos de adjunto, mensajes de sistema, contenido que Meta clasifica como unsupported — el evento llega a tu webhook con el tipo unsupported, normalmente con el error 131051 en el array de errores.
Ese evento no abre ninguna ventana del lado de Meta. Si tu enrutador de tipos mete unsupported en el mismo grupo que interactive (un error fácil, porque estructuralmente se parecen), acabas de registrar una ventana que no existe — y vas a disparar una autorrespuesta y un agente de IA contra una conversación que solo acepta plantillas.
La regla que quedó en nuestro código: un mensaje con tipo unsupported, o con cualquier cosa dentro de errors[], no abre ventana, no dispara autorrespuesta y no despierta a la IA. Se registra en el historial para que el agente vea que algo llegó, y hasta ahí.
Los flows e interactivos no son excepción
Existe la creencia de que los mensajes interactivos y los flows escapan de la ventana por ser “estructurados”. No escapan. Un flow enviado fuera de la ventana se rechaza igual que un texto suelto.
Para reenganchar a alguien fuera de la ventana con un flow, el flow tiene que ir envuelto en una plantilla de flow aprobada — es otro objeto, con su propio ciclo de aprobación. No es una bandera en el envío.
Conviene comprobarlo en tu propio guard antes de llamar a Meta. Bloquear localmente con un error claro cuesta milisegundos; descubrirlo por el 131047 cuesta una ida a la API, una entrada de error en el historial del cliente y, según tu política de reintentos, una escalera de intentos que nunca va a pasar.
Las tres reglas que quedaron en el código
timestamp de Meta (segundos Unix) y úsalo como inicio de la ventana. Nunca tu hora de procesamiento.unsupported como no-eventoTipo unsupported o errors[] no vacío: se registra en el historial, no abre ventana, no dispara respuesta automática.