Confirmación de entregas
Tu endpoint debe responder con un código de estado2xx dentro de 30 segundos para confirmar la recepción. Cualquier otro código de estado o un timeout se considera un fallo.
Política de reintentos
Con la configuración predeterminada, Nexor realiza como máximo tres intentos de entrega en total:
Si falla el tercer intento total, la entrega se marca como
failed y no se realizan más intentos.
Los reintentos solo se activan para:
- Errores de servidor 5xx
- Respuestas de límite de tasa 429
- Timeouts sin respuesta dentro de 30 segundos
- Errores de red, como una conexión rechazada o un fallo de DNS
Salud del webhook y desactivación automática
Nexor cuenta los fallos terminales consecutivos de cada webhook:- Después de 5 fallos consecutivos, su salud cambia a
degraded. - Después de 20 fallos consecutivos, su salud cambia a
failing. - Después de 100 fallos consecutivos, Nexor desactiva el webhook.
healthy. Reactivar un webhook desde el dashboard también restablece ambos valores.
Registros de entrega
Cada intento de entrega aparece en el dashboard. Abre un webhook para revisar sus entregas. Cada registro incluye:- URL, headers y cuerpo de la solicitud
- Estado, headers y cuerpo de la respuesta
- Duración en milisegundos
- Número de intento
- Mensaje de error, cuando existe
Idempotencia
Tu endpoint puede recibir el mismo evento más de una vez si Nexor lo reintenta. Eldelivery_id cambia en cada intento, mientras que el event_id identifica el evento original. Usa event_id para evitar procesarlo dos veces:
Ejecuta el handler solo después de que un middleware verifique X-Nexor-Signature contra el cuerpo original y exacto de la solicitud y tu secreto de firma, como se explica en Verificación de firmas. Rechaza una firma inválida antes de leer event_id o reclamar el evento.
claim, complete y release con una base de datos o caché persistente. El claim debe ser atómico para impedir que dos entregas simultáneas comiencen a procesar el mismo evento. Dale a cada claim en curso un plazo que venza para que un reintento posterior pueda recuperarlo si el proceso se detiene antes de liberarlo. Protege complete y release con el token del propietario del claim para que un proceso vencido no pueda modificar un claim más reciente. Renueva ese mismo claim antes de su vencimiento si el procesamiento puede durar más. Marca el evento como completado solo después de terminar el trabajo y haz que ese trabajo se pueda repetir de forma segura si el proceso se detiene entre el efecto externo y el registro de finalización.
Pruebas
Usa la acción Test del dashboard de webhooks para enviar un payload de ejemplo a tu endpoint. Los payloads de prueba contienen"test": true para distinguirlos de los eventos reales.