Your Airtable automation scripts reach any IP-allowlisted API from two fixed, load-balanced static IPs. Allowlist the pair once and every "Run a script" action arrives from an address the partner already trusts.
Airtable's automation fetch runs in a sandbox with no proxy setting and no environment or sidecar of its own, so its egress rides Airtable's shared cloud ranges and shifts without notice. QuotaGuard pins that traffic behind a stable pair of IPs a locked-down API will accept.
QuotaGuard Static starts at $19/month, direct. You register two IPs, and they stay put through plan changes and script edits.
You get a stable outbound identity for Airtable automations even though the script sandbox cannot set an HTTP proxy. A small relay function you host does the egress, and Airtable's fetch calls it with two headers.
Airtable's "Run a script" action runs server-side and lets you set custom request headers on fetch, which is all the pattern needs. It cannot point that request at a proxy, so the static IP is applied one hop out, at the relay.
Airtable's automation fetch accepts custom headers, so your script sends the target API in X-Target-URL and a secret in X-Relay-Key to the relay function URL. No proxy setting is required inside Airtable, which is the one thing the sandbox does not offer.
You host a small AWS Lambda or Google Cloud Function that egresses through the QuotaGuard connection, so the target API sees one of your two static IPs instead of Airtable's rotating ranges. The ready-to-run example is published at github.com/quotaguard/static-examples in the python/lambda-relay folder.
Airtable's remoteFetchAsync routes a call through Airtable's own servers to clear CORS, so the target sees Airtable's shared addresses, not a fixed pair you control. The relay is what puts a stable, allowlistable IP in front of the API.
Your API payloads stay encrypted end to end. QuotaGuard Static tunnels standard HTTPS calls without decrypting them at the proxy, so it fits the vast majority of Airtable automation traffic. Static is direct from $19/month.
Airtable's fetch sandbox has hard edges, and the relay is the clean place to absorb them.
QuotaGuard Static is the right choice for normal HTTPS API traffic. The request is tunneled through to the destination and never decrypted at the proxy, so the two static IPs are all the target sees change.
If the data is governed by HIPAA, PCI-DSS, or SOC 2, use QuotaGuard Shield, which uses SSL passthrough. Shield is direct from $29/month, and Static covers everything that is not regulated.
Airtable automation fetch does not follow redirects, has no cookie jar, and caps a response near 4.5 MB. Your relay function can follow a redirect, hold a session cookie, or trim a large response before returning it, so a locked-down API still works cleanly behind the static pair.
Both of your static IPs stay reachable. QuotaGuard gives every subscription two load-balanced static IPs with health checks and automatic failover, so a single node going down does not cut your Airtable automations off from the API.
Allowlist both addresses on the destination and traffic keeps flowing across the failover.
Each QuotaGuard subscription includes two load-balanced static IPs, not one. Put both on the partner's allowlist so either can serve a request during a failover without the API refusing it.
Pick the QuotaGuard region closest to the API you call to keep the extra hop short. The network runs across eleven AWS regions spanning North America, Europe, and Asia Pacific.
Your two IPs do not change when you move between plans, so an allowlist you set once keeps working. You only update the destination if you deliberately rebuild the subscription.
Common questions about Airtable static IPs and QuotaGuard.
Do my Airtable automations actually need a static IP?
Only when the API you call from a "Run a script" action enforces an IP allowlist, or when a partner requires you to declare the addresses your requests come from. Airtable's automation fetch egresses from Airtable's shared cloud ranges, which are not published as a fixed list you can allowlist and can change over time. If the destination has no IP restriction, you do not need this. If it does, the two static IPs give it a stable pair to trust.
How does this work if Airtable scripts cannot set a proxy?
Airtable's sandboxed fetch has no proxy option and no environment or sidecar, so the static IP is applied one hop out. You host a small relay function, an AWS Lambda or a Google Cloud Function, that egresses through QuotaGuard, and your Airtable script calls that relay's URL. The script passes the real destination in an X-Target-URL header and a shared secret in X-Relay-Key. The relay forwards the call through the QuotaGuard connection, and the target API sees one of your two static IPs. The reusable pattern is documented at quotaguard.com/docs/platforms/static-ip-no-http-proxy and the example repo at github.com/quotaguard/static-examples.
How long does setup take?
Plan for about 15 to 20 minutes once you have a QuotaGuard subscription. You deploy the published relay function, set its relay key and the QuotaGuard connection URL, then change your Airtable script to fetch the relay URL with the two headers instead of calling the API directly. Point X-Target-URL at https://ip.quotaguard.com first and it returns one of your two static IPs, which confirms the path before you touch the real API.
Should I use Static or Shield?
Use QuotaGuard Static for standard HTTPS API calls, which is the right fit for almost all Airtable automation traffic. Static tunnels the request end to end and never decrypts the payload at the proxy, and it is direct from $19/month. Choose Shield, which uses SSL passthrough, only when the data is regulated under HIPAA, PCI-DSS, or SOC 2. Shield is direct from $29/month.
Is it one IP or two, and do I allowlist both?
Every QuotaGuard subscription comes with two static IPs, not one, and they are load balanced per subscription rather than per account. Allowlist both on the destination. The pair exists so health checks and automatic failover can move traffic between the two nodes, and if only one address is on the allowlist a request served by the other node will be refused.
Can I use QuotaGuard for webhooks Airtable receives, not just outbound calls?
The static IPs cover outbound traffic, meaning calls your Airtable scripts make out to an API. Inbound webhooks arriving at Airtable land on Airtable's own endpoints, so QuotaGuard's IPs do not sit in front of them. If a provider needs to allowlist where your callbacks originate, that is still an outbound path and the relay applies. For a service that instead calls a URL you host, put that receiver behind the relay or your own infrastructure rather than expecting the QuotaGuard pair to change Airtable's inbound addresses.
What happens to the Airtable fetch limits like redirects and response size?
Airtable's automation fetch does not follow redirects, supports no cookies, and caps a response near 4.5 MB, which can trip up a strict API. Because the request goes through your relay, the relay can follow a redirect, keep a session cookie, or trim an oversized response before handing it back to Airtable. This keeps the sandbox limits from breaking a call that the static pair otherwise reaches fine.
Can I get a dedicated IP just for my account?
Dedicated IPs are available on QuotaGuard's Enterprise plan. On the standard plans your two static IPs are load balanced and shared, which is enough for an allowlist because the destination only cares that requests come from addresses it recognizes. If you have a contractual need for addresses no other customer uses, that is the Enterprise path.
If I change plans later, do I have to update the allowlist?
No. Your two static IPs stay the same across plan changes, so an allowlist you set on the destination keeps working without edits. You would only re-register addresses if you deliberately tear down and rebuild the subscription, which is rare. Keep both IPs on the allowlist through any plan move.
For over a decade, QuotaGuard has provided reliable, high-performance static IP and proxy solutions for cloud environments like Heroku, Kubernetes, and AWS.
Get the fixed identity and security your application needs today.