Scope
At which rate can we expect the webhook calls in Chargebee?
Ex- events Like SUBSCRIPTION_CHANGE, SUBSCRIPTION_STARTED and SUBSCRIPTION_CREATED
Summary
The renewal and the corresponding webhooks are async which will be processed in batches in a thread pool model and usually be completed within a couple of minutes. There shouldn't be performance disruption based on this. We generally don't recommend handling time-critical operations using webhooks and they can make use of the events API to handle such cases.
Solution
Webhook Timeouts
There are 3 timeouts for Webhooks in Chargebee:
Connection Timeout: The connection timeout is the timeout for making the initial connection to the webhook URL's HTTP server.
Read Timeout: Once the initial connection has been made, at any time there is a possibility that there is an indefinite wait to read data from the HTTP server. The read timeout is the timeout for such a wait.
Total Webhook Timeout: In addition to the above timeouts, Chargebee also checks the total execution of time of any webhook call via the webhook execution timeout.
Automatic Retries
Webhook execution can fail due to timeouts or errors. For each event whose webhook call fails, the calls are retried up to 7 times based on the following schedules:
Retry | Time |
1 | 2 minutes after the failure |
2 | 6 minutes after the previous retry |
3 | 30 minutes after the previous retry |
4 | 1 hour after the previous retry |
5 | 5 hours after the previous retry |
6 | 1 day after the previous retry |
7 | 2 days after the previous retry |
Note: You could resend a webhook call manually if you wish to sync your data immediately. Go to Logs › Events and open the page for the chosen event. On the right side, you will have the option to select the webhook and resend the same.
Duplicate Handling
Due to webhook retries, it's possible that your application receives the same webhook more than once. Ensure the idempotency of the webhook call by detecting such duplicates within your application. This can be done by examining theid parameter since its value is unique to an event and thus identifies it.
Out-of-Order Delivery
Webhooks can also arrive at your application out-of-order. This can be due to issues such as network delays or webhook failures. However, you can determine the order of the events by examining the resource_version attribute of the resource sent by the webhook. resource_version is incremented once for every change made to the resource.
Handling Webhooks
Chargebee needs to get a status code 2XX reply from the configured URL to confirm that the notification sent via HTTP POST has been successfully delivered. If any webhook times out, Chargebee will cancel and retry. Up to 7 retries happen for every webhook that fails and at exponential time intervals.
How does API be an alternative to Webook?
Webhooks are asynchronous and are not recommended for time-critical applications. It is very much possible and even likely that webhooks reach your application out-of-order and that they get duplicated. For time-critical applications, we recommend using the list events API to poll our system for events.
Chargebee supports multiple API versions. The event content sent to the webhook is structured based on the API version selected. Hence it is crucial that the API version of the webhook matches the API version of the client library used by your application server. Learn more about API versioning here.
Note: If you use API v1 and plan to upgrade to v2, ensure that you transition your webhooks too. Take a look at the API v2 Upgrade Guide for more detailsRelated Articles