When working with QuickBooks Online webhooks, keep in mind the following best practices.
To compensate for the possibility of missed events, make a ChangeDataCapture (CDC) call for all required entities, dating back to the last known successfully processed webhook event for each entity.
Additionally, you can make a daily CDC call for all required entities to ensure your app has always processed the most up-to-date data.
You can see this in the example webhook implementations.
Your endpoint must respond to notifications with an HTTP 200 status within 3 seconds. When our webhooks delivery system does not receive a successful acknowledgement from your listener, we retry the failed event. The retry will happen at the following intervals: 10s, 20s, 30s, 5m, 20m, 2h, 4h, 6h, and then on stays at 6-hour intervals. You may not receive subsequent events from our system until you correctly acknowledge the first event.
To make sure your app can always respond quickly, don’t process the notification payload or perform complex operations within the webhooks endpoint implementation. Do the processing on a separate thread asynchronously using a queue.
Event notifications are sent one realm ID at a time. When there are multiple rapid changes, your app may get frequent notifications. Process the queue linearly to avoid processing the same changes more than once.
It’s possible to receive events out of sequence.
The timestamp field in the notification payload is always the source of truth for when events occur.