Give Airtable Automations a Static Outbound IP for Firewall Allowlisting

Route Airtable API calls through a middleware with QuotaGuard Static, and every outbound request leaves from a fixed IP your firewall can allowlist.

Airtable does not publish fixed outbound IP ranges for its Automations or API requests. The IPs rotate. Your firewall sees a different source address every time, and the allowlist rule that worked yesterday breaks today. Developers have been asking Airtable for a solution since at least 2021 with no official fix in sight.

The practical answer is to stop waiting and add a static IP at the network layer yourself.

Airtable Runs on Shared AWS IPs That Rotate Frequently

Airtable runs on AWS infrastructure. Its Automations and Scripting blocks share IP ranges with millions of other AWS workloads. Those ranges are large, frequently updated, and not something Airtable controls or documents per-customer.

If you're calling an internal API, a financial data provider, a healthcare system, or any endpoint that requires IP-based access control, you cannot allowlist Airtable's full AWS range. It's too broad and changes too often. You need a single, stable IP that belongs to your integration.

A Middleware Proxy Gives You a Fixed Egress IP in 2 Minutes

The architecture is straightforward. Your Airtable Automation or script doesn't call the protected API directly. It calls a small middleware service you control. That service routes the request through QuotaGuard Static. QuotaGuard forwards it from a static IP you've already allowlisted at the destination.

The middleware can be a lightweight function on Render, Railway, Fly.io, or any platform that supports environment variables. Here's a Node.js example using https-proxy-agent:

import { HttpsProxyAgent } from 'https-proxy-agent';
import fetch from 'node-fetch';

const proxyUrl = process.env.QUOTAGUARDSTATIC_URL;
// e.g. http://username:password@us-east-static-01.quotaguard.com:9293
// Pick the region closest to your destination API.

const agent = new HttpsProxyAgent(proxyUrl);

export async function forwardToProtectedApi(payload) {
  const response = await fetch('https://your-internal-api.example.com/endpoint', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(payload),
    agent,
  });
  return response.json();
}

Set QUOTAGUARDSTATIC_URL as an environment variable on your middleware host. Every request that runs through this function exits from the same QuotaGuard static IP. Allowlist that IP at your destination and you're done.

QuotaGuard tip: only proxy the calls that need allowlisting. Don't route all your middleware traffic through the proxy. It keeps latency low and makes debugging much easier when something goes wrong.

Airtable Scripting Blocks Route Through the Same Middleware

If you're using Airtable's Scripting extension rather than Automations, the same pattern applies. Your script calls your middleware endpoint via fetch(). The middleware handles the proxy hop. Airtable's script itself never needs to know about QuotaGuard.

// Inside an Airtable Scripting block
const response = await fetch('https://your-middleware.example.com/forward', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer ' + YOUR_MIDDLEWARE_SECRET,
  },
  body: JSON.stringify({ record_id: record.id, data: record.fields }),
});

const result = await response.json();
console.log(result);

Keep the middleware secret in an Airtable variable or hardcoded for internal tools. Don't expose your QuotaGuard credentials directly to the Scripting block.

Shield Is the Right Choice for Financial or Health Data

If the protected API you're calling handles healthcare records, payment data, or other regulated information, use QuotaGuard Shield instead of Static.

Shield uses SSL passthrough. The TLS connection runs end-to-end between your middleware and the destination. QuotaGuard routes the packets but never decrypts them. That matters for HIPAA, PCI-DSS, and SOC 2 compliance. You get the same fixed egress IP. QuotaGuard just never sees the plaintext.

The setup is identical. Swap QUOTAGUARDSTATIC_URL for QUOTAGUARDSHIELD_URL and update the proxy URL to use port 9294:

const proxyUrl = process.env.QUOTAGUARDSHIELD_URL;
// e.g. https://username:password@us-east-shield-01.quotaguard.com:9294

QuotaGuard Static Pricing Starts at $19/Month

QuotaGuard Static direct plans:

• Starter: $19/month
• Production: $49/month
• Business: $89/month
• Enterprise: $219/month (dedicated IPs available at this tier)

QuotaGuard Shield direct plans:

• Starter: $29/month
• Production: $59/month
• Business: $109/month
• Enterprise: $259/month (dedicated IPs available at this tier)

All plans include a 3-day trial. Enterprise trials run 7 days. Credit card required. See full pricing.

Most Airtable integrations start on the Starter plan. If your middleware handles high request volume or you need multiple IPs for different destinations, Production covers it. Dedicated IPs are Enterprise-only and aren't needed unless a vendor specifically requires an IP that belongs exclusively to your account.

One Static IP Solves the Airtable Allowlist Problem Permanently

Airtable isn't going to fix this at the platform level anytime soon. The community thread has been open for years and the answer from Airtable has consistently been that fixed outbound IPs aren't on the roadmap.

A middleware proxy with a QuotaGuard static IP takes 2 minutes to configure. You allowlist one IP at your destination. It doesn't change. Your firewall rule works indefinitely. That's the fix.

Get started with QuotaGuard Static or QuotaGuard Shield if you need SSL passthrough for compliance.