QuotaGuard and Airtable Integration Guide

Static IPs for Airtable Automation Scripts

Airtable automation scripts reach an API from a fixed pair of static IP addresses when you route the request through a small relay function that egresses via QuotaGuard. Airtable’s “Run a script” action uses a sandboxed fetch with no proxy setting, no environment variables, and no sidecar, so you cannot point it at a proxy directly. Instead you host a tiny relay function (AWS Lambda or a Google Cloud Function) that forwards through QuotaGuard, and your script calls that relay with two headers. The target API then sees one of the two static IP addresses assigned to your QuotaGuard subscription.

Why Airtable needs a static IP

Airtable runs your automation scripts on shared infrastructure. The outbound IP address of a fetch call is not fixed and is not published, so any API that gates access by IP allowlist will reject the request. There is no supported way to set an HTTP proxy inside the Airtable scripting sandbox, no place to set the standard HTTPS_PROXY environment variable, and no way to attach a network sidecar. That leaves an outbound relay as the clean path to a stable egress identity.

Common destinations that require a static IP on the allowlist:

• Payment and billing gateways that allowlist server IPs
• Partner and supplier APIs that issue per-customer IP allowlists
• Banking and financial data APIs
• Legacy or on-premise systems reached over a site-to-site or firewall rule
• Internal enterprise APIs behind a corporate firewall
• Databases and data APIs (MongoDB Atlas, Supabase, Neon, Amazon RDS proxies) that restrict inbound connections by IP

Once the request egresses through QuotaGuard, you allowlist the two static IP addresses from your dashboard and every call from your Airtable automation is accepted.

How the relay pattern works

Airtable cannot set a proxy, so the fixed egress happens one hop away. You deploy a small relay function that you control on AWS Lambda or a Google Cloud Function. The relay is configured with your QUOTAGUARDSTATIC_URL and forwards any request it receives through that proxy. Your Airtable script calls the relay’s function URL and passes two headers:

• X-Relay-Key is a secret you generate. The relay checks it and rejects calls that do not match.
• X-Target-URL is the full URL of the API you actually want to reach.

The relay forwards the request through the QuotaGuard proxy to that target, and the target sees one of the two static IPs assigned to your subscription. The response comes back through the relay to your Airtable script.

This relay pattern is the same across every platform that cannot set an HTTP proxy, so it is documented once, in full, here:

• Shared pattern and reasoning: Static IPs for platforms that can’t set an HTTP proxy
• Ready-to-run relay code (AWS Lambda): quotaguard/static-examples lambda-relay

Deploy the relay from that repo first, note its function URL and the X-Relay-Key secret you set, then wire up the Airtable side below.

Getting started

After creating a QuotaGuard account, you are redirected to your dashboard, where you can find your proxy credentials, your QUOTAGUARDSTATIC_URL, and the two static IP addresses assigned to your subscription.

Choose the right proxy region: Select the QuotaGuard region closest to where your relay function runs to minimize latency, then place your relay function in that same cloud region. The region is set at sign-up. Changes after sign-up require contacting support.

Put the QUOTAGUARDSTATIC_URL value from your dashboard into your relay function’s environment, exactly as the relay repo describes. That value is what carries the request out through your two static IPs.

Call the relay from an Airtable script

In Airtable, open your base, add an automation, and add a Run a script action. Point fetch at your relay’s function URL and send the two headers. Do not call the target API directly. The same code runs in the Scripting extension, but the extension executes fetch in the browser and is subject to CORS, so the relay must return CORS headers for that path. The automation “Run a script” sandbox has no such restriction.

// Airtable automation script: call the target API through your QuotaGuard relay.
const RELAY_URL = 'https://YOUR-RELAY-ID.lambda-url.us-east-1.on.aws/';
const RELAY_KEY = 'your-long-random-secret'; // must match X-Relay-Key in the relay

const targetUrl = 'https://api.partner.com/v1/orders';

const response = await fetch(RELAY_URL, {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
        'X-Relay-Key': RELAY_KEY,
        'X-Target-URL': targetUrl,
    },
    body: JSON.stringify({
        // the JSON body your target API expects
        reference: 'AB-1024',
        amount: 4200,
    }),
});

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

Notes for the Airtable sandbox:

• The fetch response payload has a size limit of 4.5 MB. Keep target responses under that or paginate.
• Redirects are restricted in the sandbox. Have the relay resolve any redirect and return the final response.
• Store the relay key and URL as input variables in the automation rather than hardcoding them where practical, so you can rotate the secret without editing the script.
• A GET through the relay looks the same. Drop the body, set method: 'GET', and keep the two headers.

For anything about the relay itself (how it reads X-Target-URL, how it forwards through QUOTAGUARDSTATIC_URL, how it validates X-Relay-Key), follow the shared relay pattern page and the lambda-relay repo. Do not reimplement it per base.

Test that traffic exits from your static IPs

Point the relay at the QuotaGuard IP check endpoint and confirm the response is one of your two static IPs. Set X-Target-URL to https://ip.quotaguard.com and run the script.

const RELAY_URL = 'https://YOUR-RELAY-ID.lambda-url.us-east-1.on.aws/';
const RELAY_KEY = 'your-long-random-secret';

const response = await fetch(RELAY_URL, {
    method: 'GET',
    headers: {
        'X-Relay-Key': RELAY_KEY,
        'X-Target-URL': 'https://ip.quotaguard.com',
    },
});

console.log(await response.json());

Expected response:

{"ip":"<one of your two QuotaGuard static IPs>"}

The returned IP must match one of the two static IP addresses shown in your QuotaGuard dashboard. Run the script a few times. Because the pair is load-balanced, you will see both addresses over repeated calls. Allowlist both of them on the destination API, in both directions if the API distinguishes inbound and outbound rules.

Troubleshooting

403 Forbidden from the relay (not from the target). The X-Relay-Key header your script sent does not match the secret configured in the relay function. Confirm both values character for character, and check for a trailing space in the automation input variable.

Wrong IP returned, or your own cloud IP appears. The relay is not forwarding through the proxy. Confirm QUOTAGUARDSTATIC_URL is set in the relay function’s environment and that the relay code reads it. Re-run the ip.quotaguard.com test above. The value must be one of the two dashboard IPs.

Target API still returns 401 or 403 after the relay works. The static IPs are not on the destination allowlist yet, or only one of the two is. Add both IP addresses from your QuotaGuard dashboard. Do not resolve or nslookup the proxy hostname to find an IP. Use the exact pair shown in the dashboard.

Connection timeout calling the relay. The relay function URL is unreachable or the function is cold-starting past Airtable’s request window. Confirm the function URL is public, retry to rule out a cold start, and keep the relay in a region near your QuotaGuard region.

Response truncated or the script errors on large payloads. Airtable caps the fetch response at 4.5 MB. Have the relay request a smaller page, or filter fields at the target API so the response fits.

Redirect error in the script. The Airtable sandbox does not follow redirects normally. Let the relay follow the redirect server-side and return the final body to your script.

QuotaGuard Static vs QuotaGuard Shield

Static is the right product for standard HTTPS API calls from Airtable. The HTTPS payload is tunneled end to end and is never decrypted at the proxy. Choose Shield only when the workload handles regulated data (HIPAA, PCI-DSS, SOC 2) or the environment requires TLS on every hop, including the hop between your relay and the proxy.

Static is right for most Airtable relay setups. Choose Shield if the workload handles regulated data or the environment requires TLS between the relay and the proxy itself.

Ready to Get Started?

Get in touch or create a free trial account.

Try QuotaGuard Now

Read: Static IPs for platforms that can’t set an HTTP proxy

Contact Support