Can Azure Logic Apps call custom routes in a Python FastAPI Azure Function App using the native Azure Functions connector?

Question

Can Azure Logic Apps call custom routes in a Python FastAPI Azure Function App using the native Azure Functions connector?

Elham 10

I have an Azure Function App written in Python. The application uses FastAPI (via azure.functions.AsgiMiddleware) to expose multiple REST API endpoints with custom routes.

I would like to call these endpoints from an Azure Logic App using the native Azure Functions connector.

However, when I try to configure the connector in Logic Apps and select the FastAPI entrypoint function, I encounter an error indicating that custom routes are not supported.

My questions are:

Does the native connector support Python Function Apps that use FastAPI through AsgiMiddleware, or does it require each endpoint to be implemented as a separate Azure Function with an HTTP trigger?

If this is not supported, is there an alternative way to achieve this while retaining the use of managed identity for authentication?

My goal is to keep my existing FastAPI application with multiple endpoints and invoke those endpoints from Logic Apps, with managed identity for auth.

Thanks in advance!

Hemant Bharadwaj 370 Reputation points Microsoft Employee

2026-11-12T16:39:00.14+00:00
The Functions connector’s discovery limitation is the key here: the documented Logic Apps Functions action expects a .NET or Node.js function app with C# or JavaScript HTTP-trigger functions. Custom routes are supported by that action only when the function has a corresponding OpenAPI definition, so a Python FastAPI ASGI entry point is not exposed as a set of individually discoverable Functions actions.

To keep the existing FastAPI routes, call each route’s HTTPS URL with the Logic Apps HTTP action (set the HTTP method, headers and body as your API requires). Alternatively, expose an OpenAPI definition for the API if you need a designer experience with operation schemas; the Functions documentation specifically calls this out for custom routes.

For managed identity, configure the HTTP action to use the Logic App’s system-assigned or user-assigned identity and the audience expected by your API. Configure the Function App/API to authenticate Microsoft Entra tokens and authorize that identity with only the required permissions. The Function action’s managed-identity support is different: Microsoft documents it for Consumption workflows only, not Standard workflows.

Test one route first and verify the token audience/issuer and the identity seen by the API, then add the remaining operations. Do not put a function key or client secret in the workflow if the goal is secretless identity.

References: Call Azure Functions from workflows (runtime, trigger, route and connector-auth limitations); Secure connections with managed identities (HTTP action identity setup).

If you find this answer helpful, please upvote it. If this resolves your issue, please mark it as the accepted answer so that it can help others in the community.

Your answer

Hemant Bharadwaj 370 Reputation points Microsoft Employee

2026-11-12T16:39:00.14+00:00

The Functions connector’s discovery limitation is the key here: the documented Logic Apps Functions action expects a .NET or Node.js function app with C# or JavaScript HTTP-trigger functions. Custom routes are supported by that action only when the function has a corresponding OpenAPI definition, so a Python FastAPI ASGI entry point is not exposed as a set of individually discoverable Functions actions.

To keep the existing FastAPI routes, call each route’s HTTPS URL with the Logic Apps HTTP action (set the HTTP method, headers and body as your API requires). Alternatively, expose an OpenAPI definition for the API if you need a designer experience with operation schemas; the Functions documentation specifically calls this out for custom routes.

For managed identity, configure the HTTP action to use the Logic App’s system-assigned or user-assigned identity and the audience expected by your API. Configure the Function App/API to authenticate Microsoft Entra tokens and authorize that identity with only the required permissions. The Function action’s managed-identity support is different: Microsoft documents it for Consumption workflows only, not Standard workflows.

Test one route first and verify the token audience/issuer and the identity seen by the API, then add the remaining operations. Do not put a function key or client secret in the workflow if the goal is secretless identity.

References: Call Azure Functions from workflows (runtime, trigger, route and connector-auth limitations); Secure connections with managed identities (HTTP action identity setup).

If you find this answer helpful, please upvote it. If this resolves your issue, please mark it as the accepted answer so that it can help others in the community.