Encompass Webhooks: Replacing SDK Polling with Events That Don't Get Missed
Most SDK-era automation is secretly a polling loop. Query the pipeline every five minutes, compare against last time, act on the difference. It worked, but it was always the expensive way: minutes of latency, constant load, and a diff engine you had to write yourself.
The API stack inverts the model. With Developer Connect, you subscribe to webhook events and Encompass calls you when something changes — a loan created, a milestone finished, and with field-level change events, the moment a field you care about gets a new value. ICE’s own migration guidance is explicit that converting SDK logic means shifting to event-driven architecture via webhooks, not re-implementing your polling loop over REST.
Here’s how to do the shift properly.
The shape of the system
A webhook integration has three parts:
- A subscription — you register which resources and events you want and the HTTPS endpoint to deliver them to.
- A notification — when the event happens, Encompass POSTs a payload to your endpoint telling you what changed.
- A follow-up API call — your service fetches the details it needs via Developer Connect and does its work.
That last step matters: treat the webhook as a doorbell, not a delivery. Design your consumer to be told “loan X changed” and then pull the current truth from the API — rather than trusting whatever state was attached to the notification. That one decision makes duplicate and out-of-order deliveries (which any distributed system will occasionally produce) harmless: processing the same doorbell twice just means reading the same current state twice.
Field-level triggers without a plugin
The SDK pattern lenders miss most is the field trigger — plugin code that fired when a specific field changed. Enhanced field-change events are the API-era answer: notifications scoped to changes in the fields you care about, so “when the lock status flips, do X” no longer requires desktop code running on every user’s machine. It runs once, server-side, in your consumer.
Building a consumer that doesn’t lose events
The difference between a demo webhook and a production one is what happens on a bad day:
- Acknowledge fast, process async. Return success immediately and hand the event to a queue. A consumer that does its real work inside the HTTP handler will time out during bursts — and bursts are exactly when the interesting things are happening.
- Verify the source. Validate that notifications actually come from Encompass (signature/secret verification per the platform’s mechanism) before acting on them. An endpoint that trusts any POST is an integration anyone on the internet can drive.
- Make processing idempotent. Deliveries can repeat. Key your side effects to the event or loan state so a duplicate is a no-op, not a duplicate disclosure order.
- Queue with a dead-letter lane. When processing fails, the event goes somewhere a human can see, not into a retry loop that hammers a broken dependency forever.
- Reconcile on a schedule. Even a perfect event pipeline deserves a nightly sweep that compares expected state against the pipeline via the API. Polling doesn’t disappear — it retires to a once-a-day audit job, which is the workload it was always right for.
What this replaces from your inventory
If you’ve audited your SDK usage, the rows that become webhook consumers are easy to spot: anything described as “watches for,” “checks every N minutes,” or “runs when a loan hits milestone X.” In the SDK-to-API component map, those rows all point here — and they usually consolidate. Five polling jobs typically collapse into one event consumer with five handlers, which is one deployment to monitor instead of five schedules to babysit.
Latency improves from minutes to seconds. Load on your instance drops. And the “we missed one” class of bug — the loan that changed twice between polls — goes away structurally, because you’re no longer sampling a moving target.
We build these consumers as part of SDK migrations and API integration projects — queue, retries, monitoring, and reconciliation included, not extra.