Bots Autenticados no Google Meet: Saindo da Fila de Ameaças

Em abril de 2026, o Google Meet passou a separar as solicitações de entrada em duas filas. Convidados e membros da organização caem em uma fila verificada e são liberados direto. Todo o resto cai em uma segunda fila, que os anfitriões veem rotulada como "Com possíveis ameaças" (With potential threats), na qual o botão padrão é Recusar (Deny) em vez de Aceitar (Admit).

Bots de gravação rodam em IPs de data center. Todos eles caem na segunda fila.

Tentamos primeiro a solução óbvia. Proxies residenciais não funcionam aqui: os pools são compartilhados, então a reputação deles já foi gasta, e o Google os sinaliza da mesma forma. A única coisa que de fato move um bot para a fila verificada é ele ser um usuário real do Google Workspace em uma organização real.

Então foi isso que construímos. Agora um bot consegue fazer login em uma conta do Workspace que é sua e entrar na reunião como aquele usuário.

A parte que surpreende as pessoas

Todo mundo supõe que "bot autenticado" significa OAuth, e que vai acabar nos entregando acesso à própria conta Google. Não é isso que acontece.

O mecanismo é SAML. Seu Workspace é configurado com um perfil de SSO legado (Legacy SSO profile) que aponta para o nosso endpoint de login. Quando o bot digita o e-mail dele na página de login do Google, o Google vê que o domínio é federado e redireciona para nós. Assinamos uma asserção SAML com a chave privada correspondente ao certificado que você subiu no seu próprio Workspace, o navegador faz POST dela de volta para o Google, e o bot está autenticado.

Você nunca concede à MeetingBaaS acesso a nenhuma API do Google. Você sobe um certificado público em um Workspace que você controla. Nós guardamos a chave privada correspondente e a usamos para exatamente uma coisa.

As três abordagens que as pessoas esperam falham todas:

O SAML contorna todos esses pontos. Não há segundo fator a satisfazer, porque a asserção é a autenticação.

Dois recursos, não um

A API se divide em workspaces e logins, e a divisão não é arbitrária.

O perfil de SSO legado do Google guarda um certificado de verificação por Workspace, compartilhado por todos os usuários dele. Se modelássemos o certificado por login, adicionar uma conta de bot significaria gerar um novo par de chaves e sobrescrever o certificado no Google Admin, o que quebra na hora todos os logins já registrados com o antigo, ou então colar o mesmo certificado e a mesma chave em cada chamada de criação, na mão.

Por isso o certificado fica no workspace, e as identidades penduram nele.

/v2/meet-workspaces   → domain + SAML certificate and private key
/v2/meet-logins       → the Workspace users, attached via workspace_id

Workspaces

POST   /v2/meet-workspaces
GET    /v2/meet-workspaces
GET    /v2/meet-workspaces/:workspace_id
PATCH  /v2/meet-workspaces/:workspace_id
DELETE /v2/meet-workspaces/:workspace_id

Há duas formas de criar um. Deixe que a gente gera o par de chaves:

{
  "name": "Acme Production",
  "domain": "bots.acme.com",
  "generate_keypair": true
}

Ou traga o seu:

{
  "name": "Acme Production",
  "domain": "bots.acme.com",
  "cert_pem": "-----BEGIN CERTIFICATE-----...",
  "private_key_pem": "-----BEGIN PRIVATE KEY-----..."
}

Passe um ou outro. Passar os dois, ou nenhum, é erro de validação. Na criação, verificamos se o certificado e a chave realmente podem ser lidos, se a chave corresponde ao certificado e se o domínio é um hostname válido que você ainda não registrou.

A resposta sempre inclui cert_pem, independentemente do caminho escolhido, porque é esse o valor que você precisa colar no Google Admin. private_key_pem nunca é devolvido, por endpoint nenhum, nunca.

domain é imutável depois da criação. Todo o resto pode ser alterado por patch, inclusive rotacionar o certificado e a chave juntos.

Logins

POST   /v2/meet-logins
GET    /v2/meet-logins
GET    /v2/meet-logins/utilization
GET    /v2/meet-logins/:credential_id
PATCH  /v2/meet-logins/:credential_id
DELETE /v2/meet-logins/:credential_id

{
  "workspace_id": "f0e1d2c3-b4a5-6789-0123-456789abcdef",
  "name": "Production Bot Pool — Account 1",
  "email": "bot1@bots.acme.com",
  "email_group": "bots@bots.acme.com"
}

O domínio do e-mail precisa ser igual ao domínio do workspace pai, ou um subdomínio dele. email e workspace_id são imutáveis: para mover um login, exclua-o e crie outro.

email_group é opcional e vale a pena definir. Logins que compartilham um grupo formam um único pool de round-robin e, se você colocar o endereço desse grupo nos seus convites de calendário, o bot atribuído passa a ser um convidado, que é o caminho mais rápido possível através da sala de espera.

Os dois recursos aceitam um objeto extra para os seus próprios metadados, pelos quais você pode filtrar depois:

GET /v2/meet-logins?extra=environment:production

Usando em um bot

{
  "meeting_url": "https://meet.google.com/abc-defg-hij",
  "bot_name": "Recording Bot",
  "meet_config": {
    "email_group": "bots@bots.acme.com",
    "fallback": "fail"
  }
}

Como o meet_config é resolvido:

A atribuição escolhe o login com menos sessões ativas, desempatando pelo menos usado recentemente, e reserva o slot com uma atualização condicional atômica, para que dois bots simultâneos não possam pegar o mesmo.

Quando o pool satura, quem decide é o fallback. "fail" é o padrão e retorna FST_ERR_MEET_LOGIN_UNAVAILABLE. "anonymous" cai silenciosamente para uma entrada não autenticada, que é a escolha certa quando ter alguma gravação importa mais do que ter uma verificada.

Capacidade

Cada login carrega um limite de sessões simultâneas, 20 por padrão. Esse valor está deliberadamente abaixo do ponto em que se entende que o Google começa a limitar, e é um piso que você pode elevar depois de medir o seu próprio tráfego.

GET /v2/meet-logins/utilization te dá o quadro inteiro em uma única chamada:

{
  "logins_total": 5,
  "logins_active": 5,
  "logins_invalid": 0,
  "concurrent_sessions": 47,
  "concurrent_capacity": 100,
  "utilization_pct": 47,
  "by_email_group": [
    { "email_group": "bots@bots.acme.com", "logins": 5, "concurrent": 47, "capacity": 100 }
  ]
}

Fique de olho em utilization_pct. Se ele estiver regularmente acima de 70, você precisa de mais usuários do Workspace, porque a cauda do seu tráfego já está batendo no fallback.

Quando um login dá problema

Tanto workspaces quanto logins têm um state que é active ou invalid. Só o sistema define invalid, e faz isso quando o login de um bot falha de um jeito que vai continuar falhando: uma asserção SAML rejeitada, o que normalmente significa que o certificado no Google Admin não corresponde mais ao nosso, ou um usuário do Workspace que foi suspenso ou excluído. Timeouts transitórios não mudam nada.

Um login invalidado deixa de receber atribuições e registra last_error_message, last_error_at e um objeto failure_data com o bot que esbarrou nele. A reativação é deliberadamente manual, depois que você corrigir a causa raiz:

PATCH /v2/meet-logins/:credential_id
{ "state": "active" }

O PATCH só aceita "active". Tentar definir "invalid" por conta própria é rejeitado pela validação da requisição com um 400.

Excluir um login ou workspace com sessões em andamento retorna 409, em vez de arrancar a credencial debaixo de um bot em execução. Excluir um workspace cascateia para os logins dele.

Configuração

curl -X POST https://api.meetingbaas.com/v2/meet-workspaces \
  -H "x-meeting-baas-api-key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain": "bots.acme.com", "generate_keypair": true}'

curl -X POST https://api.meetingbaas.com/v2/meet-logins \
  -H "x-meeting-baas-api-key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workspace_id": "...",
    "name": "bot1",
    "email": "bot1@bots.acme.com",
    "email_group": "bots@bots.acme.com"
  }'

Uma limitação que vale conhecer desde já

O Google exibe o nome do próprio usuário do Workspace na lista de participantes e sobrescreve o que quer que você passe em bot_name. Se o nome exibido importa para você, a única solução hoje é ter um usuário do Workspace por nome que você queira mostrar, o que não escala muito. Estamos olhando para isso.

Relacionados

• Bots Autenticados no Microsoft Teams — o mesmo problema no Teams, resolvido de outro jeito, e por quê
• Referência da API do Meeting BaaS

Dúvidas sobre como dimensionar um pool de logins para o seu tráfego, ou sobre se um subdomínio dedicado é suficiente no seu caso? Fale conosco.