Encompass's New Webhook IPs Go in Your Firewall. Your Lender Calls Need a Static Egress IP

Two different Encompass IP problems get confused constantly. One is inbound: ICE is changing the source IPs its webhooks come from, and you have to update your firewall. The other is outbound: your integration calls into a lender's Encompass instance that only accepts traffic from known IPs. They point in opposite directions. A proxy fixes one of them, and it isn't the webhook one. Let's split them apart.

Encompass's New Webhook Source IPs Belong in Your Firewall Allowlist

Encompass Developer Connect is migrating the source IP ranges its outbound webhooks send from. If you receive webhooks from ICE, your firewall or security group has to allow the new ranges before the cutover, or delivery breaks.

The two new ranges are 158.224.116.0/24 and 158.224.118.0/24. Add both to the allowlist that fronts your webhook receiver. The migration is additive: ICE keeps the existing 2023-era ranges whitelisted during the transition, so you don't remove anything yet. You add the new ranges alongside the old ones and keep both live until the cutover completes.

The timeline ICE has published works in two stages:

• UAT migrates to the new source ranges in mid-October 2026.
• Production migrates in mid-November 2026.
• Integrators need the new ranges in their allowlist by October 31, 2026.

There's a second, separate allowlist on ICE's side. ICE allow-lists your webhook destination domain, not its IP, through a support ticket. That's a one-time registration of where your endpoint lives, handled by ICE support. It's unrelated to the source-IP change above. Confirm the exact dates and both allowlisting steps against ICE's current Developer Connect documentation before you schedule the work, since ICE owns this timeline and can adjust it.

The Webhook Fix Stays a Simple Firewall Allowlist

Here's the honest part, because it's where people waste a week. The IPs that are changing belong to ICE, the sender. They don't belong to you, the receiver. Putting a static-IP proxy in front of your webhook endpoint does nothing to change which IPs ICE sends from, so it can't remove the need to allowlist 158.224.116.0/24 and 158.224.118.0/24.

QuotaGuard's inbound static IP works the other way around. It gives your own service a fixed, known IP so that a third party can allowlist you. That's useful when you're the one being filtered. It's the wrong tool for the webhook migration, where ICE is the one whose IPs moved. The correct fix for the webhook change stays boringly simple. Add ICE's two new /24s to your firewall, keep the old ranges until cutover, and you're done. Don't overthink it, and don't reach for a proxy to solve it.

QuotaGuard does have a real place in the Encompass picture. It's just on the other side of the connection.

QuotaGuard Fits When Your Integration Calls Into an IP-Restricted Lender Encompass

Lenders can turn on IP-based access restrictions for their Encompass instance. When a lender does that, their instance only accepts API traffic from IP addresses they've approved. Now flip to the vendor's seat. If you build a LOS, POS, AMC, or doc-prep integration that runs on cloud infrastructure, your outbound IP is dynamic. It changes on deploys, restarts, and autoscaling events. A lender can't allowlist an address that keeps moving.

This is the standard outbound static-IP problem, and it's exactly what QuotaGuard is for. QuotaGuard is a proxy. Your integration sends its Encompass Developer Connect API calls through QuotaGuard, and the lender sees one of your two fixed IPs on every request. You hand the lender those two IPs once, they allowlist them, and your traffic keeps passing even as your underlying cloud hosts churn.

The Encompass Developer Connect API is OAuth token-based and cloud-native, so nothing about the auth flow changes when you route through a proxy. You still fetch a token and send it as a bearer credential. The proxy only changes the IP the lender sees.

Route Your Encompass Developer Connect Calls Through a Static IP in 2 Minutes

Setup is one environment variable and a proxy config on your HTTP client. Add the connection URL to your environment:

QUOTAGUARDSTATIC_URL="http://username:password@us-east-static-01.quotaguard.com:9293"

Then point your Encompass calls at it. In Node.js, using the Developer Connect API base host from ICE's own API reference rather than a guessed path:

const axios = require("axios");
const { HttpsProxyAgent } = require("https-proxy-agent");
const httpsAgent = new HttpsProxyAgent(process.env.QUOTAGUARDSTATIC_URL);

// Use the Developer Connect base URL and resource paths from ICE's API reference.
const ENCOMPASS_API_BASE = process.env.ENCOMPASS_API_BASE;

await axios.get(`${ENCOMPASS_API_BASE}/...`, {
  headers: { Authorization: `Bearer ${accessToken}` },
  httpsAgent,
  proxy: false,
});

Every subscription includes two load-balanced static IPs. Give the lender both, so a request served by either one passes their restriction. The example host above is region-specific. You pick your region at sign-up, so choose the one closest to the lender's Encompass region, and changing it later means contacting QuotaGuard support. QuotaGuard runs this on AWS infrastructure.

One architectural note worth stating plainly: the direction is what matters. A static egress IP solves lender IP restrictions because it fixes the address you send from. It does not, and cannot, solve the inbound webhook migration, because that's ICE's sending address, not yours. Same product, opposite problem.

Mortgage Data Through Shield Keeps the Payload Encrypted End to End

Loan files are regulated financial data and PII. Borrower names, Social Security numbers, income, and account details move through these calls, which puts your integration under GLBA-style handling obligations and, usually, a SOC 2 review from the lenders you serve.

QuotaGuard Static uses a standard CONNECT tunnel on outbound HTTPS. It reads the destination host to route the connection and doesn't decrypt your payload. For many integrations that's fine. But when the data is this sensitive and a vendor questionnaire asks whether any intermediary can see it in transit, use QuotaGuard Shield instead. Shield uses SSL passthrough, so the TLS connection runs end to end between your integration and the lender's Encompass instance, and QuotaGuard doesn't decrypt your data in ordinary operation. You stay responsible for whether your full architecture meets PCI-DSS, GLBA, or your own SOC 2 controls, but Shield removes the proxy itself as a decryption point. The setup is identical, with QUOTAGUARDSHIELD_URL in place of the Static variable and port 9294.

QuotaGuard Static Pricing Starts at $19/Month

Bandwidth is bundled. No per-GB overage fees. A mortgage integration calling into a handful of lender instances moves modest volume, so the entry tier covers most vendors. Dedicated IPs are available on Enterprise and above. On lower tiers, your two assigned IPs are still static, but shared with other customers.

QuotaGuard Shield Pricing Starts at $29/Month

Shield costs slightly more than Static at each tier because SSL passthrough adds routing overhead. For regulated loan data under SOC 2, PCI-DSS, or GLBA-style scrutiny, keeping the payload encrypted end to end is worth the difference. QuotaGuard never decrypts your data in ordinary operation.

All plans include a 3-day trial. Enterprise plans include a 7-day trial. Credit card required.

See the full pricing table at quotaguard.com/products/pricing.