Bot Service "Test in Web Chat" fails with 401, but backend is public and receives no logs.

Hello António Costa,

Welcome to Microsoft Q&A .Thank you for reaching out to us.

It is observed that the bot returns 401 Unauthorized in both Web Chat and Microsoft Teams, while the backend service (Cloud Run FastAPI endpoint) receives no incoming requests or logs.

This strongly indicates that the issue is occurring before the request is forwarded to the bot endpoint, most likely during Bot Framework authentication or token acquisition. As a result, the backend service is never invoked, and this behavior is not related to application logic, network connectivity or endpoint health.

This indicates the issue originates in the Bot Framework authentication or configuration layer, most likely due to:

• Token acquisition or validation failure
• Credential mismatch or outdated secret
• App Registration configuration misalignment
• Channel configuration inconsistency

Please check if the following help-

1. Authentication and App Registration Validation Authentication failure at this layer will prevent all downstream traffic. Verify Microsoft App ID and App Password: Must match exactly between:
   • Bot Service configuration
   • Application environment variables
   1. Ensure the client secret VALUE is used (not the secret ID)
   2. If any uncertainty exists, regenerate the secret and update all configurations
   Review Supported account types:
   1. In certain scenarios (for example, cross-tenant or Teams integrations), multi-tenant configuration may be required
   2. Validate this based on the deployment context rather than treating it as a universal requirement
   Please ensure tha no Conditional Access or security policies are blocking:
   • Service principal authentication
   • Non-interactive sign-in flows
2. Bot Service Configuration Validation Ensure Bot Service is correctly bound to the App Registration.Messaging Endpoint must be: https://<cloud-run-service-url>/api/messages Please confirm that:
   • Endpoint is publicly reachable over HTTPS
   • No redirects (HTTP → HTTPS or trailing slash mismatches)
   • No authentication layer exists before Bot Framework processing
   Then , re-enter App ID and secret in Bot Service and save to clear any stale configuration state
3. Channel Configuration Consistency Since both Web Chat and Teams fail, channel consistency should be validated.Refresh Microsoft Teams channel and try this sequence of Disable > Enable > Save changes
   1. Ensure Direct Line channel is enabled for Web Chat scenarios
   2. Allow 10–20 minutes for propagation after changes across services
4. Teams App Validation If Teams-specific failure persists after authentication validation:
   1. Ensure botId in Teams manifest exactly matches App ID
   2. Verify required scopes:
      • personal
      • team
      • groupchat
   3. Repackage and redeploy the Teams application after changes Please note that manifest issues are typically secondary when no backend traffic is observed, but alignment is still required.
5. Isolation Using Bot Framework Emulator This step helps distinguish between authentication and routing issues:
   • If Emulator returns 401 Unauthorized - indicates App Registration / credential / tenant configuration issue
   • If Emulator works but Teams/Web Chat fails -indicates Bot Service channel configuration or routing issue
6. Logging and Diagnostics For deeper visibility:
   • Enable Application Insights on Bot Service
   • Monitor:
   • Authentication failures
   • Token acquisition errors
   • Channel activity logs
   If no inbound requests are observed then it confirms failure occurs before bot invocation inside the Bot Framework layer

If all configuration appears correct but the issue persists, the recommended recovery approach is to

1. Create a new App Registration (validate tenant type as required)
2. Generate a fresh client secret
3. Create a new Bot Service resource
4. Reconfigure:
   • Messaging endpoint
   • Teams channel
   • Web Chat / Direct Line

This helps eliminate:

• stale credential bindings
• cached authentication state
• inconsistent Bot Framework registration

The following references might be helpful , please check them out

• Troubleshooting Bot Framework Authentication - Bot Service | Microsoft Learn
• Add authentication to a bot in Bot Framework SDK - Bot Service | Microsoft Learn
• Connect a Bot Framework bot to Microsoft Teams - Bot Service | Microsoft Learn
• Troubleshoot bot configuration issues - Bot Service | Microsoft Learn

Please let us know if the response was helpful

Thank you

Hello António Costa,

Following up to know if the above response was helpful

Thank you

Hello António Costa,

Following up to see if you had any chance to review the above response

Thank you

Im waiting on your reply. Maybe I have posted it at the wrong place. I repeat it now.
Azure Bot 30 Multitenant absence.png

Subject: RE: Missing "Multi-Tenant" option during Azure Bot Creation causing 401 Unauthorized

Hello,

Thank you for reaching out. Let me clarify the exact roadblock we are facing, which requires your engineering assistance.

The Current Situation: Our bot's backend (hosted on Google Cloud Run) is perfectly healthy, public, and processing requests. However, when we use the "Test in Web Chat" feature in Azure, the request is blocked internally by the Bot Framework validation layer, returning a 401 Unauthorized.

The Root Cause (And what we need help with): As per your own documentation and previous support suggestions, we need to create our "Azure Bot" resource as a Multi-Tenant application to properly authenticate with Microsoft Teams.

However, the "Multi-Tenant" option is completely missing/hidden from the "Type of App" dropdown in our Azure Portal UI when we try to create a new Azure Bot resource (we only see "Single Tenant" or "User-Assigned Managed Identity").

Because we are forced into a "Single Tenant" configuration by the UI, the Bot Framework SDK in our Python backend rejects the tokens generated by Microsoft Teams/Web Chat.

Our Questions for you:

Why is the "Multi-Tenant" option missing from our Azure Bot creation blade? Is there a specific Entra ID / Tenant policy blocking this for our organization (adboutique.com.br)?

We have already created a Multi-Tenant App Registration manually (3c459b96-8900-450a-91ff-6450283b5bd8). How can we force the Azure Bot resource to bind to this existing Multi-Tenant App ID if the UI refuses to let us select it?

We appreciate your swift resolution on unlocking this UI restriction so we can proceed