Webhook retry strategy

Our webhook system implements a robust retry mechanism to ensure reliable delivery of notifications. When a notification cannot be successfully delivered to your endpoint, the system automatically initiates a retry sequence with exponential backoff intervals.

Delivery Confirmation

Successful delivery is confirmed when your endpoint responds with a 2xx HTTP status code. Any other response code triggers our retry mechanism. The system will make up to 11 retry attempts before deactivating the subscription.

Retry Schedule

The retry mechanism follows an exponential backoff pattern, with increasing intervals between attempts:

Subscription Deactivation

After the 11th unsuccessful retry attempt:

• The subscription is automatically deactivated
• A final deactivation email is sent
• No new notifications will be sent for this subscription
• Pending notifications are stored for future delivery

Handling Deactivated Subscriptions

When a subscription is deactivated:

• All notifications that occurred before deactivation are preserved
• These notifications will be sent once the subscription is reactivated
• Any new events that occur during deactivation will not trigger notifications
• The subscription must be reactivated to resume receiving notifications

Email Notifications

Configuration

Email notifications for delivery failures are optional and can be configured per subscription. You can set up email notifications:

• During initial subscription setup
• By updating an existing subscription

Notification Content

Each email notification includes:

• Subscription ID
• Status code received from your endpoint
• Error message (if available)
• Timestamp of the failure

Notification Schedule

The system sends three types of email notifications:

1. First warning email after ~3 hours and 40 minutes of failures
2. Second warning email after ~45 hours and 40 minutes of failures
3. Final deactivation email after the 11th retry attempt

Technical Considerations

📘

Important Note

The rowVersion is updated with each retry attempt. This means that if a retry occurs between a GET and PUT operation (for example, while editing the endpoint URL), the PUT operation will fail.