Skip to main content

Confirmacion de entregas

Tu endpoint debe responder con un codigo de estado 2xx dentro de 30 segundos para confirmar la recepcion. Cualquier otro codigo de estado (o un timeout) se trata como un fallo.

Politica de reintentos

Cuando una entrega falla, Nexor reintenta con backoff exponencial: Despues de 3 reintentos fallidos, la entrega se marca como failed y no se realizan mas intentos. Los reintentos solo se activan para:
  • Errores de servidor 5xx
  • Respuestas de limite de tasa 429
  • Timeouts (sin respuesta en 30s)
  • Errores de red (conexion rechazada, fallo de DNS)
Los errores 4xx (excepto 429) no se reintentan, ya que indican un problema permanente del lado del cliente (URL incorrecta, fallo de autenticacion, etc.).

Desactivacion automatica

Si un webhook acumula demasiados fallos consecutivos, Nexor lo desactiva automaticamente para evitar desperdiciar recursos. Puedes reactivarlo desde el panel, el contador de fallos se reinicia al reactivar.

Registros de entrega

Cada entrega (exitosa o fallida) se registra y es visible en el panel bajo la pestana Entregas de tu webhook. Cada entrada del registro incluye:
  • URL de la solicitud, headers y cuerpo
  • Estado de la respuesta, headers y cuerpo
  • Duracion en milisegundos
  • Numero de intento
  • Mensaje de error (si fallo)

Idempotencia

Tu endpoint puede recibir el mismo evento mas de una vez (ej. si tu servidor responde lentamente y Nexor reintenta). Usa el delivery_id o event_id para deduplicar en tu lado:
Tip: Para uso en produccion, almacena los valores de event_id procesados en una base de datos o cache (ej. Redis con TTL) en lugar de un Set en memoria.

Pruebas

Usa el boton Test en el panel de webhooks para enviar un payload de prueba a tu endpoint. Los payloads de prueba tienen "test": true en el cuerpo para que puedas distinguirlos de los eventos reales.
Última modificación el 17 de junio de 2026