How can achievable using the Bicep template return a callback URL as a secure output

[piy49]

We need to enable the Logic App (LA) module to return a callback URL as a secure output, so it can be safely consumed by downstream modules or callers, and this should be achievable using the Bicep template below.

Below logic app bicep template

@description('App service containing the workflow runtime')
resource site 'Microsoft.Web/sites@2024-11-01' = {
name: <LOGIC_APP_NAME>
location: location
kind: 'functionapp,workflowapp'
identity: {
type: 'SystemAssigned'
}
properties: {
virtualNetworkSubnetId:
hostNameSslStates: [
{
name: '${<LOGIC_APP_NAME>}.azurewebsites.net'
sslState: 'Disabled'
hostType: 'Standard'
}
{
name: '${<LOGIC_APP_NAME>}.scm.azurewebsites.net'
sslState: 'Disabled'
hostType: 'Repository'
}
]
siteConfig: {
appSettings: concat([
{
name: 'FUNCTIONS_EXTENSION_VERSION'
value: '~4'
}
{
name: 'FUNCTIONS_WORKER_RUNTIME'
value: 'node'
}
{
name: 'WEBSITE_NODE_DEFAULT_VERSION'
value: '~20'
}
{
name: 'AzureWebJobsStorage'
value: 'DefaultEndpointsProtocol=https;AccountName=${<STORAGE_ACCOUNT_NAME>};...'
}
{
name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING'
value: 'DefaultEndpointsProtocol=https;AccountName=${<STORAGE_ACCOUNT_NAME>};...'
}
{
name: 'WEBSITE_CONTENTSHARE'
value: '${<STORAGE_ACCOUNT_NAME>}-content'
}
{
name: 'AzureFunctionsJobHost__extensionBundle__id'
value: 'Microsoft.Azure.Functions.ExtensionBundle.Workflows'
}
{
name: 'AzureFunctionsJobHost__extensionBundle__version'
value: '[1.*, 2.0.0)'
}
{
name: 'APP_KIND'
value: 'workflowApp'
}
{
name: 'WORKFLOWS_TENANT_ID'
value: subscription().tenantId
}
{
name: 'WORKFLOWS_SUBSCRIPTION_ID'
value: subscription().subscriptionId
}
{
name: 'WORKFLOWS_RESOURCE_GROUP_NAME'
value: resourceGroup().name
}
{
name: 'WORKFLOWS_LOCATION_NAME'
value: location
}
{
name: 'Environment'
value: environment
}
{
name: 'AzureWebJobsFeatureFlags'
value: 'EnableMultiLanguageWorker'
}
]
use32BitWorkerProcess: true
cors: {
allowedOrigins: [
'https://portal.azure.com'
]
}
minTlsVersion: '1.2'
ftpsState: 'FtpsOnly'
nodeVersion: '~20'
}
serverFarmId: <APPSERVICE_PLAN_ID>
publicNetworkAccess: 'Disabled'
outboundVnetRouting: {
allTraffic: false
applicationTraffic: true
contentShareTraffic: true
imagePullTraffic: false
backupRestoreTraffic: false
}
scmSiteAlsoStopped: false
clientAffinityEnabled: false
clientCertEnabled: false
clientCertMode: 'Required'
hostNamesDisabled: false
customDomainVerificationId: '<CUSTOM_DOMAIN_VERIFICATION_ID>'
containerSize: 1536
dailyMemoryTimeQuota: 0
httpsOnly: true
redundancyMode: 'None'
storageAccountRequired: false
keyVaultReferenceIdentity: 'SystemAssigned'
}
tags: tags
}

[GunaTeja777]

Yes, this is achievable — Bicep has supported a @secure() decorator on outputs (not just parameters) since Bicep CLI v0.35.1. That lets the workflow's callback URL be returned as a module output without it being written to deployment history, the portal, or CLI/pipeline logs.

What changes in your template

Since this is a Standard (single-tenant) Logic App, the trigger isn't a separate top-level ARM resource the way it is in Consumption — the callback URL has to be resolved via the hostruntime action path, using the listCallbackUrl() ARM/Bicep function against the site resource. Add two parameters and one output to your existing module:

@description('Name of the workflow inside the Logic App (Standard) that contains the HTTP trigger')
param workflowName string

@description('Name of the trigger inside the workflow, e.g. "When_a_HTTP_request_is_received"')
param triggerName string = 'manual'

// ...your existing `site` resource stays exactly as-is...

@secure()
output workflowCallbackUrl string = listCallbackUrl(
  '${site.id}/hostruntime/runtime/webhooks/workflow/api/management/workflows/${workflowName}/triggers/${triggerName}',
  '2018-11-01'
).value

A couple of notes on the syntax:

• triggerName should match your actual trigger name in the workflow definition (e.g. When_a_HTTP_request_is_received), not necessarily manual.
• @secure() on outputs requires Bicep CLI ≥ 0.35.1. Run az bicep version (or check your pipeline's Bicep install step) — on older versions this decorator will fail to compile, and you'd need to upgrade the CLI/pipeline task first.

The important caveat

@secure() only hides the value from logs and deployment history — it does not change the network path the call itself takes. listCallbackUrl() is resolved by the ARM/Bicep deployment engine at deploy time, using the exact same hostruntime action an external az rest call would use.

That means with publicNetworkAccess: 'Disabled' on the site (as in your template), this output can still fail to resolve with a 404, for the same reason discussed earlier in this thread: the deployment engine's call to compute the SAS-signed URL has to reach the app's front end, and a hard "Disabled" setting blocks that path regardless of whether the request came from the portal, CLI, or a Bicep deployment.

So to make this output reliably resolve, you still need one of:

1. Switch publicNetworkAccess to Enabled with access restrictions scoped to your deployment agent (the AzureCloud service tag, or your pipeline agent's IP) instead of a hard Disabled, or
2. Run the deployment from an agent that sits inside the same VNet as the Private Endpoint (self-hosted agent, container instance, or deployment script resource injected into the VNet).

Bottom line: @secure() outputs solve the "don't leak the URL in logs" half of the problem — they don't solve the "can the deployment engine even reach the app" half. You'll want to pair the secure output with one of the two network changes above, or the deployment itself will still throw the same 404 you saw with the CLI.