Forum Discussion
How to Send POS Sales Data from Power Apps to Corporate API via Power Automate Using Static IP
I am currently using a POS system built with Power Apps, where sales transaction data is saved into SharePoint using Power Automate Cloud. From the Power App, users explicitly click a button to trigger a Power Automate flow, which then sends the sales data to an external corporate company’s database through an HTTP API. The corporate system enforces strict security policies and only accepts incoming requests from a whitelisted static public IP address.
Since Power Automate Cloud runs in a Microsoft-managed multi-tenant environment, its outbound traffic originates from dynamic and shared IP addresses, which cannot be directly whitelisted. Due to security and compliance requirements, the solution must remain 100% cloud-based, and the use of Power Automate Desktop, on-premises data gateway, or any locally executed components is not permitted.
I understand that Power Automate Cloud alone cannot provide a static outbound IP, and that the recommended pattern is to route outbound API calls through an Azure-hosted intermediary (such as Logic Apps single-tenant or a similar service) configured with a static public IP, which Power Automate Cloud can call via HTTP. I would appreciate confirmation that this is the correct and supported architecture, and any guidance on the simplest cloud-only approach for this scenario.
Thank you in advance for your support.
2 Replies
The issue stems from a mismatch between modern saas integration patterns and legacy perimeter based security controls, Power automate cloud abstracts infrastructure completely, removing the ability to guarantee a x fixed outbound network footprint.
hi Sho You’re not missing anything here, this is a very common limitation with Power Automate Cloud.
Short answer: Power Automate Cloud can’t give you a static outbound IP, and there’s no supported way to make it do so. Because it runs in a shared, multi-tenant environment, the outbound IPs are dynamic by design.
What you’re describing routing the call through an Azure-hosted intermediary with a static IP is exactly how most teams solve this. The typical pattern looks like this:
Power Apps → Power Automate (Cloud) → Azure service (static IP) → Corporate API
In practice, people usually pick one of these:
- Logic Apps (single-tenant) in a VNET with a NAT Gateway
- Azure Functions (App Service plan, not Consumption) with VNET + NAT Gateway
Both options stay 100% cloud, give you a fixed public IP to whitelist, and are fully supported. Power Automate just calls the Azure endpoint over HTTPS, and that service forwards the request to the corporate API.
Why this works well:
- Meets strict IP allow-listing requirements
- No on-prem gateway or Power Automate Desktop
- Easy to add logging, retries, validation, and auth in one place
- Scales cleanly as volume grows
So yes, your assumption is correct, and you’re already aligned with the recommended architecture. Power Automate handles the workflow, and Azure handles the networking constraints.
