Webhooks

Probar tu receptor sin otro número

Prepará una prueba de contrato independiente de la autorización de Meta.

Revisado el 28 de septiembre de 2026 · WhatsAut

Separá las pruebas del tráfico real

Usá un endpoint de ensayo con secretos ficticios y una cola independiente. No apuntes pruebas de error a una automatización que pueda enviar mensajes o crear pedidos.

Podés comprobar desafío, firmas, clasificación y deduplicación sin dar de alta un número. No hace falta iniciar el popup de Meta para ejecutar tus pruebas locales.

Autenticar la prueba inicial sin una clave de API

WhatsAut firma los pings con X-WhatsAut-Test-Signature-256. Podés validarlos antes de conectar Meta usando el mismo token que configuraste para el desafío GET. Elegí un token aleatorio de al menos 32 caracteres y tratá ese token como un secreto compartido. No lo registres en logs.

Descargá /assets/examples/webhook_verification.py y llamá verify_test_ping con los bytes originales, esa cabecera, tu verify token y la URL HTTPS exacta que muestra el panel (incluyendo la barra final, si existe). No construyas esa URL a partir de cabeceras del visitante.

El algoritmo es HMAC-SHA256 sobre el prefijo whatsaut.webhook_test.v1 seguido de un salto de línea, la URL, otro salto de línea y el cuerpo original. La cabecera contiene v1= seguido del resultado hexadecimal. El helper acepta sólo el esquema sintético, una antigüedad máxima de cinco minutos y hasta 30 segundos de adelanto; sincronizá el reloj del servidor.

Una prueba válida recibe HTTP 2xx y no crea pedidos ni envía mensajes. Deduplicá request_id durante cinco minutos si registrás la prueba. La firma prueba conocimiento del secreto compartido, no exclusividad del emisor. No autoriza mensajes ni estados de Meta; esos usan el verificador Runtime y su firma original.

from webhook_verification import verify_test_ping

valid = verify_test_ping(raw_body, test_signature, verify_token, callback_url)
# Sólo si valid es True: devolver 204 sin acciones de negocio.
# Si es False: rechazar esta prueba; nunca tratarla como mensaje autorizado.

Matriz mínima de aceptación

1. GET válido: 200 con el challenge exacto. Token erróneo: rechazo. Challenge ausente: rechazo.

2. POST sin firma o con cuerpo alterado: rechazo. Firma válida con credencial de ensayo: se valida la estructura antes de aceptar.

3. Ping sintético: 2xx sin efectos. Mensaje duplicado: una sola tarea. Dos estados del mismo mensaje: ambos se registran sin repetir la acción de negocio.

4. Payload con varias entradas: se recorren todas. Evento desconocido: tratamiento controlado. Cola no disponible: no confirmar que se guardó una tarea inexistente.

Qué registrar

Guardá resultado, hora, estado HTTP y un identificador ficticio. No imprimas tokens del query ni cuerpos de conversaciones.

Probá concurrencia: dos entregas del mismo ID al mismo tiempo no deben crear dos trabajos. Repetí después de reiniciar el receptor para verificar que la deduplicación sea durable.

Caso                         Resultado esperado
GET correcto                 challenge exacto
GET con token incorrecto     rechazo
POST con firma alterada      rechazo
Ping                         sin acción comercial
Mismo mensaje dos veces      una tarea
Cola caída                   sin confirmación falsa

Lo que estas pruebas no demuestran

Estas pruebas no verifican permisos de Meta, elegibilidad de coexistencia ni entrega real de mensajes.

Conservá los resultados como preparación; cuando exista una integración autorizada, faltará comprobar su tráfico real.

¿Necesitás ayuda? Prepará tu consulta para soporte →