I ran into this building something internally: twelve flows, all calling the same internal REST API through the HTTP action, all with the same API key pasted into a header field. The key rotated. Eleven flows broke overnight, and the twelfth broke a week later because nobody remembered it existed. The fix is a Power Automate custom connector. By the end of this walkthrough you will have one connector with connection-level authentication, typed outputs in the dynamic content picker, and zero secrets sitting in flow definitions.
One thing up front so nobody is surprised: the HTTP action is premium and custom connectors are premium. You are not saving on licensing here. If you want to understand exactly what triggers premium licensing before you ship, How to Run a Power Platform Licensing Audit Before You Ship walks through flagging premium connectors and mapping user licenses. You are saving on secret sprawl, duplicated Parse JSON actions, and the maintenance cost of every flow knowing the raw URL.
Step 1: Capture the working request
Before you touch the connector wizard, get one successful call working in a plain HTTP action. You need four things written down: the method, the full URL, every header the API requires, and a real response body. Run the flow once and copy the raw JSON from the run history outputs. Save it somewhere. You will paste it into the connector definition in Step 4, and the quality of your dynamic content depends entirely on how representative this sample is. If a field can be null, make sure your sample shows it populated, or the schema inference will type it wrong.
Step 2: Create the Power Automate custom connector
Go to make.powerautomate.com, then Custom connectors under Data, then New custom connector. If you have an OpenAPI file or a Postman collection, import it and skip ahead. For an internal API you probably do not, so pick Create from blank. On the General tab set the scheme to HTTPS, the host to your API domain (api.internal.example.com, no protocol prefix), and the base URL to the shared path segment, for example /v2. Everything you put here is one edit away when the API moves. That is the whole point. The custom connector docs on Microsoft Learn cover the import paths if you go that route.
Step 3: Move the key into connection-level security
On the Security tab, choose API Key as the authentication type. Set the parameter label to something a human understands, the parameter name to the exact header the API expects (x-api-key in my case), and the location to Header. This is the step that pays for everything else. The key is now entered once per connection, stored encrypted, and never appears in the flow definition, the export package, or the run history. When the key rotates, you update the connection. Every flow using it picks up the change. Compare that to my eleven broken flows.
If your API uses OAuth 2.0, the same tab handles it, but you will need an app registration and a redirect URL. API key is the fast path for internal services.
Step 4: Define the action with Import from sample
On the Definition tab, click New action. Give it a summary and an operation ID that reads like a verb, because that text is what shows up in the action picker. Then hit Import from sample, set the method and relative path (/invoices/search), and paste the request body you captured in Step 1. Do the same for the response: open the default response, paste your saved JSON, and let it infer the schema.
This response schema is what kills the Parse JSON actions. Every field in your sample becomes a typed token in dynamic content. Instead of body('HTTP')?['data']?['invoiceNumber'] in a dozen flows, you get invoiceNumber as a pickable token. Untyped payloads always come back to bite you at the consumption end, and that same discipline around schema and parameter definitions applies when you are building tools for AI agents — How to Design Tool Definitions for Copilot Studio Agents covers exactly how typed outputs affect whether an agent selects and uses a tool correctly.
Step 5: Test the connection and swap the flows
Use the Test tab. Create a connection, enter the API key, fire the operation, and check the returned status code against what your plain HTTP action produced. Then go through your flows one by one: add the connector action, remap the inputs, repoint downstream references from the old body('HTTP') expressions to the new typed tokens, delete the HTTP action last. Do not delete first. You want the old expression text visible while you remap.
Since connectors are solution-aware, put the connector inside a solution before you build against it if this ever needs to move environments. Retrofitting that later is painful — understanding how solution layers decide which customization wins makes it much clearer why getting the connector into a solution early avoids hard-to-debug conflicts later.
The final state and the one pitfall
End result: one connector, one connection per environment, secrets out of flow definitions, typed outputs everywhere, and a single place to edit when the API changes. The maintenance profile of those twelve flows went from twelve edits to one. In my experience this is the single highest-return refactor available in a flow estate that grew organically.
The pitfall: custom connector requests have a hard timeout of 2 minutes. A plain HTTP action will happily wait longer with the right retry settings. If your API has a slow endpoint, a report generator, a bulk export, anything that can run past 120 seconds, keep that one call on the HTTP action or redesign it as an async polling pattern. I learned that one the hard way, staring at a 504 that the same request never produced from the raw action.
Frequently Asked Questions
What is a Power Automate custom connector and why would I use one?
A Power Automate custom connector is a reusable wrapper around an external or internal API that lets you call it from flows without hardcoding URLs, headers, or secrets. It centralises authentication and request configuration in one place, so when something like an API key changes, you update it once rather than hunting through every flow that uses the raw HTTP action.
How do I move an API key out of my flow definitions and into a secure location?
In a custom connector, you can configure API Key authentication at the connection level on the Security tab. You specify the exact header name the API expects, and the key is entered once when creating a connection, stored encrypted, and never written into the flow definition itself.
When should I replace HTTP actions in my flows with a custom connector?
If you have multiple flows calling the same API, sharing the same headers or secrets, or duplicating Parse JSON actions to handle responses, a custom connector is worth building. It reduces secret sprawl, cuts down on repeated configuration, and makes maintenance much easier when API details change.
How do I get typed outputs and dynamic content when building a custom connector?
You need to provide a real response body sample from a successful API call, which the connector wizard uses to infer the response schema. The quality of the dynamic content picker depends on how representative that sample is, so make sure any fields that can contain values are populated in the sample rather than null.
