Webhooks
A webhook represents a service destination, where an incoming notification can be consumed programmatically. For example, an incoming notification about an event can trigger a webhook destination to a backend microservice to act based on the content of the incoming notification. You can allowlist the ranges of IP addresses to restrict access to your servers that receive webhooks.
Regardless of the location of the Event Notification Service instance, to ensure uninterrupted webhook traffic you should add the IP ranges of all regions to your allow list.
Configuring a webhook destination
You can configure a webhook destination in the Destinations tab. As part of the configuration, enter the webhook URL, and the REST API verb to be called when the webhook is called. You can also enter authorization headers to the
destination webhook. Create a subscription to associate the webhook destination to a topic.
Webhook signing
To identify that the incoming notification is coming from IBM Cloud Event Notifications, you can enable webhook signing. If signing is enabled, a public key can be downloaded, and used to decrypt the incoming notification content.
Webhook retry policy
When calling a webhook, issues such as network errors and application glitches can cause the requests to fail. A retry is used to provide resiliency to external requests. Attempt to retry the requests in such situations by using the following values:
- Limit = 60 seconds: total time that the service retries.
- Step = 5 seconds: after each failure, the service waits 5 seconds before retrying. This delay prevents bombarding of the external services (webhook).
In addition, the following timeout conditions cause the webhook call to fail:
- A connection timeout of 10 seconds
- A response timeout of 60 seconds
If a call to the webhook URL fails even after retry attempts, the notification is lost.