Skip to main content

Confirmación de entregas

Tu endpoint debe responder con un código de estado 2xx 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
Los demás errores 4xx no se reintentan porque indican que el endpoint receptor rechazó la solicitud.

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.
Una entrega exitosa restablece el contador y la salud a 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. El delivery_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.
Implementa 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.
El generador de pruebas actual no reproduce todos los payloads de producción de forma exacta. No puede generar meeting.created ni meeting.updated, y sus campos de actor y host difieren de los esquemas de producción documentados en estas páginas. Construye y valida tu receptor con los payloads de producción documentados, no solo con una prueba del dashboard.
Última modificación el 7 de septiembre de 2026