One of the best things about Power Automate ane the Power Platform is connectors, there are over a thousand, covering nearly all of you needs, with zero effot.
But what about those API's that there is no connector for, well Microsoft has got your back, and in its normal manner it has a few ways to do it.
So this blog Im going over the 3 main ways to connect with custom api's in Power Automate
- The Wrong Way
- The Right Way
- The Crazy Way
1. The Wrong Way
I'm going to upset a lot of people with what I'm about to say, but the HTTP connector is not the right way to connect to custom api's*
The asterisk is because there is 2 fringe cases where it is the right.
Before we talk about when its ok, lets talk about why it's not the right for normal connections.
And the simple fact is it is not as secure as other options. Using the HTTP action moves the authentication into the runtime, which introduces vectors of risk.
These are the main risks:
Credential Storage
Credentials have no default place to store them securely. If you want to use a HTTP action with auth, you need to save Passwords, API Keys, OAuth Secrets, Tokens somewhere.
Now there are places to store them, like credential banks like CyberArk, or Azure Key vaults. But having to access these can add (admittedly very very small) exposure to the vaults, a great example is Azure Key vaults have to be publicly accessible for the Power Platform to use them.
I know that Microsoft will say this is fine, but some orgs don't like it, especially with the risk of new frontier LLMs. Add in you can't add urls or service tags to Key vaults, only individual IP's, and it can be a security headache you don't want to deal with
Credential In Transit
HTTP action requires the auth credential to be handled in the flow run time, which means they will appear in the logs. The good news is there is secure inputs/outputs, but although that fixes the problem, its not totally perfect
- Requires the developer to turn on
- Impacts debugging
Data Exposure
This is one that is easy to miss, but if you are posting data through the HTTP action, and that endpoint is dynamic, either through action inputs or environment variables, then it is possible for them to be edited and data sent to a bad actor.
Again we have controls, like HTTP endpoint filtering in DLP (if you are not using this then you need to!). But again we are adding overhead and more potential points of failure.
So as you can see, we really shouldn't be using them, but hey David what about that asterisk, and if they are so bad why did Microsoft add them, good question.
So there are 3 times I would use them, and one of them is a very unlikely.
PoC
If you are building a flow to see if its possible, or generally as part of a incremental built out, then using the HTTP action totally makes sense. It allows quicker incremental building, working in one UI and workstream. Once you have everything working you can take the learnings and move to a more robust solution.
No Auth
Yep there are times when the API (or in some cases using it to web scrape pages, check our my previous blog about how to How to web scrape with power automate cloud. In these cases we now remove handling auth and any sensitive data (if you are pushing sensitive data to an endpoint with no auth you have bigger issues to deal with).
So yep that is a good use case, and one I have used a few times.
Super unlikely
If you have a flow that has to handle dynamic endpoints, then this maybe your only option. In these cases you get sent a dynamic url with auth, these are normally used for file sharing. In most cases they use the same base url, so you might be able to use other ways, but in those niche cases, this is your only option, and the risks become necessary.
2. The Right Way
I'm pretty certain you already know the right way, but just in case its...... a custom connector.
Custom connectors allow you to use the built in connector/connection bank built into the Power Platform. Now all of the auth is handled outside of runtime, with the auth created during build/deployment, and never even touching the flow runtime.
On top of the auth the endpoints are pre-built, ensuring that there can be no changes without change control.
Custom Connectors do come with draw backs, in particular:
- ALM - they have to be deployed/updated across all environments
- Gateways - don't play nice with gateways, only allowing windows and basic auth.
- They don't support all auth, tools like APIGEE are often configured with client OAuth, and these don't work with Custom Connectors.
But the simple truth is they are worth the trade offs (and you cant use gateways with HTTP actions so meh). Improved your risk vector for some additional administration is 100% worth it, and in theory nearly all security practices add administration, and we always follow them.
3. The Crazy Way
This one is a bit silly, but I wanted to call it out. If you are using an API that is from a vendor that does not have a connector, you can always make and submit your own.
Microsoft allows 'Independent' publishers to create connectors. This means you, me, or anyone can create connectors, submit them to Microsoft and they become available (Service Now is a good example, its not made by Service Now, but Microsoft as an Independent Publisher.
Don't get me wrong, this is A LOT of work (again another previous blog about how and how painful here), but in some cases it might be worth it.
You remove complexity around ALM (though add a more painful one with publishing), but more importantly you help others out. A big thing about the Power Platform is the community and helping out (you are reading a free blog made purely to help you), so I like the idea of sharing your learnings and effort with others.
4. Secret Bonus way
There is one more kind of way to do this, and this is my favourite connector the HTTP with Microsoft Entra ID (preauthorized)'.
This connector is amazing for 2 reasons, first it uses Entra SSO, so the auth is simple, no SPNs, no Key vaults, everything done the normal way. Second is it can access anything within the Microsoft world. That's all of the Grap API (so every office software etc), but also some Azure services.
And as the connection is linked to the endpoint url, it should be pretty secure (the input url should never be dynamic because it is related to the connection. This symbiosis ensures that it cant be changed), and it stores all credentials in the connection/connector vault, win.
Shock horror, I've already done a blog about the connector, check it our here 😎
There you have it, there are lots of ways to access non standard API's in Power Automate, but as always there is a right and wrong way. The wrong way can often feel like the easy way, and you may get pressure from enterprise architects and others who do not understand the platform, and just want the easy way. But as a developer or administrator its your job to do it the right way, even if that can add a little effort.
Top comments (0)