Probar webhooks
Un evento de prueba real, entregado por el mismo worker y firmado con el mismo secreto, sin tocar ninguna reserva.
1 · Pide el evento
curl -X POST https://wearetransfers.com/api/v1/webhooks/3c4d5e6f-7a8b-4c9d-8e0f-1a2b3c4d5e6f/test \
-H "Authorization: Bearer $WAT_API_KEY"{
"delivery_id": "6d2e1f0a-9b8c-4d7e-a6f5-4c3b2a1d0e9f",
"event_id": "8b7a6c5d-4e3f-4a2b-9c1d-0e9f8a7b6c5d",
"status": "pending"
}Es un 202: la entrega se encola y sale en la siguiente pasada del worker (normalmente en menos de un minuto).
2 · Lo que recibe tu servidor
POST /hooks/wat HTTP/1.1
Content-Type: application/json
User-Agent: WAT-Webhooks/1
X-WAT-Event: webhook.test
X-WAT-Event-Id: 8b7a6c5d-4e3f-4a2b-9c1d-0e9f8a7b6c5d
X-WAT-Delivery: 6d2e1f0a-9b8c-4d7e-a6f5-4c3b2a1d0e9f
X-WAT-Attempt: 1
X-WAT-Timestamp: 1758189600
X-WAT-Signature: v1=…{
"id": "2b3c4d5e-6f70-4a8b-9c0d-1e2f3a4b5c6d",
"type": "webhook.test",
"version": 1,
"created_at": "2026-09-18T10:00:00.000Z",
"organization": {
"id": "9a8b7c6d-5e4f-4a3b-8c2d-1e0f9a8b7c6d"
},
"resource": {
"type": "webhook",
"id": "3c4d5e6f-7a8b-4c9d-8e0f-1a2b3c4d5e6f"
},
"changes": [],
"previous_status": null,
"data": null
}resource.type es webhook, data es null. Todo lo demás —firma incluida— es idéntico a un evento real.
3 · Comprueba el resultado
curl "https://wearetransfers.com/api/v1/webhooks/3c4d5e6f-7a8b-4c9d-8e0f-1a2b3c4d5e6f/deliveries?limit=1" \
-H "Authorization: Bearer $WAT_API_KEY"{
"data": [
{
"id": "6d2e1f0a-9b8c-4d7e-a6f5-4c3b2a1d0e9f",
"event_id": "8b7a6c5d-4e3f-4a2b-9c1d-0e9f8a7b6c5d",
"event_type": "webhook.test",
"status": "succeeded",
"attempt": 1,
"max_attempts": 8,
"next_retry_at": "2026-09-18T10:42:10.000Z",
"last_status": 200,
"last_error": null,
"last_duration_ms": 212,
"delivered_at": "2026-09-18T10:42:10.000Z",
"created_at": "2026-09-18T10:42:08.000Z"
}
]
}succeeded con last_status: 200 es lo que buscas. Si ves failed, last_error y last_status dicen por qué; se reintentará según la política.
webhook.test no aparece en GET /v1/events y no depende de que la salida de eventos de reservas esté activada para tu organización: puedes probar el destino antes de recibir el primer evento real. Lo que sí hace falta es tener los webhooks activados; si no, la respuesta es 403 api_disabled.
Cada prueba es un POST firmado a un servidor de verdad, así que el tope va por destino —el host de la URL— y no por webhook: dos webhooks apuntando al mismo servidor comparten las cinco del minuto. Al superarlo, 429 rate_limited con Retry-After.
Probar en local
La URL tiene que ser https:// pública: localhost, redes privadas y puertos distintos de 443 se rechazan al crear el webhook. Usa un túnel (ngrok, Cloudflare Tunnel o similar) y apunta el webhook a esa URL mientras desarrollas. Bórralo al terminar.