Airtable

QuotaGuard puts two fixed IP addresses onto the target API's allowlist for your Airtable integration. Because Airtable's automation fetch cannot set an HTTP proxy, a small relay you host forwards each outbound call through QuotaGuard at the connectivity layer, so the target sees one of your two static IPs instead of Airtable's rotating egress. Trusted for static IP connectivity since 2013.

• Relay-Based Setup: Host a small relay function on AWS Lambda or a Google Cloud Function, set your QuotaGuard connection URL and a secret key, and point Airtable's "Run a script" fetch at the relay URL with the target API passed in an X-Target-URL header and the secret in an X-Relay-Key header. Register your two static IPs with the target API once.
• The Target Sees Static IPs, Not Airtable's: The relay forwards every request through QuotaGuard, so the target API sees your two static IPs. Airtable's rotating egress and the relay host's own IP never reach the allowlist check.
• Multi-Platform Support: The relay deploys on AWS Lambda or Google Cloud Functions, and the same relay serves Bubble, Zapier, and any other platform that can call a URL but cannot set a proxy. One piece of infrastructure covers them all.
• Production-Grade Reliability: A load-balanced pair of static IPs with health checks and automatic failover. Both IPs go on the target's allowlist, and traffic routes through whichever responds.
• Shield for Regulated Data: For HIPAA, PCI-DSS, or SOC 2 workflows, QuotaGuard Shield uses SSL passthrough so QuotaGuard never decrypts the data flowing between the relay and the target API.

Gate note: You only need this when the API your Airtable "Run a script" automation calls enforces IP allowlisting. If the target rejects requests from unregistered IPs, Airtable's dynamic egress fails and you need the two static IPs. Calls to APIs with no IP allowlist do not need it.