QuotaGuard and Microsoft Power Automate Integration Guide

QuotaGuard and Microsoft Power Automate Integration Guide

Get two static outbound IPs for your Power Automate flows

Power Automate cloud flows call external APIs from Microsoft shared service-tag IP ranges, so the source IP is never fixed and cannot be allowlisted. To send those calls from two fixed IP addresses, host a small relay function that egresses through QuotaGuard, then call that relay from the HTTP action with two headers. Your target API sees the two static IP addresses assigned to your QuotaGuard subscription, and you allowlist both.

This page documents the relay path end to end. The reusable relay pattern is documented once at Static IP with no HTTP proxy and in the lambda-relay example repo. This guide links those and shows the Power Automate-specific call.

Why Power Automate needs a static IP

A Power Automate cloud flow does not run from an IP you control. When a flow uses the HTTP action or a connector, the request egresses from Microsoft-owned shared address space, published as the service tags LogicApps, PowerPlatformPlex, and PowerPlatformInfra. Those ranges are large, shared across every tenant in the region, and change over time. Microsoft tells you to allow the service tags, not a small fixed set of IPs. Many partner and vendor APIs will not accept a broad Microsoft range on their allowlist, and some do not support service tags at all.

If a destination requires a small, stable set of source IPs, you need a fixed egress identity that Power Automate itself cannot provide. Common destinations that require allowlisting an exact IP:

• Payment gateways and financial APIs
• Partner and supplier B2B APIs
• Legacy or on-premise systems behind a firewall
• MongoDB Atlas, Supabase, Neon, and other managed databases with IP access lists
• Salesforce, NetSuite, and other SaaS platforms with trusted-IP login ranges
• Any vendor whose security review asks for “the IP addresses your integration will call from”

QuotaGuard gives you two load-balanced static IP addresses assigned to your subscription. You allowlist those two on the destination, and every relayed request arrives from one of them.

Why the relay pattern, not a proxy setting

Power Automate cloud flows have no place to set an HTTP proxy. There is no HTTP_PROXY variable, no proxy field on the HTTP action, and no arbitrary code step where you could attach one. The proxy settings documented for Power Automate are for Power Automate for desktop, a separate product that runs on a machine you manage. They do not apply to cloud flows.

Because the flow cannot route its own traffic, the fix is to give it a destination that already egresses through QuotaGuard. You host a small relay function on a platform that does support a proxy, AWS Lambda or a Google Cloud Function, and that function forwards your request through the QUOTAGUARDSTATIC_URL connection. The flow calls the relay. The relay calls the real API from your two static IPs.

Power Automate HTTP action
        |
        v
Relay function (AWS Lambda or Google Cloud Function)
        |  egresses via QUOTAGUARDSTATIC_URL
        v
QuotaGuard  -->  two static IPs  -->  Target API

Set up the relay function

The relay is a short function that reads two request headers, forwards the request through QuotaGuard, and returns the response. Do not re-derive it here. Use the ready-to-run version and deploy it once.

1. Deploy the published example: quotaguard/static-examples/python/lambda-relay. It ships as an AWS Lambda with a Function URL. A Google Cloud Function port follows the same shape.
2. Set the function’s QUOTAGUARDSTATIC_URL environment variable to the value from your QuotaGuard dashboard. It looks like http://username:password@us-east-static-01.quotaguard.com:9293. Use the exact host for your region from the dashboard.
3. Set a shared secret on the function, for example an environment variable RELAY_KEY. The function rejects any request whose X-Relay-Key header does not match. This stops the public Function URL from being used as an open forwarder.
4. Note the relay’s invoke URL. You call this from Power Automate.

The full explanation of how the relay reads X-Relay-Key and X-Target-URL, forwards through the proxy, and streams the response back lives on the shared relay pattern page. Read it once, then reuse the deployed relay for every flow.

Region note: choose the QuotaGuard region closest to where you host the relay function to minimize added latency. The region is set at sign-up. Changes after sign-up require contacting support.

Call the relay from a Power Automate cloud flow

Use the premium HTTP action (or HTTP + Swagger). It lets you set the method, the URL, and custom headers, which is all the relay needs.

1. In your flow, add a new step and choose the HTTP action.
2. Set the fields:

The action inputs look like this in the flow’s code view:

{
  "method": "POST",
  "uri": "https://abc123.lambda-url.us-east-1.on.aws/",
  "headers": {
    "X-Relay-Key": "@parameters('RelayKey')",
    "X-Target-URL": "https://api.partner.com/v1/orders",
    "Content-Type": "application/json"
  },
  "body": {
    "order_id": "@{triggerBody()?['orderId']}"
  }
}

Store the relay secret in a secure input or an environment variable rather than pasting it in plain text. Keep the real target API URL in the X-Target-URL header. The relay reads that header, calls the target through QuotaGuard, and returns the target’s status code and body to your flow so downstream steps parse the response as normal.

The X-Relay-Key and X-Target-URL header names, and the forwarding behavior, are defined by the relay you deployed. They are documented on the shared relay pattern page.

Test that traffic exits from your static IPs

Point the relay at the QuotaGuard IP check endpoint before you wire up the real API. This confirms the whole path works and shows you which IP a request left from.

Set the HTTP action’s X-Target-URL header to:

https://ip.quotaguard.com

Run the flow and inspect the HTTP action’s output body. You should see:

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

The returned IP must be one of the two static IP addresses shown in your QuotaGuard dashboard. Run the flow a few times. Because the IPs are load balanced, you will see both addresses across repeated runs. Allowlist both on your destination.

If you want to confirm outside the flow, call https://ip.quotaguard.com from a terminal through the same QUOTAGUARDSTATIC_URL credentials to see the pair before you build the flow.

Troubleshooting

HTTP action returns 401 or 403 from the relay. The X-Relay-Key header does not match the secret set on the relay function. Confirm the value, and check for a trailing space or a smart quote introduced when pasting into the header field.

Target API returns 403 from a non-allowlisted IP. The request reached the API but from an unexpected source. Confirm the relay’s QUOTAGUARDSTATIC_URL is set, then run the ip.quotaguard.com test above and allowlist the exact two IPs it returns. Do not allowlist a proxy hostname or an nslookup result. Only the two IPs in your dashboard are correct.

Wrong IP returned, or a Microsoft service-tag IP appears. The flow called the target API directly instead of the relay. Check that the HTTP action’s URI is the relay invoke URL and that the real API URL is in the X-Target-URL header, not in the URI field.

The HTTP action is unavailable or asks for a premium license. The native HTTP and HTTP + Swagger actions are premium in Power Automate. Confirm your plan includes premium connectors, or use a custom connector that points at the relay URL.

Connection timeout to the relay. The Function URL is unreachable or the function is cold-starting past the action timeout. Confirm the URL responds from a browser or curl, and raise the function’s timeout and memory if cold starts are slow.

502 or 504 from the relay. The relay reached QuotaGuard but the upstream target timed out or refused the connection. Test X-Target-URL against https://ip.quotaguard.com to isolate whether the proxy path or the target is failing.

QuotaGuard Static vs QuotaGuard Shield

Most Power Automate integrations use QuotaGuard Static. Choose Shield only when the workload handles regulated data or the environment requires TLS on every hop between the relay and the proxy.

Static is right for standard HTTPS API calls from your relay. The payload is tunneled end to end and is never decrypted at the proxy. Choose Shield (SSL passthrough) when the workload handles regulated data such as HIPAA, PCI-DSS, or SOC 2 material, or when your environment requires TLS on the hop 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 with no HTTP proxy

Contact Support