Calling REST APIs with the HTTP Action

1. The HTTP Action Landscape in Power Automate

Before we dive into a specific implementation, it's important to understand that Power Automate offers several actions for making HTTP requests. Choosing the right one is the first step in building a robust integration.

The video below provides a great overview of the main HTTP-related connectors.

To summarize, you have three main choices:

1. Send an HTTP request to SharePoint: Highly optimized for the SharePoint REST API. It handles authentication seamlessly within the SharePoint context.
2. HTTP with Azure AD: Designed for calling APIs secured by Azure Active Directory, most notably the Microsoft Graph API. It simplifies authentication by using the logged-in user's identity or a pre-configured service principal.
3. HTTP (Generic): This is the most flexible action and the primary focus of our lesson. It can call any RESTful endpoint and provides several built-in authentication options, or allows you to handle authentication manually.

2. Calling a Public API (No Authentication)

Let's start with the simplest case: a public API that doesn't require any authentication. This allows us to focus on the core mechanics of the generic HTTP action.

The key parameters you'll configure are:

• Method: The HTTP verb (GET, POST, PUT, PATCH, DELETE).
• URI: The URL of the API endpoint.
• Headers: Key-value pairs, such as Content-Type.
• Body: The payload for POST or PUT requests, typically in JSON format.
• Queries: URL query parameters, which can be added to the URI or defined in this field.

This video demonstrates a practical example of calling a public API.

This first step is straightforward and serves as a good warm-up for the more complex scenarios involving authentication.

3. Implementing API Key and Basic Authentication

Now, let's add a layer of security. Many APIs use either an API Key or Basic Authentication.

API Key Authentication

An API key is a simple token that the client provides when making API calls. It's often used to identify the calling project for usage and billing purposes. The key is typically sent in one of two ways:

1. As a query parameter in the URL (e.g., ?api_key=YOUR_KEY).
2. As a custom HTTP header (e.g., X-API-Key: YOUR_KEY). Sending the key in the header is generally the more secure and standard practice.

The next segment of the video you just watched demonstrates using an API key as a query parameter.

Basic Authentication

This method uses a standard Authorization header containing a Base64-encoded string of username:password. While you could construct this header manually, the Power Automate HTTP action has built-in support for it, which simplifies the process considerably.

The following article provides a clear, practical guide to implementing both Basic Auth and API Key Auth (via headers) in the HTTP action.

4. Handling OAuth 2.0 Authentication

OAuth 2.0 is the industry standard for authorization. For a developer, handling the OAuth flow is a common task. In Power Automate, you have two primary ways to approach this.

Method 1: Using Built-in Azure AD / OAuth Helpers

For APIs secured with Azure Active Directory (AAD), Power Automate provides fantastic built-in support that handles the token acquisition flow for you.

• HTTP with Azure AD Connector: As mentioned earlier, this is the simplest way to call Microsoft Graph. It uses the connection's identity to authenticate automatically. The video below shows how to use it.

• Generic HTTP action with Active Directory OAuth: For more control, the generic HTTP action has a dedicated authentication type for AAD. You provide details like the Tenant ID, Audience, Client ID, and Client Secret from an Azure App Registration, and the action performs the token exchange behind the scenes.

Method 2: The Manual OAuth 2.0 Flow

For many third-party APIs that use OAuth 2.0 but are not on Azure AD, you'll need to perform the authentication flow manually. This typically involves a two-step process, which will be very familiar from your .NET development experience:

1. Step 1: Get the Bearer Token. Make an initial HTTP POST request to the API's token endpoint. You'll typically send your client_id, client_secret, grant_type (e.g., 'client_credentials'), and scope in the request body. The response will contain an access_token.
2. Step 2: Call the API. Make the actual API call (e.g., a GET request to fetch data), including the access_token from Step 1 in the Authorization header, prefixed with "Bearer ".

This pattern is essential for a Power Platform developer. The following article provides a superb walkthrough.

The flow for this pattern typically looks like this:

Conclusion

You've now seen how to use Power Automate's HTTP actions to connect to virtually any REST API, handling the most common authentication schemes. This is a powerful capability that dramatically extends the reach of your automations.

Key Takeaways:

• Choose the right tool for the job: use the specialized SharePoint or Azure AD HTTP actions when applicable, and the generic HTTP action for everything else.
• The generic HTTP action has built-in support for Basic and Active Directory OAuth, which simplifies configuration.
• API Keys can be passed as query parameters or, more securely, as custom request headers.
• For many third-party APIs using OAuth 2.0, you must implement the manual two-step flow: one action to get the token, and a second to use it.

What's Next

While the HTTP action is incredibly flexible, using it repeatedly for the same API across multiple flows can lead to duplicated effort and maintenance headaches. A much more professional and scalable approach is to encapsulate the API's definition and authentication logic into a reusable component.

In our next lesson, we will do exactly that. We'll learn how to create a custom connector for a REST API using API Key or Basic authentication, turning the ad-hoc calls we made today into a first-class citizen in the Power Platform connector ecosystem.