Retries and delivery
How ChatBeds sends webhooks, what counts as delivered, the retry schedule, and how to handle repeats and order.
ChatBeds sends each webhook as soon as the booking changes. If your server does not take it, ChatBeds keeps trying for about two days.
What counts as delivered
A delivery succeeds when your server answers with a 2xx status within 10 seconds. Everything else is a failure and is tried again:
- any other status, including
3xx(redirects are not followed), - no answer within 10 seconds, a refused connection, or a TLS error,
- an address that no longer points at the public internet. The address is checked again before every send.
Answer first and do the work afterwards: put the event on a queue and return 204. Anything slow (calling the API back, sending emails) belongs after the answer.
The retry schedule
A delivery is tried at most 8 times. After a failure, the next try waits at least:
| After try | Wait |
|---|---|
| 1 | 1 minute |
| 2 | 5 minutes |
| 3 | 30 minutes |
| 4 | 2 hours |
| 5 | 6 hours |
| 6 | 12 hours |
| 7 | 24 hours |
Retries are sent by a job that runs every hour, so a retry can come up to an hour later than the wait above. After the 8th failure the delivery is given up. Every try is signed again with a fresh timestamp.
A delivery is also given up at once if the key is revoked, the app is disconnected, or the webhook address is removed.
Repeats
You can receive the same delivery more than once: a retry after your server took it but answered too slowly, for example. Each delivery has one ID, the same on every try:
- the
ChatBeds-Deliveryheader, - the
idfield in the body.
Store the IDs you have handled (a week is plenty) and skip any you have seen.
Order
Deliveries are not guaranteed to arrive in order. A retry of an old event can arrive after a newer one. To keep your copy right:
- Compare
data.reservation.updated_atwith what you have, and ignore anything older. - Or treat a webhook as a nudge: fetch the booking with
GET /reservations/{id}and use what that returns.
Watching deliveries
- Private keys: Settings → Partner API shows the recent deliveries for each key, with their status and last error.
- Apps: your app's page in the developer console holds its webhook address. Log the
ChatBeds-DeliveryID of every request you receive.
When your server was down
If you were down for longer than the retry schedule covers, some events are gone. Catch up by searching: Keep in sync shows how.
| Throughput | |
|---|---|
| Sends at once | Up to 8 deliveries in parallel, across all endpoints |
| Timeout | 10 seconds per try |
| Retries | 7, over about 2 days |
Building something?