Raphael Serafim· Publicado el 10 de septiembre de 2026· 9 min de lectura

El webhook de WhatsApp no llega: las 7 causas y cómo probarlo en 30 segundos

El webhook de la API de WhatsApp no está llegando a tu servidor. Antes de tocar el código, una prueba con webhook.site te dice de qué lado está el problema. Las 7 causas más comunes, en el orden en que conviene revisarlas.

Ver como Markdown

Antes de abrir el código, averigua de qué lado está el problema. Toma 30 segundos y te ahorra la tarde entera, porque "el webhook no llega" tiene dos causas completamente distintas, y depurar la equivocada no lleva a ninguna parte.

La prueba de 30 segundos

Abre webhook.site. Genera una URL única al instante, sin registro.
Copia esa URL.
Configúrala como webhook de tu instancia, desde el panel o por la API.
Envía cualquier mensaje al número conectado.
Mira la pantalla de webhook.site.

Si el evento apareció ahí: la plataforma está enviando bien. El problema es tu servidor — salta a las causas 4 a 7.

Si no apareció: el evento no está saliendo. El problema es la configuración de la instancia — causas 1 a 3.

webhook.site además muestra el cuerpo exacto que llega, con las cabeceras. Es la forma más rápida de confirmar el formato antes de escribir cualquier parser, y puedes copiar ese JSON real para usarlo en tus pruebas.

Causa 1 — La URL no es HTTPS válido

La más común y la más molesta de descubrir, porque falla en silencio.

http:// sin TLS: rechazado.
HTTPS con certificado autofirmado: rechazado.
HTTPS con certificado vencido: rechazado.
Certificado válido solo para el dominio sin www, y la URL registrada con www: rechazado.

No hay error de tu lado. Simplemente no llega nada.

Cómo comprobarlo sin salir de la terminal:

curl -sS -o /dev/null -w "%{http_code}\n" https://tu-dominio.com/webhook/wame

Si aquí da error de certificado, allá también lo dará.

Causa 2 — La instancia está desconectada

Una instancia caída no emite eventos. Parece obvio, pero es la segunda causa más frecuente, sobre todo en la API no oficial, donde la sesión puede caerse sola.

curl "https://us.api-wa.me/TU_KEY/instance"

Si el estado no es conectado, el webhook es la consecuencia, no la causa. Reconecta primero.

Causa 3 — Filtro de eventos o formato equivocado

WAME permite filtrar qué eventos envía la instancia y en qué formato. Dos trampas:

Formato. Si tu instancia está en formato meta y tu código espera el formato antiguo (o al revés), el evento llega y el parser no encuentra nada. El formato meta es el sobre estándar de la Cloud API y es el recomendado: es lo que hace que un mismo handler sirva para WhatsApp, Instagram y Messenger.

Filtro. Si solo hay algunos eventos habilitados, "mensaje recibido" puede simplemente no estar en la lista.

Revisa ambas cosas en el panel de la instancia antes de sospechar del código.

Causa 4 — Estás leyendo el campo equivocado

¿Llegó a webhook.site pero tu código no ve nada? Probablemente sea esto.

En el sobre de Meta, mensaje y estado de entrega viven en campos distintos:

{
  "entry": [{
    "changes": [{
      "value": {
        "messages":  [ /* mensaje recibido */ ],
        "statuses":  [ /* entregado, leído, fallido */ ]
      }
    }]
  }]
}

El evento de estado no tiene messages. El código que hace value.messages[0] directamente se rompe — o, peor, no se rompe y simplemente lo ignora todo:

// mal: un estado de entrega tumba esto o pasa desapercibido
const msg = body.entry[0].changes[0].value.messages[0];

// bien
const value = body?.entry?.[0]?.changes?.[0]?.value;
const msg = value?.messages?.[0];
if (!msg) return res.sendStatus(200);   // era un estado, no un mensaje

La misma guarda vale para msg.type: el audio, la imagen y el documento no tienen text.body.

Causa 5 — Tu servidor no responde 200 rápido

Si el webhook llega duplicado, es esto. La plataforma espera confirmación; sin ella, reenvía.

El error clásico es procesar antes de responder:

// mal: el cliente recibe la respuesta 2 o 3 veces
app.post('/webhook/wame', async (req, res) => {
  await llamarIA(req.body);          // 3 segundos
  await guardarEnBase(req.body);     // uno más
  res.sendStatus(200);               // demasiado tarde
});

// bien
app.post('/webhook/wame', (req, res) => {
  res.sendStatus(200);               // primero esto
  procesar(req.body).catch(console.error);
});

Si tu procesamiento es pesado, mételo en una cola y responde 200 en cuanto lo encoles.

Causa 6 — El cuerpo no se está parseando

En Express, sin express.json() el req.body llega undefined y parece que el webhook no llegó:

app.use(express.json());   // antes de las rutas

Si validas la firma, también necesitas el cuerpo crudo, y express.json() por sí solo no guarda el original:

app.use(express.json({
  verify: (req, _res, buf) => { req.rawBody = buf; },
}));

Causa 7 — Firewall, proxy o WAF bloqueando

Si webhook.site recibe y tu servidor no, y ya descartaste las causas anteriores, algo en el medio está bloqueando: una regla de firewall, Cloudflare en modo agresivo, un WAF rechazando POST de origen desconocido, o un proxy que exige autenticación.

Pruébalo enviando un POST desde fuera, simulando a la plataforma:

curl -X POST https://tu-dominio.com/webhook/wame \
  -H "Content-Type: application/json" \
  -d '{"object":"wame","provider":"whatsapp","entry":[{"changes":[{"value":{"messages":[{"from":"525512345678","type":"text","text":{"body":"prueba"}}]}}]}]}' \
  -i

Si eso no llega a tu handler, el problema está en la infraestructura y no en la aplicación.

El orden que ahorra tiempo

Probar con webhook.site — decide de qué lado está.
Si no llegó ahí: HTTPS, instancia conectada, filtro y formato.
Si sí llegó: campo correcto, 200 rápido, parser del cuerpo, firewall.

Casi todos los casos caen en una de esas siete. Seguir el orden evita el escenario más común de todos: pasar dos horas revisando el parser cuando la instancia estaba desconectada.

Después de que vuelva a funcionar

Un webhook que llega no es lo mismo que un webhook confiable. Antes de ponerle carga encima, revisa la firma, la reentrega y el mensaje procesado dos veces — son los problemas que solo aparecen con volumen.

¿Listo para automatizar tu WhatsApp?

Crea tu cuenta gratis y empieza a enviar mensajes por la API en minutos.

Empezar gratis

Preguntas frecuentes

¿Cómo probar si el webhook de WhatsApp se está enviando?+

Abre webhook.site, copia la URL única que genera, configúrala como webhook de tu instancia y envía un mensaje al número. Si el evento aparece en la pantalla de webhook.site, la plataforma está enviando correctamente y el problema está en tu servidor. Si no aparece, el problema es la configuración de la instancia.

¿Por qué mi webhook recibe estados de entrega pero no mensajes?+

Casi siempre es un filtro de eventos o un campo equivocado. Los mensajes llegan en entry[0].changes[0].value.messages[0]; los estados de entrega llegan en value.statuses, y es habitual que el código trate ambos como si fueran lo mismo.

El webhook llega duplicado. ¿Por qué?+

Porque tu endpoint tardó en responder 200. Toda plataforma de webhooks reenvía cuando no recibe confirmación rápida. La corrección es responder 200 de inmediato y procesar después, de forma asíncrona, nunca dejar el procesamiento pesado antes de la respuesta.

¿El webhook funciona en localhost?+

No directamente: la plataforma necesita alcanzar tu URL por internet. En desarrollo usa ngrok, cloudflared o similar para exponer el puerto local con una URL pública HTTPS, y configura esa URL como webhook.

¿Necesito HTTPS en el webhook?+

Sí, con certificado válido. Una URL http:// o un HTTPS con certificado autofirmado o vencido se rechaza en silencio: el envío falla y no aparece ningún error de tu lado, lo que hace que esta sea una de las causas que más tiempo cuesta descubrir.