Webhooks

Managing Webhook Subscriptions

Having Webhook Subscriptions is costly to our system. Improperly managed Webhook Subscriptions could cause millions of failed events. It is important that Webhook Subscriptions are properly managed. Therefore, keep the following in mind:

• When creating Webhook Subscriptions with multiple events, it is important to consider the use case(s) and action(s) taken on the Webhook Notification(s) received. If the action(s) taken are different for each event, then having multiple events in one Webhook Subscription is appropriate. However, if the action(s) taken is the same for all of the events, then the event needed may be a common event such as the Update event type on one Webhook Subscription.
• Webhook Subscriptions that are not used need to be removed.
• An application should never exceed 25 Webhook Subscriptions per Lender.
• For Loan Change Event Webhook subscriptions that have Filter attributes, it is recommended that if there is a separate workflow for each of the Fields in the Filter Attributes, then create separate Webhook subscriptions for each of the Fields. Cache those Subscription ID’s and when the Webhook notifications are received, get the specific workflow function on that specific Subscription ID for the cache store. The Subscription ID is in the Header of the Webhook Notification.
• Utilize the signing key encoded process to ensure that the notification being received is from ICE Mortgage Technology and the Lender. This process is documented in the Encompass Developer Connect portal (see Notification Signature in the Signing Keys page of Webhooks).

Subscribing to the Loan Change Webhook Event

• You cannot include more than 50 attributes as part of a single subscription, but you may add more than one “change” subscription.
• When delivering different subscriptions at different endpoints, the resource event and the endpoint combination must be unique.
• Upfront testing is required to ensure that the notifications are being posted to the right endpoint.