Next Tuesday, February 24th at 5am CT, we will be rolling out improvements to our webhook delivery infrastructure to improve reliability, consistency, and observability. These changes are internal and do not require any action from our customers. We are not anticipating any downtime as part of these changes.

Reason for update

We are updating how our webhooks are dispatched in order to improve:

• Delivery reliability
• Retry consistency
• Delay handling
• Failure tracking and observability

These updates should help resolve known issues related to webhook delays and retry behavior.

Timeout Policy Update

Webhook timeout has been updated to:

• 15 seconds

If your endpoint does not return an HTTP 200 response within 15 seconds, the delivery attempt will be considered failed and will automatically initiate a retry flow.

Retry Strategy

When a webhook delivery fails, we will try sending it again a few extra times using the schedule below:

• 1st retry: 15 minutes
• 2nd retry: 30 minutes
• 3rd retry: 1 hour
• 4th retry: 4 hours
• 5th retry: 8 hours
• 6th retry: 11 hours

With this new retry policy, webhook delivery attempts will occur over a 24-hour period. If all retry attempts fail, the webhook will be marked as permanently failed.

Webhook Request Format

The webhook payload and headers structure will remain consistent with the current format. However, internal delivery handling has been improved to ensure more predictable and stable behavior.

Recommended Best Practices

To ensure successful webhook processing, we recommend the following best practices:

• Respond with HTTP 200 as soon as the webhook is received and validated
• Avoid long synchronous processing inside the webhook endpoint
• Process webhook payloads asynchronously when possible

UAT Release

These changes are already available in our UAT environment in case you want to test them.