Give Relay.app Automations a Static IP Address

Give Relay.app Automations a Static IP Address

Relay.app sends every Custom HTTP Request from shared, rotating cloud infrastructure, so the API you call sees a different source IP each time. When your destination API requires an allowlisted source IP, you need those calls to exit from a fixed address. QuotaGuard gives your subscription two load-balanced static IP addresses. This guide shows how to send Relay.app HTTP traffic through them.

Answer capsule

Relay.app’s Custom HTTP Request step has no HTTP proxy setting and cannot run a sidecar, so it cannot point directly at QuotaGuard. Instead you host a tiny relay function (AWS Lambda or a Google Cloud Function) that egresses through QuotaGuard, and you point the Relay.app HTTP step at that function’s URL. Every downstream API call then exits from one of your two QuotaGuard static IPs. Allowlist both IP addresses from your QuotaGuard dashboard at the destination and you are done.

Why Relay.app needs a static IP

Relay.app runs your automations on managed cloud infrastructure. The outbound IP address of a Custom HTTP Request is not fixed and can change between runs, which breaks any destination that authenticates or filters by source IP. A static IP gives every call a stable, allowlistable origin.

Common destinations that require a fixed source IP:

• Financial and banking APIs with IP allowlists
• Partner and supplier APIs that gate access by source IP
• Payment gateways and processors
• Internal or on-prem systems reachable only from known IPs
• Databases and data APIs behind an IP firewall (MongoDB Atlas, Amazon RDS, Supabase, Neon)
• Government, healthcare, and enterprise endpoints with strict network rules

How the relay pattern works

Relay.app’s outbound mechanism is the Custom HTTP Request action. You set the URL, the method (GET, POST, PUT, or PATCH), custom headers as key-value pairs, and an optional JSON or Form payload. There is no field for an HTTP proxy, and the automation runtime does not let you install a proxy client or sidecar. A proxy URL alone cannot be used here.

The fix is a relay. You deploy a small serverless function that receives a request from Relay.app, then forwards it to the real target API through the QuotaGuard proxy. The target API sees the request coming from one of your two QuotaGuard static IPs. The function is stateless and does one job: read two headers, forward the call through QUOTAGUARDSTATIC_URL, and return the response.

This is a reusable pattern that works for any automation platform without a proxy setting. The full walkthrough and a ready-to-run example live here. Use them as the source of truth for the function itself, then wire up the Relay.app call below.

• Relay pattern (concept and setup): Static IP for platforms with no HTTP proxy
• Ready-to-run Lambda example: quotaguard/static-examples lambda-relay

Step 1: deploy the relay function

Deploy the relay function from the example repo to AWS Lambda (with a Function URL) or to a Google Cloud Function (HTTP trigger). Set two things on the function:

• QUOTAGUARDSTATIC_URL, the connection string from your QuotaGuard dashboard, of the form http://username:password@<region>-static-01.quotaguard.com:9293. Use the exact value shown in your dashboard.
• RELAY_KEY, a secret string you choose. The function checks it against the X-Relay-Key header on every request so that only your Relay.app automation can use it.

The relay reads two request headers on each call:

• X-Relay-Key, the shared secret above.
• X-Target-URL, the real API endpoint you want to reach.

It forwards the request body, method, and the Content-Type and Authorization headers to X-Target-URL through the QuotaGuard proxy, then returns the target’s response. If the target needs a different custom header, add that header name to the forwarding list in the relay function. See the repo for the code and deploy steps.

Step 2: point the Relay.app Custom HTTP Request at the relay

In your Relay.app workflow, add a Custom HTTP Request step. Configure it to call your relay function URL instead of the target API directly.

• URL: your deployed relay function URL (the Lambda Function URL or Cloud Function URL).
• Method: the method your target API expects (GET, POST, PUT, or PATCH).
• Headers (key-value pairs):
  • X-Relay-Key: your shared secret. Store this in the Relay.app Secret Store and reference it here rather than pasting it in plaintext.
  • X-Target-URL: the real API endpoint, for example https://api.example.com/v1/orders.
• Body: the JSON or Form payload your target API expects. Relay.app always sends a Content-type header, and the relay passes your body straight through to the target.

Concretely, a POST to a partner API becomes a POST to your relay with these two headers set:

POST https://your-relay-function-url/
X-Relay-Key: your-shared-secret
X-Target-URL: https://api.example.com/v1/orders
Content-type: application/json

{ "order_id": "12345", "status": "shipped" }

The relay forwards this to https://api.example.com/v1/orders through QuotaGuard, and the partner API sees one of your two static IPs.

Testing

Before pointing the relay at a real API, confirm traffic exits from your static IPs. Set the Relay.app step’s X-Target-URL header to the QuotaGuard IP check endpoint and run the workflow.

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

The response body is:

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

The returned IP must be one of the two static IPs listed in your QuotaGuard dashboard. Run it a few times. Because the IPs are load-balanced, you will see both addresses over repeated calls. Allowlist both at your destination.

Troubleshooting

403 Forbidden from the relay function. The X-Relay-Key header sent by Relay.app does not match the secret set on the function. Confirm the value in the Relay.app Secret Store matches X-Relay-Key on the function exactly, with no trailing whitespace.

Wrong or unexpected IP returned by ip.quotaguard.com. The function is egressing directly instead of through the proxy. Confirm QUOTAGUARDSTATIC_URL is set on the function and that the function code routes the outbound request through it. A returned IP that is not in your dashboard means the proxy was bypassed.

407 Proxy Authentication Required. The QUOTAGUARDSTATIC_URL credentials are wrong or truncated. Copy the full connection string from your dashboard, including username and password, and redeploy the function.

Destination still returns 401 or 403 after routing through the relay. The destination has not allowlisted your static IPs, or only one of the two. Add both IP addresses from your QuotaGuard dashboard to the destination’s allowlist.

Relay.app step times out. Relay.app applies a fixed 3-minute timeout to Custom HTTP Requests and this cannot be changed. If the target API plus proxy hop is slow, reduce payload size or check the target’s own latency. A cold serverless function can add a first-call delay, so a warm function responds faster.

Connection timeout to the target. The relay reached QuotaGuard but the target did not respond. Confirm X-Target-URL is a full URL including https://, and that the target is reachable from the proxy region.

QuotaGuard Static vs QuotaGuard Shield

Most Relay.app automations should use QuotaGuard Static. Choose Shield only when the workload handles regulated data (HIPAA, PCI-DSS, SOC 2) or the environment requires TLS on every hop between the relay function and the proxy itself.

Static is right for standard HTTPS API calls from your relay function. The payload is tunneled end to end and is never decrypted at the proxy. Choose Shield (SSL passthrough) if the workload handles regulated data or the environment requires TLS between the relay and the proxy.

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