Power Automate API Integration: Questions Before You Build

Power Automate API Integration: What to Decide Before the First Connector

By Michael Branson | September 7, 2026

Quick answer. Power Automate API integration turns on five decisions the platform leaves to you: the connector, the authorization, the connection, the request budget, and the change owner. Each one is a named answer with a named person against it, settled before the first action is built.

The request that starts this work is a plain one. Two systems hold the same information, somebody is rekeying it between them, and Power Automate is already licensed. A maker builds a flow, it works, and the rekeying stops. The trouble arrives later, and it lands somewhere other than the logic: the flow runs under one person’s credentials, calls an endpoint nobody documented, and shares a request pool with everything else the tenant automates. When the vendor changes the API, the flow stops, and the question of who fixes it has no answer written down.

That is not a Power Automate defect. The platform turns an API into a working integration quickly, which is why it gets chosen, and the five decisions below are the ones that speed skips past. Each is cheap to make before the first action exists and expensive to retrofit once other flows depend on the answer.

Five Decisions the Platform Leaves to You

These are not the estate-level integration questions. Scope, systems of record, field mapping and validation, credential placement, and estate-wide recovery design belong to the live System Integration Best Practices for Microsoft Enterprises page, and the closing section of this page carries the link to it. What follows sits one layer down, at the flow: the choices a maker makes inside Power Automate that an estate-level standard does not reach.

Two things about this table are load-bearing. The rightmost column names a role, and the copy you keep replaces each role with the name of the person who holds it, because a decision owned by a committee is unmade on the day it is tested. The third column names something somebody can open and read, so a claim about the integration can be checked instead of believed. Where the two owners in a row disagree, the one who carries the consequence decides: on the authorization, the owner of the system being called, because that team carries the damage from a wrong write.

The Connector: Prebuilt, Custom, or the HTTP Action

“Connect our systems” is one sentence in a request and three different builds in Power Automate, and the difference shows up in who maintains the result. A prebuilt connector for a system Microsoft already covers is the cheap answer and the right one when it exposes the operations you need. The two harder cases are a system with an API nobody has wrapped, and a system whose API you intend to call directly.

A custom connector is the durable answer for the first case. Microsoft’s Custom connectors overview describes it as a wrapper around a REST API that allows Logic Apps, Power Automate, Power Apps, or Copilot Studio to communicate with that REST or SOAP API, and sets out a six-step lifecycle: build the API, secure it, describe it and define the connector, use it, share it, and certify it. Two of those steps carry the decisions people skip. The securing step names the standard authentication methods a connector may use, generic OAuth 2.0, OAuth 2.0 for specific services including Microsoft Entra ID, basic authentication, and API key, with Microsoft Entra ID recommended among them; picking one is an architecture decision, not a configuration detail. The sharing step is where a connector stops being one maker’s asset: sharing is optional, and certification, which submits the connector to Microsoft, is what makes it available to all users of Power Automate, Power Apps, Logic Apps and Copilot Studio rather than to your organization alone.

Calling the API directly is the second case, and it is the one worth being explicit about. Microsoft’s HTTP with Microsoft Entra ID (preauthorized) connector is documented to fetch resources from web services authenticated by Microsoft Entra ID, or from an on-premises web service, and it is a premium connector in Power Automate. It is also documented with two boundaries that decide the design for you. It encodes the request body into base64, so it suits backend services that expect the body in that form, and it cannot be used to call a backend service that expects the request body in raw binary format. Its published throttling limit is 100 API calls per connection in 60 seconds, which is a design input the moment an integration processes items in bulk.

One rule settles the choice: use the HTTP action for a call that stays inside one flow and is owned by that flow’s owner. When a second flow calls the same API, or when the endpoint, the authentication, or the payload shape will outlive the flow that first needed it, wrap it in a custom connector so there is one place to change it. An integration built from HTTP actions scattered across flows has no such place, which is where the “who fixes it when the API changes” conversation usually starts.

The Authorization: Whose Permissions the Flow Carries, and Where Service Account Sprawl Starts

Every call a flow makes runs under some identity, and the identity is chosen when somebody creates a connection rather than when somebody designs the integration. That ordering is how service account sprawl begins: a maker needs a flow to read a system ordinary users cannot reach, an administrator creates an account for it, the flow works, and the account outlives everyone who knew why it existed.

Three answers are defensible inside Power Automate, and they suit different jobs. The signed-in user is the answer for a flow a person triggers, and it holds only where that person provides the connection rather than running on one somebody else stored, because then the flow reaches what that person reaches and existing permissions keep working. A named person’s credentials, usually the maker’s, is the answer that looks easiest and ages worst: the flow carries that individual’s reach to everyone who can trigger it, and it stops when that individual’s account is disabled. An application identity is the answer for a background integration that runs on a schedule or a webhook, where there is no signed-in user to borrow from. In Dataverse that identity is an application user, created from an app registration in Microsoft Entra ID and assigned security roles, and it is visible on the Application users page in the Power Platform admin center, which is also where somebody can check which application identities an environment holds.

The point buyers miss is that this decision has a metered consequence as well as a security one. Microsoft’s Requests limits and allocations documentation sets a separate, tenant-pooled limit for activities that do not require user interaction, and names the identities that draw on it: application users, non-interactive users, administrative users, and the SYSTEM user. It answers the sprawl question directly. No, each of those identities does not get its own tenant-level limit; all application users, non-interactive users, administrative users, and system users within the tenant share tenant-level limits. Adding a service account does not add capacity, it adds a claimant on a pool that other automation is already drawing down.

That documentation also names the exit. A Power Automate cloud flow owned by a service principal does not draw on the non-licensed user pool if it has a Process or per-flow license, belongs to a flow group with a Process license assigned, or has a designated licensed user, in which case the flow uses that user’s action limits. So the authorization decision and the licensing decision are one decision, taken together at design time or discovered together in production. Where the estate’s broader security posture around these accounts is the live question, the operating side of it is treated in Securing Power Automate in Regulated Enterprises, and this page assumes rather than repeats that program.

If the argument about whether a flow gets its own identity keeps reopening between your platform and identity teams, the useful next step is a conversation with somebody outside the argument. Talk to a senior workflow automation architect

The Connection: Who Owns the Stored Credential

Connections behave less like code and more like people, which is why they cause the outages nobody predicted. Microsoft’s guidance on how to Use a connection reference in a solution with Microsoft Dataverse states the mechanics plainly: a connection is a stored authentication credential for a connector, for example OAuth credentials for the SharePoint connector, and a connection reference is a solution component that contains a reference to a connection about a specific connector. Solution-aware canvas apps and the operations inside a solution-aware flow bind to that connection reference instead of binding directly to a connection.

That indirection is what makes an integration movable between environments, and it is worth building in from the start for anything that will exist in more than one. It does not, on its own, answer the ownership question. The same documentation records two constraints that decide how much of a problem ownership becomes: when a flow is turned on by the owner of the connections it uses, the flow gets explicit permission to use those connections, and ownership of a connection reference cannot be transferred to another user from the Solutions area in Power Apps. So a departure is also a question about which flows were enabled under whose credentials and what has to be re-established by somebody else.

This is inspectable before it becomes an incident. Permissions granted to apps and flows using a connection can be seen on the details page for that connection, in its Apps using this connection and Flows using this connection tabs. That page is the surface to read when somebody asks what a service account is holding up, and it is worth reading during design instead of during an outage. One further constraint interacts with the connector decision above: canvas apps do not recognize connection references on custom connectors, so a design that assumes uniform behavior across the artifact types in one solution is untested.

Three rules turn this from mechanics into an operating position. Connections that back an integration are owned by a role, not by whoever happened to build the flow, and the record says which role. A connection whose owner leaves triggers a review of the flows bound to it before the account is disabled, because disabling first turns a governance event into an outage. And a connection created for one integration is not silently reused by a second one without the first integration’s owner agreeing, because reuse quietly widens the blast radius of a credential rotation.

The Request Budget: What the Integration Consumes

Request limits are the design input teams meet last, and the one to settle first when an integration calls an API once per item in a list. Microsoft’s Requests limits and allocations documentation, cited above, states that you can make only a limited number of requests each day across Power Apps, Power Automate, Microsoft Copilot Studio, and Dynamics 365 applications, and that those limits are based on a user’s assigned license. The allocation is counted over a 24-hour period, and 40,000 requests per paid license per 24 hours is the documented figure for the paid Power Platform and Dynamics 365 licenses, with Power Apps per app, Power Automate per flow, Microsoft Copilot Studio and Dynamics 365 Team Member documented separately at their own figures. Background identities, as the authorization section set out, draw on a separate pool defined at the tenant level and shared.

Two questions follow, and both belong in design instead of in a post-incident review. The first is volume: how many calls does this integration make on an ordinary day, and on the worst day the source system can produce. An integration that walks a list and calls an API per item has a request profile shaped like the list, so the useful question is what bounds the list. The second is where the budget is charged: to a licensed user, to the tenant’s background pool, or to a flow with capacity reserved for it. The flow details page’s Analytics view, on its Actions tab, is where a flow’s action count is read once it is running, so a design that predicts a number is a design somebody can check later.

Retry behavior sits in the same category, as an input and not as an afterthought. A retried call is another call, so retry settings and request budgets are one conversation. A retry against a system that is not safe to receive the same request twice converts a transient failure into a duplicate record, which is the kind of defect reconciliation exists to catch. The design questions here are whether the receiving endpoint is safe to call again, what the flow should do when retries are exhausted, and where a failed item waits for a human. Those questions are error architecture, and the companion Workflow Error Handling and Recovery page carries them; it is not yet published. This page stops at naming them as inputs to the connector, authorization and budget decisions above.

There is a reason to settle this before a build instead of after one: request budgets and retry behavior interact with each other and with the identity decision, and they are cheapest to reason about while the design is still a diagram. Talk to a senior workflow automation architect

The Change Owner: Who Fixes It When the API Changes

The API on the other side of an integration changes without asking. A field is renamed, an authentication method is deprecated, a version is retired, a rate limit is tightened. The flow does not adapt, and the interesting question is not technical: it is who notices, who is allowed to change the flow, and who decides whether the change is urgent.

Where nobody is named, the first part gets answered by accident and the rest not at all. The flow fails, somebody in the business notices that records stopped arriving, and a search begins for whoever built it. That search is the cost. The fix is a record, kept per integration, answering four questions: which external API it depends on, where that vendor publishes change and deprecation notices, who is accountable for reading them, and who is authorized to change the flow. A custom connector helps in a specific way, because it puts the endpoint, the authentication method and the payload shape in one artifact somebody can version, and the environment’s custom connector inventory lists the ones that exist.

Two operating rules make the record useful. An integration with no named change owner is treated as a risk item at review, because a working integration with nobody accountable for it is a future outage with an unknown response time. And the change owner is named at the point the integration is approved, not at the point it breaks, because the negotiation about who does this work is much easier before anybody is under pressure.

Detection is the other half, and it belongs to the operate phase. A flow that fails loudly is a manageable problem; one that fails quietly, or half succeeds, costs money before anyone knows. That failure mode, and how to find it in an estate that already has flows running, is the subject of When Power Automate Flows Fail Silently: Finding the Risk, which this page assumes instead of repeating.

When This Is Not the Work You Need

Some readers should stop here, and saying so is cheaper than selling five decisions to somebody who needs a different conversation.

If the open question is which systems are in scope, which system is of record for a given entity, how fields map and validate between them, where credentials belong at the integration layer, or how retry and dead-lettering should work across an estate, those are estate questions and they are answered in full in System Integration Best Practices for Microsoft Enterprises. The five decisions set out here assume those answers exist and sit one layer below them.

Another open question is whether Power Automate should be the integration layer at all, and that is a platform choice, not a build decision. Power Automate is a poor fit where the integration is high volume and continuous, where the transformation is complex enough to need real code and real tests, where the receiving system demands transactional guarantees across several calls, or where the workload is a data pipeline that moves large volumes on a schedule. Those shapes belong to Azure Logic Apps, Azure Functions, Azure Data Factory or a purpose-built service, and the comparison against Logic Apps for workflow-shaped work is treated in SharePoint Workflow Automation: Power Automate vs Logic Apps. The comparison against writing custom integration code belongs to the companion Power Automate versus Custom Integration page, which is not yet published.

If flows are already running and the pain is operational, monitoring, support and the cost of keeping them alive, design decisions are not the intervention. And if you want the build delivered instead of the decisions framed, Power Automate Development & Integration Services for Enterprises describes that engagement.

What is left is the organization this page was written for: a licensed platform, a real API to call, a maker who can build the flow, and no written answer to the five questions above. i3solutions has been a Microsoft partner since 1997, and the fastest way to close that gap is to write the five answers down for the integration you are about to build, then check them against the one you built last year. Talk to a senior workflow automation architect

Frequently Asked Questions

What should we resolve before building Power Automate API integrations?

Inside Power Automate, resolve five things and write down a name against each. Which connector carries the call: a prebuilt connector, a custom connector, or the HTTP action. Whose permissions the call runs under: the signed-in user, a named person, or an application identity. Who owns the stored connection and what happens to the flows bound to it when that person leaves. What the integration is allowed to consume against the tenant’s request allocation. And who is accountable when the API on the far side changes. The wider estate questions, which systems are in scope, which one is the system of record, how fields map and validate, and how retry and dead-lettering are designed across an estate, are answered on the System Integration Best Practices for Microsoft Enterprises page.

How should authentication be handled in Power Automate integrations?

Choose the identity deliberately, at design time, from three defensible options. A flow a person triggers should run as the signed-in user where that person provides the connection, so it reaches what that person reaches. A background integration that runs on a schedule or a webhook has no signed-in user to borrow from and should use an application identity, which in Dataverse is an application user created from an app registration in Microsoft Entra ID and assigned security roles, visible on the Application users page in the Power Platform admin center. Running on a named individual’s credentials is the option that ages worst, because the flow carries that person’s reach and stops when their account is disabled. Microsoft’s Requests limits and allocations documentation adds a consequence people miss: application users, non-interactive users, administrative users and system users within a tenant share tenant-level limits, so adding a service account adds a claimant on a shared pool and not extra capacity.

How do we handle errors and reconciliation in automated integrations?

At design time, treat error behavior as an input to three other decisions rather than as a setting to configure later. A retried call is another call against the request budget. A retry against a system that is not safe to receive the same request twice creates duplicate records, which is the failure reconciliation exists to catch. And the question of where a failed item waits for a human decides who is on the hook for clearing it. The architecture that answers those questions, retry policy, idempotency, compensation and dead-lettering, is the subject of the companion Workflow Error Handling and Recovery page, which is being written and is not yet live. Detecting failures in flows that are already running is a separate operate-phase job, covered in When Power Automate Flows Fail Silently: Finding the Risk.

When is Power Automate the wrong integration layer?

It is the wrong layer when the volume is high and continuous, when the transformation needs real code and real tests, when the receiving system requires transactional guarantees across several calls, or when the job is a scheduled data pipeline moving large volumes. Work of that shape sits better on Azure Logic Apps, Azure Functions, Azure Data Factory or a service built for it. Power Automate is a good fit where the work is event-driven, the volumes are moderate, the transformation is modest, and the value is in removing rekeying between systems that people do by hand today. The honest test is whether a maker can own the result: where the answer needs a developer, a build pipeline and a test suite, the work has left the platform’s centre of gravity.

When should we build a custom connector instead of using the HTTP action?

Use the HTTP action when the call lives inside one flow and is owned by that flow’s owner. Build a custom connector when a second flow needs the same API, or when the endpoint, the authentication method or the payload shape will outlive the flow that first needed it, because the connector puts those three things in one artifact somebody can version. The connector is then listed in the environment’s custom connector inventory, where somebody can check whether one exists. Microsoft documents a custom connector as a wrapper around a REST API that lets Power Automate communicate with that REST or SOAP API, with a six-step lifecycle that includes securing the API, describing it, sharing the connector, and optionally submitting it for Microsoft certification. Two documented constraints on the HTTP with Microsoft Entra ID (preauthorized) connector also push toward a custom connector for anything demanding, and Microsoft documents both on that connector’s own reference page linked above: it encodes the request body into base64 and cannot call a backend service that expects the request body in raw binary format, and its published throttling limit is 100 API calls per connection in 60 seconds.

Who should own the connection a Power Automate integration runs on?

A role, named in writing, and not whoever happened to build the flow. Microsoft documents that a connection is a stored authentication credential for a connector and that a connection reference is a solution component pointing at one; solution-aware flows bind to the reference so the integration can move between environments. Two constraints make ownership consequential. A flow enabled by the person who owns its connections gets explicit permission to use them, and a connection reference’s ownership cannot be handed to another user from the Solutions area in Power Apps. Before an owner’s account is disabled, read the connection’s details page, in its Apps using this connection and Flows using this connection tabs, to see which apps and flows depend on it.

Related Reading

• Microsoft Integration Architecture for Large Enterprises: A Reference Guide for Regulated Sectors, the estate-level reference architecture these flow-level decisions sit inside
• Data Integration Risk Consulting for Regulated Enterprises, the assessment shape for an estate whose integrations are already built and already carrying risk
• Hire US-Based Senior Microsoft Integration Developers, the staffing route when the decisions are settled and the capacity to build is what is missing

About the Author

Michael Branson co-founded i3solutions and brings executive, operational, and technical perspective to organizations running complex, secure, and mission-critical Microsoft estates. He works with enterprise teams on the integration and governance decisions that determine whether a platform investment holds its value.