QuotaGuard and Glide Integration Guide

QuotaGuard and Glide Integration Guide

Glide apps call external APIs through the Call API action and Call API column. Glide sends those requests from its own shared infrastructure, so the source IP is not fixed and cannot be allowlisted. This guide gives your Glide app two fixed outbound IP addresses. You deploy a small relay function that egresses through QuotaGuard, point Glide’s Call API at the relay, and every downstream request exits from one of your two static IPs.

Get a static IP for Glide Call API requests in three steps

Glide’s Call API lets you set the Endpoint, Method, Query String, Headers, and Body, but it has no HTTP proxy setting and cannot run a sidecar. So you host a tiny relay function (AWS Lambda or a Google Cloud Function) that forwards requests through QuotaGuard, and Glide calls that relay. The result: your target API sees the two static IP addresses assigned to your QuotaGuard subscription, not Glide’s shared pool.

1. Deploy the relay function and connect it to QuotaGuard using the shared relay pattern.
2. In Glide, set the Call API Endpoint to your relay URL and add two headers, X-Relay-Key and X-Target-URL.
3. Allowlist your two QuotaGuard static IPs at the destination API.

Why Glide needs a static IP

Glide is a no-code platform. Your app runs on Glide’s managed infrastructure, and outbound Call API requests leave from shared, rotating IP addresses. Many APIs and databases refuse connections unless the caller comes from a known, fixed IP. There is no way to pin Glide’s egress IP from inside the builder, and there is no proxy field on the Call API action or column.

Common destinations that require a fixed source IP:

• Payment and billing gateways that allowlist server IPs
• Partner and supplier APIs behind an IP firewall
• Banking, insurance, and healthcare APIs
• Internal or on-prem systems exposed through a corporate firewall
• Databases fronted by an HTTP data API (for example a MongoDB Atlas Data API, a Supabase or Neon REST endpoint) with IP rules
• ERP, CRM, and logistics systems that gate access by source IP

If the API you are calling shows a place to enter allowed IP addresses, Glide needs a static IP to sit behind.

Getting Started

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

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

Every QuotaGuard subscription is assigned two load-balanced static IP addresses. You allowlist both at the destination API. The proxy connection string is delivered as QUOTAGUARDSTATIC_URL, in the form http://username:password@<region>-static-01.quotaguard.com:9293. Copy the exact value from your dashboard.

Why a relay, and how it works

Glide cannot set an HTTP proxy and cannot run a sidecar, so it cannot route its own egress through QuotaGuard. The relay solves this. You host a small function on infrastructure that can set a proxy environment variable, AWS Lambda or a Google Cloud Function. The function reads QUOTAGUARDSTATIC_URL, and forwards any request it receives out through QuotaGuard. Because the forwarded request exits QuotaGuard, the target API sees your two static IPs.

The flow:

1. Glide’s Call API sends a request to your relay function URL, with two headers.
2. X-Relay-Key is a shared secret the relay checks so that only your app can use it.
3. X-Target-URL is the real API you want to reach.
4. The relay forwards the request to X-Target-URL through the QUOTAGUARDSTATIC_URL connection.
5. The target API responds, and the relay passes the response back to Glide.

This relay pattern is reusable across any no-code platform that has an outbound HTTP call but no proxy control. Do not re-derive it here. Use the two published sources:

• The shared pattern guide: Static IP for platforms with no HTTP proxy
• The ready-to-run example: quotaguard/static-examples lambda-relay

Deploy the relay from the example repo, set QUOTAGUARDSTATIC_URL (from your dashboard) and RELAY_KEY (a secret you choose) as environment variables on the function, and note the function’s public URL. Then wire Glide to it below.

Step 1: point Glide’s Call API at the relay

In the Glide builder, add a Call API action (or a Call API column) and configure these fields.

Endpoint

Set the Endpoint to your relay function URL, for example:

https://abc123.lambda-url.us-east-1.on.aws/

Method

Choose the method your target API expects: GET, POST, PUT, PATCH, or DELETE. The relay forwards the method through to X-Target-URL.

Headers

Click + Add value to add each header. Glide automatically marks manually entered header values as secret, which is what you want for the relay key. Add two headers:

If your target API needs its own auth header (for example Authorization: Bearer ...), add it here too as an extra header. The relay forwards the Content-Type and Authorization headers to the target. If the target needs a different custom header (for example X-Api-Key), add that header name to the forwarding list in the relay function.

Body

Put the request body your target API expects. Use Glide’s JSON Object column to build the body dynamically from your app’s data, then reference it here. The relay passes the body straight through.

Query String

If your target API needs query parameters, you can append them to the X-Target-URL value, or add them under Query String if your relay is written to forward them. Appending to X-Target-URL is the simplest and always works.

That is the entire Glide-side setup. Endpoint to the relay, two headers, your normal body.

Step 2: allowlist your two static IPs

At the destination API’s dashboard, add both static IP addresses shown in your QuotaGuard dashboard to the allowlist. Add both, because requests are load-balanced across the pair. Allowlist exactly the two IPs from the dashboard. Do not resolve or nslookup the proxy hostname to find an IP, because a proxy hostname resolves to internal infrastructure, not your allowlist IPs.

Testing

Confirm the static IP is working before you point the relay at a production API. QuotaGuard has an IP check endpoint that returns the source IP it saw.

Set the Glide Call API to:

• Method: GET
• Endpoint: your relay function URL
• Headers: X-Relay-Key = your secret, X-Target-URL = https://ip.quotaguard.com

Run the action. The response body is:

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

The returned IP must match one of the two static IPs in your QuotaGuard dashboard. Run it a few times. Because the pair is load-balanced, you should see both of your static IPs appear across repeated calls. If you see an IP that is not in your dashboard, the request is not going through the relay, or the relay is not reading QUOTAGUARDSTATIC_URL.

You can also test the relay directly with curl before touching Glide:

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

The same JSON response confirms the relay and the QuotaGuard connection are wired correctly.

Troubleshooting

Wrong IP returned by ip.quotaguard.com The returned IP is not one of your two static IPs. The relay is reaching the target directly instead of through QuotaGuard. Confirm QUOTAGUARDSTATIC_URL is set on the function exactly as shown in your dashboard, and that the relay code sends the outbound request through that proxy variable.

403 or 401 from the relay itself The relay rejected the request. Your X-Relay-Key header value in Glide does not match the RELAY_KEY environment variable on the function. Re-copy the secret into both places. Watch for trailing spaces.

Timeout or no response in Glide The relay took too long or is not reachable. Check the function URL is public and correct in the Endpoint field, and confirm the relay’s own timeout is long enough for the target API. Lambda and Cloud Function default timeouts are often shorter than a slow third-party API needs.

Connection still blocked at the destination API The target API still sees a non-allowlisted IP. You allowlisted only one of the two static IPs. Add both from your QuotaGuard dashboard, since the pair is load-balanced.

407 Proxy Authentication Required in the relay logs The relay reached QuotaGuard but the credentials were rejected. The username or password in QUOTAGUARDSTATIC_URL is wrong or truncated. Copy the full connection string from the dashboard again.

Target API returns 400 or 422 through the relay but works in a direct test The body or a required header is not being forwarded. Confirm the target’s own auth header is added in Glide’s Headers, and that the Body is populated. If you built the body with a JSON Object column, verify it produces valid JSON.

Headers missing at the target Remember Glide marks manually entered header values as secret. That is expected and does not stop them being sent. If a header is genuinely missing, confirm you clicked + Add value and saved the action.

QuotaGuard Static vs QuotaGuard Shield

Most Glide integrations use QuotaGuard Static. Your Call API requests travel HTTPS end to end, and the payload is never decrypted at the proxy. Choose Shield only when the workload carries regulated data (HIPAA, PCI-DSS, SOC 2) or the environment requires TLS on every hop, including between the relay and the proxy.

Static is right for standard HTTPS API calls from a Glide relay. 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 IP for platforms with no HTTP proxy

Contact Support