If your webhook consumer endpoint fails to accept a delivery or returns a retriable error status (anything other than a 2xx response), Paxos will automatically attempt to retry the webhook delivery.
We use an exponential backoff policy with jitter (randomization to avoid retry storms) with the following schedule:
Initial retry delay: ~5 seconds after initial failure
Subsequent retries: Increasing intervals with exponential backoff
Maximum retry duration: 24 hours from the time the event was first invoked
Paxos will continue retry attempts for up to 24 hours from the initial attempt, unless delivery succeeds. After this period, no additional retry attempts will be made.
To ensure optimal performance and stability, Paxos implements rate limits on webhook deliveries.When configuring a webhook via the Dashboard, you can set the rate limit from 1 to 100 requests per second. The default is 10 requests per second.
Respond quickly: Your webhook endpoint should acknowledge receipt with a 2xx status code as quickly as possible (ideally < 500ms)
Process asynchronously: Acknowledge the webhook immediately, then process the event asynchronously in your application
Implement idempotency: Design your webhook handlers to be idempotent in case the same event is delivered multiple times
Monitor delivery failures: Implement monitoring for webhook delivery failures to detect issues early
Implement backup polling: Establish a periodic job that polls the Events API as a fallback mechanism for missed webhook events
Ignore test events: You may wish to test the functionality of your webhook consumer endpoint by sending test events. To ignore test events, you can filter on the is_test=false field in your webhook consumer.