Delivering Webhook Notifications
A Webhook notification is the object delivered when an event is triggered, and notifications have data payloads that contain references to the Intercom objects associated with the event.
Every webhook payload is slightly different, but they do share a number of common fields which will help you identify the type of notification you have received, when the event took place and more. You can find a more detailed description here
There may be instances when we pause, suspend or delay delivery of notifications, so let's take a look at how we handle these scenarios.
Paused subscription notifications
If your endpoint URL responds with more than 1000 consecutive HTTP error codes in a 15-minute window, we pause your Webhook topic notifications for 15 minutes after which we start sending as normal again.
If your endpoint URL responds with HTTP error codes for more than seven days, we suspend your Webhook subscription, and you will stop receiving any further notifications.
If we suspend your subscription, we display an error banner on the Webhooks page under the Configure menu of the relevant App in your Developer Hub.
After resolving any issues with your server, you can resume suspended subscriptions by pressing Set live from the top right of the page.
We only suspend Webhook subscriptions for Private apps. Webhook subscriptions used in Public apps are never suspended.
We will prioritise the first 150,000 events per minute of your Webhook topic notifications and then rate limit all further notifications with a lower priority.
Slow topic notifications
We prioritise Webhook topic notifications for endpoint URLs that successfully respond within 500ms. If response times exceed 500ms, we deliver topic notifications with a lower priority.
If we receive an HTTP 429 (Too Many Requests) response from your endpoint URL, we throttle further notifications with a delay that starts at 1 minute and extends to 2 hours. We drop any throttled notifications if we do not receive a successful response within 2 hours.
When you receive a notification, you should check the timestamp in the
created_at field to confirm when the action took place. This will allow you to determine the right action to take in your App, as we do not offer any guarantee on the order of Webhook topic notifications.
Because we want to be sure your app has received a notification, we will resend it if we do not receive a HTTP 200 (OK) response from your endpoint URL within 5000ms. This means you may receive duplicate notifications if your response takes longer than 5000ms to reach our servers.
To avoid this, we recommend responding with HTTP 200 (OK) immediately upon receipt and before you trigger any long-running tasks.
If Intercom's System Status interrupts notification delivery, we will store them and resume sending once we restore the service. We will always prioritise the most recent notifications and process older delayed notifications with a lower priority.
Ensuring delivery behind a firewall
If the endpoint you configure is behind a firewall, you must add the IP addresses Intercom sends Webhook Notifications from to your allow list. If you do not, you will not receive any notifications.
The IP addresses Intercom sends Webhook Notifications from are:
Updated about 1 month ago