Skip to main content

Acknowledging deliveries

Your endpoint must respond with a 2xx status code within 30 seconds to acknowledge receipt. Any other status code or a timeout is treated as a failure.

Retry policy

With the default configuration, Nexor makes at most three total delivery attempts: If the third total attempt fails, the delivery is marked as failed and no more attempts are made. Retries are only triggered for:
  • 5xx server errors
  • 429 rate limit responses
  • Timeouts with no response within 30 seconds
  • Network errors, such as a refused connection or DNS failure
Other 4xx errors are not retried because they indicate a request that the receiving endpoint rejected.

Webhook health and auto-disable

Nexor tracks consecutive terminal delivery failures for each webhook:
  • After 5 consecutive failures, its health changes to degraded.
  • After 20 consecutive failures, its health changes to failing.
  • After 100 consecutive failures, Nexor disables the webhook.
A successful delivery resets the failure counter and health to healthy. Re-enabling a disabled webhook from the dashboard also resets both values.

Delivery logs

Every delivery attempt is visible in the dashboard. Open a webhook to review its deliveries. Each entry includes:
  • Request URL, headers, and body
  • Response status, headers, and body
  • Duration in milliseconds
  • Attempt number
  • Error message, when present

Idempotency

Your endpoint may receive the same event more than once if Nexor retries it. The delivery_id changes on every attempt, while the event_id identifies the original event. Use event_id to deduplicate processing: Run the handler only after middleware has verified X-Nexor-Signature against the exact raw request body and your signing secret, as described in Verifying signatures. Reject an invalid signature before reading event_id or claiming the event.
Implement claim, complete, and release with a durable database or cache. The claim must be atomic so two simultaneous deliveries cannot both start processing. Give each in-progress claim an expiring lease so a later retry can reclaim it if the process stops before releasing it. Fence complete and release with the claim’s owner token so an expired worker cannot modify a newer claim. Renew that same claim before its lease expires if processing can run longer. Mark an event as completed only after its work succeeds, and make the work itself safe to repeat in case the process stops between the external side effect and the completion record.

Testing

Use the Test action in the webhook dashboard to send a sample payload to your endpoint. Test payloads contain "test": true so you can distinguish them from real events.
The current test generator does not reproduce every production payload exactly. It cannot generate meeting.created or meeting.updated, and its sample actor and host fields differ from the production schemas on these pages. Build and validate your receiver against the documented production payloads, not only against a dashboard test.
Last modified on September 7, 2026