Webhooks are notifications about QuickBooks entities that are sent to developer-created applications. For example, if you wish to be notified when a customer's information changes, you configure a specific endpoint that QuickBooks can call for this event with the details of the change. When webhooks is active, data for the requested event is aggregated and then sent in a periodic notification to your API. Once you have configured webhooks, you will receive event notifications for all companies your app is connected to.
You can enable webhooks on a per-app basis via the Webhooks tab. Note that there are two webhooks sections: webhooks for development and webhooks for production. The former is for testing on your development setup, while the latter is for use with your app once it has been released to production. Make sure to configure both appropriately.
- From your My Apps dashboard, click the app you wish to configure.
- Click Webhooks.
- Enter your endpoint URL in the field provided. This URL must be exposed over the internet and be secured via HTTPS.
Note: Make sure that your specified domain has intermediate certificates installed to complete the chain of trust. Self-signed certificates are not supported.
- Check the events desired (or Select All to enable all of them). Each option can be expanded using the drop-down arrow on the right, allowing you to specify exactly which resource should trigger webhooks.
- Click Save. It may take up to five minutes for your endpoint to receive its first notification.
Once you have configured the webhooks endpoint, you can modify or delete it using the buttons shown at the far right.
When you are testing your webhooks with your app, you must configure webhooks in the sandbox environment. Your app must have gone through OAuth flow and authorization with a sandbox company before events will be received. Once you are ready to go to production, you must configure webhooks again on the production side.
- Reliability: In order to compensate for the possibility of missed or dropped packets, make a ChangeDataCapture (CDC) call for each entity received up to the last notification time (as shown in sample app) upon receipt of new notification. You can additionally make a daily CDC call for all entities to ensure that your database is consistently up to date.
- Respond promptly: Your endpoint should respond within three seconds; otherwise, the transaction will time out and be retried. To make sure you can always respond quickly, do not process the notification payload or perform complex operations within the webhooks endpoint implementation. It is a good idea to do the processing on a separate thread asynchronously (as shown in the sample apps listed below) using a queue.
- Manage Concurrency: Event notifications are sent for each realmID at a time. When there are multiple changes happening rapidly, your app may receive notifications frequently. Care should be taken to process the queue linearly to avoid processing the same changes more than once.
- Notification Ordering: While we make all effort to send the events in order, it is possible to receive an older event in a subsequent notification. The event timestamp field in the notification payload is always the source of truth for when an event has occurred.
- Retry Policy: If the endpoint is down, we will retry progressively (first time after 20 minutes, then again after 30 minutes, and a third time after 50 minutes) and finally drop the message and blacklist the endpoint if it is still down. The endpoint will become inactive after one day.
Refer to the following links for sample webhooks implementations.