O Teams segura quem entra de forma anônima na sala de espera e cada vez mais coloca um captcha no caminho. Fazer o login do bot em uma conta real do Microsoft 365 elimina os dois. Aqui está a API, a configuração do tenant e por que o Teams funciona de um jeito diferente do Meet.
Um bot anônimo que entra em uma reunião do Teams vai parar na sala de espera. Alguém precisa notar o aviso de "alguém está esperando" e deixá-lo entrar. Se ninguém fizer isso, o bot atinge o tempo limite e você fica sem gravação. A Microsoft também vem adicionando de forma constante desafios de captcha ao caminho de entrada como convidado, que um navegador headless não consegue resolver.
Um bot logado em uma conta real do Microsoft 365 pula tudo isso. Sem sala de espera, sem aviso que o anfitrião pode não ver, sem captcha. O nome dele na lista de participantes vem da conta.
Opcional, por bot. Deixe teams_config de fora e seus bots continuam entrando como convidados, sem mudança nenhuma.
Por que isso não é SAML
Lançamos os bots autenticados no Google Meet usando SAML, com a nossa API atuando como provedor de identidade de um Workspace que é seu. A pergunta óbvia é por que o Teams não funciona do mesmo jeito.
A Microsoft não oferece caminho equivalente. Fazer o Entra ID aceitar um IdP de terceiros significa federar o tenant inteiro, o que é um compromisso muito mais pesado do que subir um certificado em um perfil de SSO legado, e não é algo que pediríamos a um cliente. Então o Teams autentica do mesmo jeito que uma pessoa: e-mail, depois senha, digitados em login.microsoftonline.com.
Essa única diferença determina todo o resto:
| Google Meet | Microsoft Teams | |
|---|---|---|
| Mecanismo | Asserção SAML, atuamos como IdP | Usuário e senha |
| O recurso workspace guarda | Domínio, certificado, chave privada | Apenas o domínio do tenant |
| A credencial sai dos nossos servidores? | Não. Assinamos a asserção no servidor. | Sim. O bot a busca uma vez, sobre TLS. |
| Segredo armazenado | private_key_pem | password, criptografada |
| Modo de falha | Certificado divergente, usuário suspenso | Senha errada, solicitação de MFA |
O bot do Teams precisa ter a senha de verdade na hora de entrar, porque não há outro jeito de digitá-la. Ele a busca uma única vez em um endpoint de resolução autenticado, indexado por um id de sessão de vida curta, no mesmo formato usado pelo bot do Zoom para buscar o token OBF. A senha é criptografada em repouso com AES-256-GCM e nunca é retornada por nenhum endpoint de leitura.
A API
Mesmo formato de dois níveis do Meet: um workspace representando um tenant do Microsoft 365 e os logins pendurados nele.
POST /v2/teams-workspaces
GET /v2/teams-workspaces
GET /v2/teams-workspaces/:workspace_id
PATCH /v2/teams-workspaces/:workspace_id
DELETE /v2/teams-workspaces/:workspace_id
POST /v2/teams-logins
GET /v2/teams-logins
GET /v2/teams-logins/utilization
GET /v2/teams-logins/:credential_id
PATCH /v2/teams-logins/:credential_id
DELETE /v2/teams-logins/:credential_idO workspace é enxuto, porque não há certificado para guardar. Ele existe para que as contas de um mesmo tenant fiquem agrupadas e possam ser desativadas em bloco:
{
"name": "Contoso Production Tenant",
"domain": "contoso.onmicrosoft.com"
}Contas em qualquer um dos domínios verificados do tenant podem ser adicionadas a ele.
Depois, cada conta:
{
"workspace_id": "f0e1d2c3-b4a5-6789-0123-456789abcdef",
"name": "Teams Bot Pool — Account 1",
"email": "bot1@contoso.onmicrosoft.com",
"password": "...",
"email_group": "bots@contoso.onmicrosoft.com"
}password é somente escrita. Ler o login de volta te dá tudo, menos a senha:
{
"credential_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"workspace_id": "f0e1d2c3-b4a5-6789-0123-456789abcdef",
"name": "Teams Bot Pool — Account 1",
"email": "bot1@contoso.onmicrosoft.com",
"email_group": "bots@contoso.onmicrosoft.com",
"state": "active",
"last_error_message": null,
"last_error_at": null,
"last_used_at": "2026-08-10T14:22:03.000Z",
"active_session_count": 3,
"extra": null,
"created_at": "2026-08-01T09:12:44.000Z",
"updated_at": "2026-08-10T14:22:03.000Z"
}Rotacionar uma senha é um PATCH com a nova. Nada mais muda e os bots em execução mantêm seus slots.
Em um bot
{
"meeting_url": "https://teams.microsoft.com/l/meetup-join/...",
"bot_name": "Recording Bot",
"teams_config": {
"email_group": "bots@contoso.onmicrosoft.com",
"fallback": "anonymous"
}
}O teams_config é resolvido exatamente como o meet_config:
| O que você envia | O que acontece |
|---|---|
null (o padrão) | Entrada anônima, como convidado. |
{ "email_group": "X" } | Round-robin entre os logins ativos do grupo X. |
{ "credential_id": "Y" } | Fixa o login Y. |
| Os dois, com grupo não vazio | email_group vence. |
{ "email_group": "" } sozinho | Round-robin entre todos os logins ativos do time. |
{ "email_group": "", "credential_id": "Y" } | O login Y é fixado. Um grupo vazio não é um grupo, então credential_id assume. |
Na saturação, fallback: "fail" retorna FST_ERR_TEAMS_LOGIN_UNAVAILABLE com um 503, e fallback: "anonymous" volta para uma entrada como convidado. No caso específico do Teams, "anonymous" é um padrão mais razoável do que é no Meet, porque a entrada como convidado ainda funciona com frequência, só que é mais lenta e menos confiável.
Quantos bots uma conta consegue rodar ao mesmo tempo?
Essa pergunta aparece o tempo todo, porque todo mundo já viu o Teams dizer que você só pode estar ativo em uma reunião e precisa colocar as outras em espera.
Esse limite é por sessão de cliente, não por conta. Ele vem de uma instância do app do Teams ser dona de uma pilha de áudio. A página de limites publicada pela Microsoft não tem nenhum teto por usuário para reuniões simultâneas, e a orientação da própria Microsoft para estar em duas reuniões ao mesmo tempo é usar um segundo dispositivo ou um segundo perfil de navegador.
Cada bot da MeetingBaaS é um pod próprio, com navegador próprio e um login novo em login.microsoftonline.com. Cada bot é uma sessão de cliente separada. Uma conta pode sustentar muitos bots em reuniões diferentes simultaneamente.
O limite padrão por login é de 20 sessões simultâneas, e GET /v2/teams-logins/utilization reporta em relação a ele:
{
"logins_total": 3,
"logins_active": 3,
"logins_invalid": 0,
"concurrent_sessions": 41,
"concurrent_capacity": 60,
"utilization_pct": 68,
"by_email_group": [
{ "email_group": "bots@contoso.onmicrosoft.com", "logins": 3, "concurrent": 41, "capacity": 60 }
]
}O teto real, porém, não é o Teams. É o Entra ID. N logins simultâneos de uma mesma conta a partir de N IPs de pods diferentes é exatamente o padrão que o Acesso Condicional (Conditional Access) baseado em risco foi feito para sinalizar e, quando ele dispara, você recebe um desafio de MFA que um navegador headless não consegue responder. Se você está batendo na saturação, vale tentar aumentar o limite por conta antes de provisionar mais contas, mas meça com 5, depois 10, depois 20 em uma única conta e observe as falhas de login, em vez de pular direto para um número alto.
Configuração do tenant
Esta é a parte que exige cuidado, então leia a seção inteira antes de mudar qualquer coisa.
Use um tenant dedicado
Crie as contas de bot em um tenant só delas, por exemplo bot1@contoso-bots.onmicrosoft.com. O Business Basic já basta.
Bots autenticados precisam de configurações no nível da conta que você não deveria aplicar a um tenant onde pessoas de verdade fazem login. Um tenant separado mantém esse raio de impacto em zero. Isso não é um "seria bom ter", é a precondição para tudo o que vem abaixo.
Garanta que as contas de bot não recebam uma solicitação de MFA
Um tenant novo vem com os Padrões de Segurança (Security Defaults) ativados, o que força a página de registro "Vamos manter sua conta segura" (Let's keep your account secure) no primeiro login. Um navegador headless não consegue passar dela, e essa é de longe a causa mais comum de falha de login no Teams.
Há dois caminhos, e qual deles escolher depende do tenant:
Tenant dedicado a bots, sem contas humanas. Desligue os Padrões de Segurança para o tenant inteiro: entra.microsoft.com → Identidade (Identity) → Visão geral (Overview) → Propriedades (Properties) → Gerenciar padrões de segurança (Manage security defaults) → Desabilitado (Disabled).
Tenant com contas humanas dentro. Mantenha o MFA ligado. Coloque as contas de bot em um grupo e exclua apenas esse grupo da sua política de Acesso Condicional que exige MFA. Isso requer o Entra ID P1. É mais demorado de configurar e uma higiene muito melhor.
Nos dois casos, confira também se o MFA legado por usuário está Desabilitado para as contas de bot, e desligue a campanha de registro de métodos de autenticação (Authentication methods registration campaign) para que ela não traga a solicitação de volta mais tarde.
O estado final que você quer alcançar: fazer login como uma conta de bot te dá e-mail, senha, depois "Continuar conectado?" (Stay signed in?), e nada no meio disso.
Faça login uma vez, na mão
Entre em cada conta de bot manualmente, em um navegador normal, e limpe quaisquer telas de primeira execução que a Microsoft mostrar. Mesmo raciocínio do passo de onboarding do Workspace no lado do Meet: o primeiro login é interativo, gostando você ou não, então tire isso do caminho antes que um bot precise da conta.
Registre o workspace e os logins
curl -X POST https://api.meetingbaas.com/v2/teams-workspaces \
-H "x-meeting-baas-api-key: $API_KEY" \
-H "Content-Type: application/json" \
-d '{"domain": "contoso-bots.onmicrosoft.com"}'Depois, um POST /v2/teams-logins por conta.
Como é uma falha
Um login que falha de um jeito que vai continuar falhando muda o login para invalid e faz com que ele pare de ser atribuído. As três causas:
| Causa | O que significa |
|---|---|
| Credenciais inválidas | A senha mudou, ou foi digitada errada na criação. |
| MFA exigido | Padrões de Segurança, uma política de Acesso Condicional ou uma detecção de risco está desafiando a conta. |
| Timeout | A Microsoft estava lenta ou o fluxo travou. |
Timeouts são tratados como transitórios e não invalidam nada. As outras duas causas invalidam e registram last_error_message, last_error_at e failure_data com o bot que esbarrou nelas.
Reative depois de corrigir a causa:
PATCH /v2/teams-logins/:credential_id
{ "state": "active" }Se uma conta começa a falhar com MFA exigido depois de semanas funcionando bem, quase sempre é o Acesso Condicional baseado em risco reagindo à sua concorrência, não uma senha alterada. Olhe os logs de login no Entra antes de sair redefinindo qualquer coisa.
Excluir um login com sessões em andamento retorna 409. Os slots são liberados quando o processo do bot termina, inclusive quando ele quebra, então um pod morto não vaza capacidade de forma permanente.
Relacionados
- Bots Autenticados no Google Meet — o mesmo problema, resolvido com SAML, e por que os dois diferem
- Referência da API do Meeting BaaS
Se você está calculando de quantas contas o seu volume precisa, ou se a exclusão do Acesso Condicional vai passar pelo seu time de segurança, teremos prazer em conversar a respeito.