Calling Api different Approaches

(0) Share

Report

Posted on by enes

150

Hi All,

I noticed there are different ways we can call API's in our Power pages project.

1. We call it through Power Automate HTTP action.

2. We can call it through Power Automate using a custom action.

3. We can call an azure function which will call the API.

I don't understand the difference between these approaches. Do I get any advantage if I use power automate instead of azure function?

Categories:

General topics

I have the same question (0)

All responses (8)

Answers (2)

Verified answer

oliver.rodrigues 9,425 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!
Power Automate

Pros:

has many connectors to lots of systems and application

low-code/no-code, can be achieved by citizen developers

Cons:

API call happens async, depending on your need you might face caching issues on Power Pages

Azure Functions

Pros:

you have access to the source-code, so you have full control of the API call

you will define how you would like the call to be made, so would probably not face caching issues on Power Pages

Cons:

requires a pro-dev

dev effort is usually higher than using Power Automate

Was this reply helpful? Yes No
enes 150 on at

Like (0)

Report
Copy link

Link copied!

Thanks @OliverRodrigues

Which one is easier to maintain in terms of exporting/importing and deploying the project into new environment?

Was this reply helpful? Yes No
Fubar 8,487 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

@OliverRodrigues HTTP Request, runs it synchronous.

@bssienes One of the other considerations is Security, and how can you ensure that calls that are made are coming from the Portal and if so is that user authorized to make such a call..

Implicit Grant Flow is the mechanism supported by the portal https://learn.microsoft.com/en-us/power-apps/maker/portals/oauth-implicit-grant-flow

The other way is to trigger something in a way that a real-time dataverse plugin or workflow can be triggered, and have the results available on the next page you redirect to.

Was this reply helpful? Yes No
enes 150 on at

Like (0)

Report
Copy link

Link copied!

Hi @Fubar
My main goal is to securely call an API from the portal at the click of a button. I am not sure what is the best way to do this but many people in this forum suggested to create HTTP request trigger in power automate and then call the API from there. To secure the HTTP request trigger we can use the trigger condition as shown below so that only the portal can trigger this flow.

I am not sure about the implicit grant flow, I am new to all of this. Is this a place to store my API keys so that I can call the API directly from the portal?

Or does it add another stage of security for calling the power automate flow? That's what I understand by reading this post: https://powerusers.microsoft.com/t5/Power-Apps-Portals/How-to-secure-the-flows-that-called-from-the-portal/td-p/867032

Was this reply helpful? Yes No
oliver.rodrigues 9,425 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

@Fubar sorry yeah, the HTTP request to flow may run Sync, but the Flow itself would run Async, which leads to caching issues

Was this reply helpful? Yes No
oliver.rodrigues 9,425 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

@bssienes what is your API doing? what will be the result? do you need to know the result in real-time on the Portal page? or will you simply send the request and display a generic message to the user like "thanks your request is being processed"?

Was this reply helpful? Yes No
enes 150 on at

Like (0)

Report
Copy link

Link copied!

Hi @OliverRodrigues

Sorry, I am new to this, what are you referring to by caching issues? Any examples on what kind of error this may cause?

I am calling the stripe api to add a credit card, display the credit cards on the portal, add a customer, make a payment etc.

So I need the response in the portal.

Was this reply helpful? Yes No
Verified answer

Fubar 8,487 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

I believe the potential cache issue that Olive is referring to is that the Portal talks directly to a cache, any 'main' record that is created/updated from the Portal updates both the cache and Dataverse (so its data is available straight away as it is already in the cache), but 'non-main' records and records that are created in Dataverse from another user interface (e.g. via a Model Driven or Canvas App) are only pushed to the cache periodically (whilst this usually happens in less than a few minutes the SLA for it is actually 15min).
So if your Flow for example created a record in Dataverse, that record would not be available on the portal straight away (and could take a few minutes for it to become available) as the HTTP Flow is not part of the caching mechanism. But if all you need is data that is in the response from the HTTP call then not an issue.

The Trigger Condition on the flow trigger allows you to lock it down somewhat, but to do it more robustly you would also implement Azure API Management on the URL. It all depends on what you are doing as to how secure it would need to be in some cases having a Trigger Condition would be adequate in others it may not be.

Was this reply helpful? Yes No