Give Airtable a Static IP With a Relay Function and QuotaGuard

Airtable automations make outbound calls with fetch inside the Run a script action. That works for reaching any API, but the request leaves from Airtable's shared infrastructure on an IP that changes. If the API you're calling sits behind a firewall allowlist, those calls get blocked. The fix is a static outbound IP, and Airtable gives you no direct way to set one.

Airtable's Run a Script Action Sends fetch Straight to the Internet

The Run a script action runs in a sandbox. You call fetch() and the request goes out over Airtable's network. There's no setting for HTTP_PROXY, no environment variables you control, and no sidecar process you can attach. Airtable's own docs confirm scripts make outbound calls with fetch and say nothing about proxy configuration, because there isn't any. So you can't point Airtable at a proxy the way you would in a server app. The egress IP is Airtable's, and it isn't fixed.

A Relay Function Gives Airtable a Static IP

Since Airtable can't set a proxy or run a sidecar, you host a small relay function that does the proxying for it. You deploy the relay on AWS Lambda or a Google Cloud Function, and the relay egresses through QuotaGuard. Airtable calls the relay function URL. The relay forwards your request through the QuotaGuard connection, and the target API sees one of your two static IPs instead of Airtable's rotating address.

QuotaGuard assigns two load-balanced static IPs to every subscription, and the relay forwards through the QUOTAGUARDSTATIC_URL connection so your target API only ever sees those two addresses. Allowlist both IPs on the destination firewall, because either one can serve any given request. This relay pattern is the standard way to give a sandboxed platform a static IP. QuotaGuard documents it in full at the no-HTTP-proxy platform guide, and there's a ready-to-run example in the lambda-relay repo. Deploy that, set your QuotaGuard connection string on it, and you're done in about 2 minutes.

Your Airtable Script Calls the Relay With Two Headers

The relay reads two headers. X-Relay-Key is a shared secret that stops anyone else from using your relay. X-Target-URL is the real API you want to reach. You send those to the relay function URL, and the relay forwards the body and method through to the target. Here's the Run a script version:

// Airtable automation: Run a script action
const RELAY_URL = 'https://your-relay-id.lambda-url.us-east-1.on.aws/';
const RELAY_KEY = 'your-shared-secret';
const TARGET = 'https://api.example.com/v1/resource';

const response = await fetch(RELAY_URL, {
    method: 'POST',
    headers: {
        'X-Relay-Key': RELAY_KEY,
        'X-Target-URL': TARGET,
        'Content-Type': 'application/json'
    },
    body: JSON.stringify({ example: 'payload' })
});

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

The same call from the command line, useful for testing the relay before you wire it into Airtable:

curl -X POST "https://your-relay-id.lambda-url.us-east-1.on.aws/" \
  -H "X-Relay-Key: your-shared-secret" \
  -H "X-Target-URL: https://api.example.com/v1/resource" \
  -H "Content-Type: application/json" \
  -d '{"example":"payload"}'

Swap api.example.com for the real endpoint from your vendor's API reference. Keep X-Relay-Key out of shared bases and check your vendor's docs for the exact path and payload the endpoint expects.

Point X-Target-URL at the IP Checker to Confirm Your Static IPs

To confirm the relay is egressing through QuotaGuard, set X-Target-URL to https://ip.quotaguard.com. That endpoint returns the IP the request came from, which will be one of your two static IPs. Run it a few times and you'll see both addresses. Those are the two you allowlist on the destination firewall.

curl -X POST "https://your-relay-id.lambda-url.us-east-1.on.aws/" \
  -H "X-Relay-Key: your-shared-secret" \
  -H "X-Target-URL: https://ip.quotaguard.com"

QuotaGuard Static Pricing Starts at $19/Month

QuotaGuard Static is the right product for standard HTTPS API calls from Airtable. On outbound HTTPS it uses a standard CONNECT tunnel, so your payload is tunneled end to end and never decrypted at the proxy. Bandwidth is bundled with no per-GB overage fees, which fits the light, per-record traffic most Airtable automations generate. QuotaGuard Static direct plans start at $19/month. Dedicated IPs are available on Enterprise and above. On lower tiers, your subscription's two assigned IPs are still static, but shared with other customers.

QuotaGuard Shield Pricing Starts at $29/Month

If your Airtable automation moves regulated data, healthcare records, payment information, or anything under HIPAA, PCI-DSS, or SOC 2 review, use QuotaGuard Shield instead. Shield uses SSL passthrough, so the TLS connection runs end to end and QuotaGuard never decrypts your data in ordinary operation. QuotaGuard Shield direct plans start at $29/month. It costs slightly more than Static at each tier because SSL passthrough adds routing overhead, and the compliance coverage is worth the difference when your data requires it. All plans include a 3-day trial, Enterprise plans include a 7-day trial, and a credit card is required.

Deploy the relay from the lambda-relay example repo, follow the full walkthrough in the no-HTTP-proxy platform guide, and point your Airtable Run a script action at it. Then allowlist your subscription's two static IPs on the destination and your automations run from a fixed address every time. See the full pricing table at quotaguard.com/products/pricing.