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 falsaLo 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.