The connectors are the life blood of Power Automate, they give it it's power, but what is a connector. It's an API wrapper, with predefined input and output schemas. This has 3 big benefits:

• Authentication - connections stored in the platform
• Simplicity - we know what we need
• Lookups - you may need an id as an input but the connector shows display names in the selector

So connectors are perfect, well not quite. With most API's there are far too many end points to invest in to creating a connector for, and that's where HTTP connectors come in. They have benefits of authentication, but allow you to enter any/additional end points.

In Power Automate we currently have 8 HTTP connectors:

1. HTTP
2. SharePoint
3. Outlook
4. Office 365 Users
5. Office 365 Groups
6. Office 365 Groups Mail
7. Azure DevOps
8. Azure AD

1. HTTP

This is the one we all think of, it's incredibly flexible and allows you to call any HTTP end point, additionally it allows all different authentication methods.

But, and here is the big but, everything is stored in plain text within the connector:

Client Secret visible

Password visible

For this reason, HTTP connector should only be used for unsecured end points, it can be a great tool to test, but if authentication is needed a custom connector should be used.

Example use case:

• Open API's quickchart.io
• Downloading Images

2. SharePoint

There are a lot of SharePoint actions (50 and growing) so you may not think there is much need for a HTTP connector, but there are a couple of cool benefits.

Additional End Points
50 may sound like a lot, but there are more, just try /_apo/Web on a site, it will list all the end points.

There are loads of niche cases where the HTTP connector will save you.

Example Create Subsites

Additional Control
The connectors have some functionality, but not all, so the HTTP connector allows us additional functionality.

My 3 favourites are:

Header OData verbose -
This one line will speed up your API by up to 92% on its own. When you request items from a SharePoint list it returns not only the data, but all of the meta data (like urls, author, thumbnails, etc). These extra fields are often bigger than your data and have relationships with other lists. By selecting 'verbose' the connector returns none of this. For more info click here

Query parameters -
You are limited to filters with the connectors when getting items, but with the API there is a lot more control: :

• $select - only return selected fields
• $skiptoken - skips to set place in list
• $Expand - returns for then just the id for lookups

Additional Permissions -
Certain fields are locked in the connector, but with HTTP you can still edit them. Check out below where I am able to change Modified by, Modified, Created by, and Created:

Example use cases:

• Update Site Theme
• Update Site Quick Menu
• Set Field Theme/Formatting
• Save to Draft
• Restore Version

3. Outlook

Another one with lots of connectors (34 at time of publish), but there are still loads of additional end points. Additionally we have some more functionality, one I use a lot is the Get Emails. With the connector we are limited to 25 emails:

But with the HTTP request we don't have that limit. Additionally we can also skip emails and return in blocks (So if you do hit a limit you can use a DoUntil and return in blocks, there is even an
@odata.nextLink: key in the json which populates the url for the next block)

Example use cases:

• Create folders in mailbox
• Create/Delete Mailbox Rules

4. Office 365 Users

This is where it gets strange, admittidely this is in preview, but not only could I find no use (all actions covered except beta endpoints, and fully functional) I could not get it to work, it was acting like it was the Outlook HTTP connector.

Example use cases: none

4. Office 365 Groups

Another interesting one, there is a bug in version 1 of the connector that allows you to call graph API end points beyond just groups. This bug makes it more powerful 😎

Version 2 has very little additional functionality beyond the current connectors, so no real use. But while version 1 exists we have a universal graph API connector. We can not only use it for SharePoint Outlook etc, but for missing end points like teams.

Example use cases:
Version 2 - None
Version 1 - All other graph HTTP connectors uses and missing HTTP like Teams

6. Office 365 Groups Mail

I must admit I have never had a use case for the Groups mail connector so I may have missed something. But I can't find any end points or additional functionality over the connectors.

Example use cases: none that I can find

7. Azure DevOps

Again I never had a use case for this, but when comparing the connectors with available API's I can't see any missing functionality.

Example use cases: none that I can find

8. Azure AD

Now this is where it gets extra cool (and yes I have a strange idea if cool), this connector is a little bit like Office 365 Groups version 1, as in we can use it for any Graph API endpoint. But it gets better, it can actually call any end point that authenticates with AAD on your tenant.

To use it is a little different, as the url for the root is configured with the connection (so you create a new connection to each root end point).

Once signed in we can add the unique end points.

Example calling OneDrive graph API

Example bulk downloading form responses and creating file

Due to the scope of the accepted urls, although little clunky in setup, in my opinion it is the most powerful http connector.

Example use cases:

• All other graph HTTP connectors uses and missing HTTP like Teams
• Additional Forms functionality
• Dataverse End points
• Flow Runs (None solution aware)

There is one more thing to be aware of, and that's new end points and features. Where today the HTTP connector might have little use, not having to wait for a new connector to be made allows us to use those new features earlier.

Further Reading

• Graph API Explorer
• Graph API
• MS Learn SharePoint API
• https://hevodata.com/learn/sharepoint-api/