Static IP for Vapi.ai Voice Agents: Fix Firewall Blocks on Custom LLM and Webhook Traffic

Vapi.ai voice agents use dynamic IPs for nearly all outbound traffic. Custom LLM calls, webhooks, media streams. All dynamic. If your enterprise firewall requires IP allowlisting, that's a problem. Here's how to give your Vapi integration a fixed, allowlistable identity using a static IP proxy.

Vapi Publishes Two Static IPs. They Cover Almost Nothing.

Vapi documents two static IPs for SIP signaling: 44.229.228.186 and 44.238.177.138. That's it. Those cover SIP only.

Everything else is dynamic:

• Custom LLM API calls (when Vapi hits your self-hosted model)
• Server URL webhooks (assistant-requested, end-of-call reports, status updates)
• RTP/SRTP media streams
• Any outbound HTTP request Vapi makes on your behalf

Vapi's own recommendation is to use domain-based whitelisting or token authentication instead of IP allowlisting. That works for some setups. It doesn't work when your security team requires IP-based firewall rules. And in healthcare, finance, or government environments, that's not negotiable.

The Same Firewall Problem We've Solved Since 2013, New Platform

The Vapi community forums have active threads from developers stuck on exactly this. One thread asks directly for egress IP ranges for custom LLM API calls. Another reports that even after allowlisting Vapi's SIP IPs, media traffic (SRTP/RTP) still gets dropped because the media servers use a completely different, undocumented IP pool.

The pattern is the same every time. Developer builds voice agent. Connects it to a custom LLM or webhook behind a corporate firewall. Firewall blocks the connection. Developer asks Vapi for static IPs. Answer: there aren't any.

Voice agent platforms are moving fast, but the networking layer hasn't caught up. Vapi, Bland, Retell. They all run on dynamic cloud infrastructure because that's how you scale voice. But the enterprises buying voice agents still run firewalls that need a fixed IP on the allowlist. It's the same tension QuotaGuard has been solving for over a decade across Heroku, AWS, Render, and dozens of other platforms. Different application layer, identical network problem.

Two Traffic Directions, Two Solutions

Vapi integrations have traffic flowing both ways. Each direction has a different fix.

Outbound: Your Server Calling the Vapi API

If your backend calls Vapi's API to create calls, manage assistants, or pull transcripts, and your corporate firewall restricts outbound traffic to known IPs, route those calls through a QuotaGuard static IP proxy.

This is the standard pattern. Set the HTTPS_PROXY environment variable, or configure your HTTP client to use the proxy URL. Every outbound request from your server to api.vapi.ai goes through QuotaGuard's fixed IP. Your firewall sees a known egress address. Done.

Node.js example using https-proxy-agent:

const { HttpsProxyAgent } = require('https-proxy-agent');
 
const agent = new HttpsProxyAgent(process.env.QUOTAGUARDSTATIC_URL);
 
const response = await fetch('https://api.vapi.ai/call', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${process.env.VAPI_API_KEY}`,
    'Content-Type': 'application/json',
  },
  agent,
  body: JSON.stringify({
    assistantId: 'your-assistant-id',
    phoneNumberId: 'your-phone-number-id',
    customer: { number: '+15551234567' },
  }),
});

Python example:

import os
import requests
 
proxies = {
    'https': os.environ['QUOTAGUARDSTATIC_URL'],
}
 
response = requests.post(
    'https://api.vapi.ai/call',
    headers={
        'Authorization': f'Bearer {os.environ["VAPI_API_KEY"]}',
        'Content-Type': 'application/json',
    },
    proxies=proxies,
    json={
        'assistantId': 'your-assistant-id',
        'phoneNumberId': 'your-phone-number-id',
        'customer': {'number': '+15551234567'},
    },
)

Inbound: Vapi Calling Your Endpoint

This is the harder direction and the one most Vapi developers are struggling with. When Vapi calls your custom LLM endpoint or server URL webhook, those requests come from Vapi's dynamic IP pool. You can't tell Vapi to route through your proxy. Vapi controls that connection.

The fix is to put a QuotaGuard ingress endpoint in front of your backend. Instead of giving Vapi your server's direct URL, you give it a QuotaGuard endpoint that forwards traffic to your actual server. Your firewall only needs to allowlist QuotaGuard's known static IPs.

The flow looks like this:

Vapi (dynamic IP) → QuotaGuard endpoint (static IP) → Your custom LLM / webhook server

Your firewall allowlists QuotaGuard's IPs. Vapi's dynamic IPs never touch your firewall directly. When Vapi's infrastructure scales and IPs rotate, nothing breaks on your end.

In your Vapi assistant config, you'd point the server URL to your QuotaGuard ingress endpoint instead of your backend directly:

{
  "assistant": {
    "serverUrl": "https://your-qg-ingress.quotaguard.com/vapi-webhook",
    "model": {
      "provider": "custom-llm",
      "url": "https://your-qg-ingress.quotaguard.com/v1/chat/completions"
    }
  }
}

The exact ingress setup depends on whether you're using QuotaGuard Static or Shield, and how your backend is configured. Talk to our engineering team if you're setting this up for the first time. We'll walk you through it.

When to Use Shield Instead of Static

QuotaGuard Static routes your traffic through a shared static IP. For most Vapi integrations, that's all you need.

QuotaGuard Shield adds SSL passthrough. The encryption handshake happens directly between the two endpoints. QuotaGuard routes the traffic but never holds the decryption keys. The payload stays encrypted end to end.

For voice agents, this matters more than you might think. Voice traffic carries conversation transcripts, customer phone numbers, and potentially sensitive business data. If your Vapi agent handles patient intake for a healthcare provider, or collects payment details for a financial service, that payload is regulated.

Use Shield when:

• Your voice agent processes PHI (HIPAA) or payment data (PCI-DSS)
• Your compliance team requires proof of end-to-end encryption for all proxy hops
• You're in a regulated industry and your auditors will ask about the proxy layer

Use Static when:

• You need a fixed IP for firewall allowlisting and the traffic isn't regulated
• Your Vapi agent handles internal workflows, scheduling, or non-sensitive automation
• Cost matters and you want the simplest setup

What This Doesn't Solve

Honest caveats.

RTP/SRTP media streams. Voice media uses UDP, not HTTP. QuotaGuard proxies HTTP and HTTPS traffic. If your firewall is blocking Vapi's media streams specifically, a static IP proxy won't help with that traffic. You'll need to work with Vapi's SIP IPs and your telephony provider's media port ranges. The proxy solution covers API calls, webhooks, and custom LLM traffic. Not raw media.

Vapi Cloud latency. Adding a proxy hop adds latency. For voice agents, latency matters. Our infrastructure typically adds less than 20ms when you pick a region close to your server. For API calls and webhooks, that's negligible. But if you're routing real-time LLM inference through the proxy and your model is already slow, that 20ms compounds. Test it.

Vapi's own proxy guide is different. Vapi publishes a proxy server guide in their docs. That guide is about hiding your API key by routing Web SDK calls through your backend. It's a security pattern for frontend apps. It's not about static IPs or firewall allowlisting. Different problem, different solution.

Get a Static IP for Your Vapi Voice Agent

QuotaGuard has been solving the static IP problem for cloud platforms since 2013. Voice agents are newer, but the networking challenge is the same one we've handled for thousands of customers across Heroku, AWS, Render, n8n, and dozens of other platforms.

Static plans start at Micro/month for shared IPs. Shield plans add SSL passthrough for regulated traffic. Dedicated IPs are available on Enterprise plans at /month for teams that need a completely isolated address.

See pricing and start a free trial here.