QuotaGuard and Microsoft Power Apps Integration Guide
QuotaGuard and Microsoft Power Apps Integration Guide
Give Power Apps a fixed outbound IP for external API calls
QuotaGuard gives your Power Apps custom connectors two fixed outbound IP addresses so any API that allowlists by IP will accept the call. Power Apps reaches external APIs through a custom connector, and a custom connector has no field for an HTTP proxy. So you host a small relay function that egresses through QuotaGuard, point the custom connector at the relay URL, and every request leaves from one of your two static IPs. Both IPs belong to your QuotaGuard subscription. Allowlist both on the destination.
Why Power Apps needs a static IP
Power Apps and Power Automate run on shared Microsoft cloud infrastructure. Outbound calls from a custom connector leave from Microsoft IP ranges that are large, shared across tenants, and not fixed to your app. There is no setting that pins a custom connector to a single egress IP. When a destination API enforces an IP allowlist, you cannot hand it a Microsoft range, and requests from an unknown IP get rejected.
A static IP fixes this. Route the outbound call through QuotaGuard and the destination sees one of your two assigned static IPs every time.
Common destinations that require IP allowlisting:
- Payment and billing gateways (Stripe restricted endpoints, PayPal, Authorize.Net)
- Partner and supplier REST APIs with an IP firewall
- Financial data and banking APIs
- MongoDB Atlas, Amazon RDS, and other managed databases behind a network allowlist
- Legacy or on-prem systems reachable only from a known source IP
- Internal enterprise APIs fronted by a WAF or IP filter
How the relay pattern works
Power Apps cannot set an HTTP proxy on a connector and cannot run a sidecar next to your app. So the outbound call takes one hop through a relay you own.
- You deploy a small relay function (AWS Lambda or a Google Cloud Function). The relay holds your
QUOTAGUARDSTATIC_URLconnection and egresses through QuotaGuard. - Your Power Apps custom connector calls the relay function URL instead of calling the destination API directly.
- The connector sends two headers.
X-Relay-Keyis a shared secret that authorizes the relay.X-Target-URLis the real API endpoint you want to reach. - The relay forwards the request to
X-Target-URLthrough the QuotaGuard proxy. The destination API sees one of your two static IPs.
This relay pattern is reusable across any platform that cannot set an HTTP proxy. The full walkthrough and a ready-to-run function live here, so this page links them instead of repeating all the code:
- Shared relay pattern guide: https://www.quotaguard.com/docs/platforms/static-ip-no-http-proxy/
- Ready-to-run example (Python, AWS Lambda): https://github.com/quotaguard/static-examples/tree/main/python/lambda-relay
Deploy the relay from the repo first. It reads QUOTAGUARDSTATIC_URL from the environment and expects the X-Relay-Key and X-Target-URL headers. Set X-Relay-Key to a strong secret you generate. You reference that same secret from Power Apps below.
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 the region hosting your relay function to minimize latency. The region is set at sign-up. Changes after sign-up require contacting support.
Step 1: build the custom connector that calls the relay
You point a Power Apps custom connector at the relay function URL, not at the destination API. You can create the connector from scratch in the portal. Both Power Apps and Power Automate share custom connectors, so a connector built in one is available in the other.
In make.powerapps.com, go to More > Discover all > Custom connectors > New custom connector > Create from blank.
General tab
- Host: the host of your relay function URL. For an AWS Lambda Function URL this looks like
abcd1234.lambda-url.us-east-1.on.aws. For a Google Cloud Function it looks likeus-central1-yourproject.cloudfunctions.net. - Base URL:
/(or the function path, for example/relay). - Scheme: HTTPS.
Security tab
Set authentication to API Key so the relay secret is stored on the connection rather than typed into every request.
- Parameter label: Relay Key
- Parameter name:
X-Relay-Key - Parameter location: Header
When a user creates a connection for this connector, Power Apps prompts for the API key. Paste the X-Relay-Key secret you set on the relay. The connector then sends it as the X-Relay-Key header on every call, and it is never exposed in the app.
Definition tab
Create a new action (for example CallTargetApi). Under Request, choose Import from sample and provide the shape of the call to the relay.
- Verb: POST
- URL: your relay function URL
-
Headers:
X-Target-URL: https://api.example.com/v1/resource Content-Type: application/json - Body: a sample JSON body if the target API expects one.
After importing, open the X-Target-URL header parameter and set it so app makers can supply the real endpoint at call time. Make it required if each call targets a different endpoint, or set a default value if the connector always hits one API. Leave X-Relay-Key out of the Definition headers. It is already handled by the API key security you configured.
Select Create connector to save.
Step 2: call the connector from your app or flow
From a canvas app (Power Fx)
Add the custom connector as a data source (Data > Add data > your connector), then call the action. Power Fx passes the target URL and body:
// Call the relay, which forwards to the target API through QuotaGuard
Set(
apiResponse,
YourConnector.CallTargetApi(
{ 'X-Target-URL': "https://api.example.com/v1/orders" },
{ orderId: 12345, status: "shipped" }
)
);
The exact parameter shape depends on how you named the header and body parameters in the Definition tab. Use the IntelliSense suggestions Power Fx shows for your connector.
From a Power Automate flow
Add your custom connector action to the flow and fill the parameters:
- X-Target-URL:
https://api.example.com/v1/orders - Body: the JSON payload for the target API
The connection you selected already carries the X-Relay-Key header, so you do not set it in the flow step.
Alternative: the HTTP action in Power Automate
If you use Power Automate (premium) rather than a custom connector, the built-in HTTP action can call the relay directly. It also has no proxy field, so it calls the relay URL the same way:
- Method: POST
- URI: your relay function URL
-
Headers:
X-Relay-Key: <your relay secret> X-Target-URL: https://api.example.com/v1/orders Content-Type: application/json - Body: the JSON payload for the target API
Store the relay secret in Azure Key Vault or a secure input rather than pasting it as plain text in the flow.
Step 3: test that calls exit from your static IP
QuotaGuard runs an IP check endpoint that echoes the source IP it sees. Point the relay at it and confirm the returned IP matches your dashboard.
Set X-Target-URL to the IP check endpoint and call your connector action (or the HTTP action):
- X-Target-URL:
https://ip.quotaguard.com
The relay forwards to ip.quotaguard.com through QuotaGuard and returns:
{"ip":"<one of your two QuotaGuard static IPs>"}
The returned IP must be one of the two static IPs shown in your QuotaGuard dashboard. Call it a few times. Because the two IPs are load balanced, repeated calls show both addresses over time. Allowlist both on every destination API.
You can also test the relay directly, outside Power Apps, before wiring the connector:
curl -X POST "https://<your-relay-function-url>" \
-H "X-Relay-Key: <your relay secret>" \
-H "X-Target-URL: https://ip.quotaguard.com"
A matching IP here confirms the relay and QuotaGuard are working, so any later failure is in the Power Apps connector config.
Troubleshooting
401 or 403 from your relay (“relay key mismatch” or similar)
The X-Relay-Key sent by the connector does not match the secret on the relay. Recheck the connection’s API key value in Power Apps and confirm it equals the secret set on the relay function. Recreate the connection after changing the key.
Wrong IP returned by ip.quotaguard.com
The relay is not egressing through QuotaGuard. Confirm QUOTAGUARDSTATIC_URL is set in the relay function environment and that the relay code routes the outbound request through it. If the value is missing, the function calls out from its own cloud IP, not your static pair.
Destination API still returns 403 from a non-allowlisted IP The target sees the correct QuotaGuard IP but has not been told to trust it. Allowlist both IP addresses from your QuotaGuard dashboard on the destination, not just one. Load balancing means either IP can be the source on any given call.
Power Apps error: “The response is not in a JSON format”
The custom connector expects a JSON response but the relay or target returned something else (an HTML error page, an empty body, or a redirect). Test the relay with curl first, then confirm the target endpoint and method are correct in X-Target-URL.
Connector call times out The target API is slow, or the relay is in a distant region. Power Platform connector requests have platform timeout limits. Deploy the relay in a region close to both the target API and your chosen QuotaGuard region, and keep the QuotaGuard region matched to the relay.
“Invalid connection” or the connection prompt reappears The API key connection was not saved, or the connector was republished after the connection was made. Recreate the connection, then re-add the data source in the app. Power Apps caches connector definitions and needs a refresh after a connector change.
QuotaGuard Static vs QuotaGuard Shield
Static is right for standard HTTPS API calls. The payload is tunneled end to end and is never decrypted at the proxy. Shield adds TLS on the hop between your relay and the proxy itself, which is what regulated workloads (HIPAA, PCI-DSS, SOC 2) require.
| Feature | QuotaGuard Static | QuotaGuard Shield |
|---|---|---|
| Protocol | HTTP / HTTPS / SOCKS5 | HTTPS / SOCKS5 over TLS |
| Customer-to-proxy hop | Plaintext | TLS-encrypted |
| HTTPS payload | Tunneled end-to-end, never decrypted at the proxy | Tunneled end-to-end, never decrypted at the proxy |
| Best for | Most apps | Regulated data or environments that require TLS on every hop |
| Starting price | $19/month | $29/month |
Static (from $19/month, direct) is right for most Power Apps relays. Choose Shield (from $29/month, direct) 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.
Read: Static IP for platforms with no HTTP proxy