Skip to main content
There are two ways to connect an agent to Microsoft Teams. They differ in who owns the Microsoft Teams bot, and that single difference decides how much Azure work you do. Both modes connect your own agent: StandIn is the bridge, never the brain. And both need the same one-time admin consent before calling works - chat works without it.

​
StandIn Managed Bot

StandIn publishes and operates one Microsoft Teams bot; your Microsoft organization is routed to your agent by a connection you create in the StandIn portal.
  1. In Microsoft Teams, add StandIn from the Store.
  2. Type signin to the bot and sign in with your StandIn account. That link is how StandIn learns which Microsoft organization to connect - you do not type a tenant id anywhere.
  3. In the StandIn portal, deploy an identity and choose Use the StandIn bot. Paste your agent’s address; the portal gives you back the secrets.
  4. A Microsoft 365 administrator approves calling once for the organization. Chat works before this; calling switches on when the approval lands.
You get a connection secret, and on this SDK it is one environment variable:
A managed deployment may issue a second key for chat. That is deliberate, not an oversight: each lane signs its own handshake, so two keys mean a key that can open one lane cannot open the other. If you are given one, export it as STANDIN_CHAT_SECRET and the chat lane signs with that instead. ChatChannel reads STANDIN_CHAT_SECRET first and falls back to STANDIN_SECRET, so when a single key covers both lanes there is nothing extra to set. The managed bot is also what unlocks the SDK’s chat lane. ChatChannel dials out to StandIn with whichever of those two keys it found, so chat needs no URL registered, no open port and no tunnel rule, and your agent never holds a Bot Framework credential. It needs no flag either: if the socket opens, you are managed.
One agent instance serves one connection. The secrets belong to a single Microsoft organization - run a second instance for a second organization, and never share a secret across tenants.

​
Bring your own Azure bot

You register a Microsoft Entra app, create an Azure Bot resource, and upload your own Microsoft Teams app package. The bot carries your name and lives entirely in your tenant. Follow Azure bot setup and App package. This is the right choice when identity custody matters more than setup time, or when you need the bot to be visibly yours.

​
Endpoints

StandIn dials your worker, so the URL you save in the portal has to match the path the worker listens on. Give the portal a bare host and it fills in the default below; paste a full URL if the worker uses a different path. Calling is the same in both modes. Only chat differs: A bring-your-own-bot identity answers Microsoft Teams chat on that Azure Bot messaging URL, not through ChatChannel. Calls still use the calling row. Take the URL the portal offers when you deploy the identity.

Expose your agent

The mount commands that publish the call path, what a healthy probe looks like, and the --http1.1 gotcha that makes a working mount look broken.