Yes, you are reading it right! Something so basic, so apparently harmless, can lead to unexpected behavior or integration issues: The name of the “When a HTTP request is received” trigger in a Logic App Standard or Consumption affects the actual URL of the workflow! 😲
And we’re not talking about display names or metadata — this tiny detail affects your workflow’s real, public endpoint. Let’s break it down.
When we create a Logic App (Standard) with a “When a HTTP request is received” trigger, Azure automatically generates a callback URL that includes several parameters, including the trigger name:
- For Logic App Consumption
https://{name}.logic.azure.com:443/workflows/{workflow-id}/triggers/{triggerName}/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2F{triggerName}%2Frun&sv=1.0&sig=...
- For Logic App Standard
https://{name}.logic.azure.com:443/api/{workflow-name}/triggers/{triggerName}/invoke?api-version=2022-05-01&sp=%2Ftriggers%2F{triggerName}%2Frun&sv=1.0&sig=...
The problem is that in many scenarios, Logic Apps are used as API endpoints, webhook receivers, or are called by external systems that rely on the generated URL.
Now, imagine the following common situations:
- You rename the trigger during development or refactoring.
- You promote the Logic App to another environment (e.g., from dev to prod) with a different trigger name.
- You redeploy using ARM/Bicep and forget the original trigger name.
Suddenly, the previously working endpoint stops responding because the trigger path in the URL has changed. External systems won’t know! They’ll still try to call the old endpoint unless you notify them or update your configurations.
And the reality is that there’s no workaround to “freeze” the trigger path. It’s by design. But you can follow a few best practices to avoid surprises:
- Define a clear naming convention for triggers and stick to it across all environments.
- Never rename the “When a HTTP request is received” trigger without understanding the impact on existing integrations.
- Store the full callback URL in a configuration store (like Azure Key Vault or App Config) and use that as a source of truth.
- If you are exposing Logic Apps publicly, consider placing them behind Azure API Management. This way, the external contract stays consistent even if internal Logic App trigger names change.
To lazy to read? We’ve got you covered! Check out our video version of this content!
Hope you find this helpful! If you enjoyed the content or found it useful and wish to support our efforts to create more, you can contribute towards purchasing a Star Wars Lego for my son!
