How to Get a Static IP for Webhooks

Webhooks fail in two directions when IPs are not fixed. When your app sends a webhook to a partner that allowlists source IPs, a rotating egress IP gets the POST rejected. When a provider sends a webhook to you and asks for a destination IP to allowlist on their side, an app behind a rotating address or a shared CDN has nothing stable to give them. A static IP proxy fixes both: your outbound POSTs exit from two fixed addresses, and inbound deliveries arrive at one permanent address that forwards to your app.

Use QuotaGuard Static for standard webhook traffic. Use QuotaGuard Shield when the payload is regulated (HIPAA, PCI-DSS, SOC 2), because Shield uses SSL passthrough and never decrypts your traffic at the proxy. This page covers both directions, the exact mechanism for each, how Static and Shield differ on encryption, and which webhook scenarios need a proxy at all.

Webhook Static IP: Outbound vs Inbound

Outbound gets most of the attention, but inbound is where hosting platforms leave the biggest gap. Many managed platforms have no native fixed inbound IP at all, which is exactly where a proxy earns its place.

Outbound Webhooks: Give Your Receiver One IP to Allowlist

When your application or automation sends webhooks to a partner whose firewall only accepts pre-approved source IPs, route those POSTs through the proxy. Every request exits from one of your two static IPs. The receiver allowlists both addresses once and verifies your webhook signature on each delivery. That combination, a known source IP plus a verified signature, is a solid authentication model.

If you send to several partners, you hand each of them the same two IPs. Adding a new partner integration needs no new infrastructure. The addresses never change, so an allowlist entry written today is still valid next year.

Inbound Webhooks: Give Providers One IP to Trust

When a provider, bank, or enterprise system needs to send webhooks to you and demands a fixed destination IP to allowlist on their side, the proxy becomes your stable front door. You point a hostname at the proxy's fixed inbound IP, give that IP to the providers sending you webhooks, and the proxy forwards each delivery to your app's current address. Your hosting platform can rotate underneath without your providers ever updating anything.

The two products handle the inbound TLS differently:

• Shield inbound routes by the TLS SNI hostname on port 443 and never decrypts the connection. Your certificate and private key stay on your servers. This is the model for regulated webhook payloads.
• Static inbound terminates TLS using a certificate you upload, so the proxy can receive HTTPS on your behalf and forward to your app.

One caution for Shield: because Shield reads the SNI hostname to route, hostnames and domains are visible to the proxy as routing metadata. Do not encode protected data in a hostname.

The Technical Mechanism

Outbound is an environment-variable change. Your app sends webhook requests through the proxy, the proxy forwards them from its fixed IPs, and the receiver sees a known source address.

# Set the proxy URL (example)
QUOTAGUARDSTATIC_URL="http://username:password@proxy.quotaguard.com:9293"

// Node.js: send a webhook from your static IPs
// node-fetch honors the agent option below; native fetch needs an undici dispatcher
const fetch = require('node-fetch');
const { HttpsProxyAgent } = require('https-proxy-agent');
const agent = new HttpsProxyAgent(process.env.QUOTAGUARDSTATIC_URL);
 
await fetch('https://partner.example.com/webhooks/orders', {
  method: 'POST',
  agent,
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(payload),
});

# Python: send a webhook from your static IPs
import os, requests
proxies = {"http": os.environ["QUOTAGUARDSTATIC_URL"],
           "https": os.environ["QUOTAGUARDSTATIC_URL"]}
requests.post("https://partner.example.com/webhooks/orders",
              json=payload, proxies=proxies)

Inbound is a DNS and certificate step rather than an environment variable. You point a hostname at the proxy's fixed inbound IP and hand that IP to your providers. With Shield the proxy passes the TLS connection through by SNI and never holds your keys. With Static you upload a certificate so the proxy can terminate TLS and forward to your app.

Static vs Shield: the encryption model

QuotaGuard Static routes outbound HTTPS through a standard CONNECT tunnel. The proxy reads the destination host and port to route the connection and does not decrypt your HTTPS payload. On inbound, Static terminates TLS using a certificate you provide, which means it can see HTTP-level details of the requests it receives on your behalf.

QuotaGuard Shield never decrypts in either direction. On inbound it routes by SNI on port 443 without terminating TLS. On outbound it carries the connection while your application's payload stays in a separate end-to-end TLS session the proxy does not read. That zero-knowledge model is the one to use for HIPAA, PCI-DSS, and SOC 2 webhook payloads. Static is appropriate for everything that is not regulated.

Webhooks on Your Platform

The setup depends on where your app runs and which automation tool sends or receives the webhook. These guides cover the common cases:

• Sending webhooks from a fixed IP: the full outbound walkthrough is in Sending Webhooks to Firewalled Endpoints.
• Automation senders: Zapier, Make, and n8n route their outbound webhook calls through your static IPs.
• Inbound webhook receivers: Netlify, Bubble, and Kubernetes use the inbound proxy to receive webhooks from partners on a fixed IP.

When You Need a Proxy for Webhooks

• Outbound, you need a proxy when a receiver allowlists source IPs and your platform rotates your egress address.
• Inbound, you need a proxy when a provider requires a fixed destination IP and your app has no stable public address to give them. Most managed platforms have no native answer here.
• You may not need a proxy for inbound if your platform already gives you a fixed public IP or hostname your provider will accept, and the payload is not regulated.

Regulated Webhook Data: Use Shield

If a webhook carries protected health information, payment card data, or anything under a SOC 2 control, the question is not only whether the IP is fixed, but whether anyone decrypts the payload along the way. QuotaGuard Shield uses SSL passthrough so your data is never decrypted at the proxy and your certificates never leave your servers. That is the model auditors expect for HIPAA, PCI-DSS, and SOC 2 workloads. A Business Associate Agreement is available for approved Shield configurations. QuotaGuard does not stand behind Static for regulated data, so route regulated webhooks through Shield.

FAQ

How do I send webhooks from a static IP?

Route your outbound webhook POSTs through QuotaGuard Static by setting one environment variable. Every request exits from your two static IPs. Give those two addresses to each partner to allowlist, and keep verifying your webhook signature on their side.

How do I give a provider a static IP to send webhooks to?

Point a hostname at the proxy's fixed inbound IP and give that IP to the provider. The proxy forwards each delivery to your app's current address, so the provider's allowlist stays valid even when your platform rotates underneath.

Can the proxy receive webhooks without decrypting them?

Yes, with Shield. Shield inbound routes by the TLS SNI hostname on port 443 and never decrypts the connection, so your keys stay on your servers. Use Shield for regulated webhook payloads.

Do I have to upload a certificate?

For Static inbound, yes. Static terminates TLS to receive HTTPS on your behalf, so you upload a certificate. For Shield inbound, no. Shield passes the connection through by SNI and never holds your keys.

How many IPs do I get?

Two, in a load-balanced pair with automatic failover. Add both to any allowlist. On Starter, Production, and Business the pair is shared with other customers; Enterprise gives you dedicated IPs.

Does inbound work if my app's IP keeps changing?

Yes. That is the point of the inbound proxy. Providers send to the proxy's fixed IP, and it forwards to wherever your app currently lives, so your deploys and scaling never break a partner's allowlist.

Static or Shield for webhooks?

Static for standard webhook traffic. Shield for regulated payloads (HIPAA, PCI-DSS, SOC 2), because Shield never decrypts your data at the proxy in either direction.