Bots autenticados de Google Meet: cómo salir de la cola de amenazas

En abril de 2026, Google Meet empezó a clasificar las solicitudes de acceso en dos colas. Las personas invitadas y los miembros de la organización van a una cola verificada y entran sin fricción. Todos los demás caen en una segunda cola que los anfitriones ven etiquetada como "With potential threats" (con posibles amenazas), donde el botón predeterminado es Deny (denegar) en lugar de Admit (admitir).

Los bots de grabación se ejecutan en IP de centros de datos. Todos ellos caen en la segunda cola.

Probamos primero la solución obvia. Los proxies residenciales no sirven aquí: los pools son compartidos, así que su reputación ya está gastada, y Google los marca igual. Lo único que realmente mueve un bot a la cola verificada es ser un usuario real de Google Workspace en una organización real.

Así que eso fue lo que construimos. Ahora un bot puede iniciar sesión en una cuenta de Workspace que usted posee, y unirse como ese usuario.

La parte que sorprende a la gente

Todo el mundo supone que "bot autenticado" significa OAuth, y que nos va a entregar acceso a su cuenta de Google. No es eso lo que ocurre.

El mecanismo es SAML. Su Workspace se configura con un perfil de SSO heredado (Legacy SSO profile) que apunta a nuestro endpoint de inicio de sesión. Cuando el bot escribe su correo en la página de login de Google, Google ve que el dominio está federado y redirige hacia nosotros. Firmamos una aserción SAML con la clave privada que corresponde al certificado que usted subió a su propio Workspace, el navegador la envía por POST de vuelta a Google, y el bot queda con la sesión iniciada.

Nunca le da a MeetingBaaS acceso a ninguna API de Google. Usted sube un certificado público a un Workspace que controla. Nosotros tenemos la clave privada correspondiente y la usamos para exactamente una cosa.

Los tres enfoques que la gente espera se caen todos:

SAML esquiva todos esos problemas. No hay un segundo factor que satisfacer, porque la aserción es la autenticación.

Dos recursos, no uno

La API se divide en workspaces y logins, y la división no es arbitraria.

El perfil de SSO heredado de Google guarda un certificado de verificación por Workspace, compartido por todos los usuarios que hay en él. Si modeláramos el certificado por login, agregar una cuenta de bot significaría o bien generar un nuevo par de claves y sobrescribir el certificado en Google Admin, lo que rompe al instante todos los logins ya registrados contra el anterior, o bien pegar a mano el mismo certificado y la misma clave en cada llamada de creación.

Así que el certificado vive en el workspace, y las identidades cuelgan de él.

/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

Hay dos formas de crear uno. Que generemos nosotros el par de claves:

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

O que traiga el suyo:

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

Pase uno u otro. Pasar ambos, o ninguno, es un error de validación. Al crear comprobamos que el certificado y la clave se parseen de verdad, que la clave corresponda al certificado, y que el dominio sea un hostname válido que no haya registrado ya.

La respuesta siempre incluye cert_pem, sin importar qué camino haya tomado, porque ese es el valor que necesita pegar en Google Admin. private_key_pem no se devuelve nunca, en ningún endpoint, jamás.

domain es inmutable tras la creación. Todo lo demás se puede modificar con un patch, incluida la rotación del certificado y la clave a la vez.

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"
}

El dominio del correo debe coincidir con el dominio del workspace padre, o ser un subdominio suyo. email y workspace_id son inmutables: para mover un login, elimínelo y cree uno nuevo.

email_group es opcional y vale la pena configurarlo. Los logins que comparten grupo forman un único pool de round-robin, y si pone esa dirección de grupo en sus invitaciones de calendario, el bot asignado es un invitado, que es el camino más rápido posible a través de la sala de espera.

Ambos recursos aceptan un objeto extra para sus propios metadatos, por el que después puede filtrar:

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

Cómo usarlo en un bot

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

Cómo se resuelve meet_config:

La asignación elige el login con menos sesiones activas, desempatando por el usado hace más tiempo, y reclama el slot con una actualización condicional atómica para que dos bots simultáneos no puedan tomar el mismo.

Cuando el pool está saturado, decide fallback. "fail" es el valor predeterminado y devuelve FST_ERR_MEET_LOGIN_UNAVAILABLE. "anonymous" recurre en silencio a una unión sin autenticar, que es la opción correcta cuando conseguir alguna grabación importa más que conseguir una verificada.

Capacidad

Cada login lleva un tope de sesiones concurrentes, 20 por defecto. Está deliberadamente por debajo del punto en el que se entiende que Google empieza a aplicar throttling, y es un piso que puede subir una vez que haya medido su propio tráfico.

GET /v2/meet-logins/utilization le da el panorama completo en una sola llamada:

{
  "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 }
  ]
}

Vigile utilization_pct. Si está habitualmente por encima de 70, necesita más usuarios de Workspace, porque la cola de su tráfico ya está cayendo en fallback.

Cuando un login se estropea

Tanto los workspaces como los logins tienen un state de active o invalid. Solo el sistema establece invalid, y lo hace cuando el inicio de sesión de un bot falla de una forma que seguirá fallando: una aserción SAML rechazada, que suele significar que el certificado en Google Admin ya no coincide con el nuestro, o un usuario de Workspace que ha sido suspendido o eliminado. Los timeouts transitorios no cambian nada.

Un login invalidado deja de recibir asignaciones y registra last_error_message, last_error_at y un objeto failure_data con el bot que se topó con el problema. Reactivarlo es deliberadamente manual, una vez que haya corregido la causa de fondo:

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

PATCH solo acepta "active". Intentar establecer "invalid" usted mismo lo rechaza la validación del request con un 400.

Eliminar un login o un workspace con sesiones en curso devuelve 409 en lugar de arrancarle la credencial a un bot en ejecución. Eliminar un workspace se propaga en cascada a sus logins.

Configuración

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"
  }'

Una limitación que conviene conocer de entrada

Google muestra el nombre propio del usuario de Workspace en la lista de participantes, y anula lo que sea que usted pase como bot_name. Si el nombre mostrado le importa, hoy la única solución alternativa es un usuario de Workspace por cada nombre que quiera mostrar, algo que no escala mucho. Lo estamos revisando.

Relacionado

• Bots autenticados de Microsoft Teams — el mismo problema en Teams, resuelto de otra manera, y por qué
• Referencia de la API de Meeting BaaS

¿Preguntas sobre cómo dimensionar un pool de logins para su tráfico, o sobre si un subdominio dedicado es suficiente en su caso? Contáctenos.