Azure Logic Apps Standard – Unable to Retrieve HTTP Trigger Callback URL via Bicep/CLI with Private Endpoint Enabled

[piy49]

I’m trying to confirm whether the behavior I’m seeing is a platform limitation of Azure Logic Apps Standard (single-tenant) when used with Private Endpoints, rather than a deployment or permissions issue.

Environment
Logic App Type: Standard (single-tenant)
Trigger: HTTP – When an HTTP request is received
Networking:
Private Endpoint enabled
Public network access disabled
Accessible only from within VNet
Deployment:
ZIP deployment via Azure DevOps pipeline
Workflow deploys successfully
Trigger executes correctly when invoked from inside the VNet

Problem:-
As part of CI/CD, I need to programmatically retrieve the HTTP trigger callback URL so it can be stored in Key Vault or passed to downstream systems.

However, all automation approaches fail with:

ERROR: Not Found
Failed to retrieve callback URL
What I’ve Tried

The following methods all return 404 / Not Found, despite the workflow and trigger existing and functioning correctly:
az webapp workflow trigger list-callback-url

az rest calls to:

.../hostruntime/runtime/webhooks/workflow/api/management/workflows/{workflow}/triggers/{trigger}/listCallbackUrl
ARM / Bicep listCallbackUrl()
Multiple API versions
Delays for app warm-up and workflow execution
Current Status
✅ Workflow exists
✅ Trigger fires successfully
✅ HTTP endpoint works from داخل VNet
❌ Callback URL cannot be retrieved via ARM / CLI / REST

Questions
1)- Is retrieving HTTP trigger callback URLs via ARM/CLI unsupported by design for Logic Apps Standard when:
Private Endpoint is enabled
Public network access is disabled
2)- If this is supported, could you please provide:
The correct approach to retrieve the callback URL
Any required configuration or networking considerations
3)- Is there a recommended pattern for securely exposing or storing the callback URL in private-only environments?
Additional Request

If possible, I would also appreciate an example of how to retrieve the callback URL using Azure Bicep, or confirmation that this scenario is not supported.

[GunaTeja777]

Hi @piy49 — good write-up, this is a genuine platform behavior, not a bug in your Bicep/CLI usage. Here's what's actually going on and how people work around it.

Why this happens

For Standard (single-tenant) Logic Apps, listCallbackUrl isn't a simple ARM metadata lookup — ARM proxies the call down to the app's own runtime (the hostruntime endpoint you're already hitting), which computes the SAS-signed URL live. That proxied call still has to physically reach your app's front end. When Public Network Access is set to fully Disabled (not just IP-restricted) and only a Private Endpoint is configured for inbound, ARM's control plane has no path in — it isn't calling from inside your VNet, so the request effectively gets blocked at the front door, and you see it surface as 404/Not Found rather than a clean 403.

This lines up with a few other documented quirks in the same family — e.g. Azure engineers confirming that if you lock inbound access down with access restrictions, things like viewing trigger/action input-output data in run history stop working with a CORS-style error, and the fix was adding the caller's public IP to the access restriction list. Same root cause: management/portal-plane operations need a path to the app that a hard "disabled" setting doesn't allow.

Answers to your questions

1. Is this a design limitation?

Yes — with Public Network Access fully disabled, ARM/CLI-based listCallbackUrl calls are effectively unsupported. It's a side effect of how the control plane retrieves the value, not a permissions problem on your identity/service connection.

2. Is there a supported way to still get it?

Two practical options:

• Switch from "Disabled" to "Enabled from selected virtual networks and IP addresses" and explicitly allow the AzureCloud (or more scoped, your DevOps agent's) service tag/IP as an access-restriction rule. The public endpoint still exists, but only your listed callers can reach it — Private Endpoint access for everything else stays intact.
• Run the listCallbackUrl call from inside the VNet — a self-hosted DevOps agent, an Azure Container Instance, or a deployment script resource injected into the same VNet as the Logic App — so the call to the private endpoint originates from a location that can actually reach it.

3. Recommended pattern for storing it securely?

Most teams do one of:

• Retrieve the callback URL once from inside the VNet (via a self-hosted agent/deployment script) as part of the pipeline, then push it straight into Key Vault — never expose it as pipeline output/log.
• If the trigger's SAS key ever needs rotating, re-run that same in-VNet retrieval step rather than trying to do it from a public agent.
• Avoid trying to reconstruct the URL manually — the sig is a genuine SAS signature, not something you can predict or template.

Bottom line

Your diagnosis is right — it's a platform limitation tied to how Public Network Access is configured, not something fixable purely through IAM/RBAC or a different ARM API version. Loosening "Disabled" to a scoped access-restriction rule, or moving the retrieval step inside the VNet, are the two supported paths forward.