Límites de uso

Dado que la API de Google Chat es un servicio compartido, aplicamos cuotas y limitaciones para garantizar que todos los usuarios la usen de manera justa y proteger el rendimiento general de Google Workspace.

Si superas una cuota, recibirás una respuesta con código de estado HTTP 429: Too many requests. Las verificaciones de límite de frecuencia adicionales en el backend de Chat también pueden generar la misma respuesta de error. Si ocurre este error, debes usar un algoritmo de retirada exponencial y volver a intentarlo más tarde. Siempre que te mantengas dentro de las cuotas por minuto que se muestran en las siguientes tablas, no habrá límite para la cantidad de solicitudes que puedes realizar por día.

Hay dos tipos de cuotas que se aplican a los métodos de la API de Chat: cuotas por espacio y por proyecto.

Cuotas por espacio

Las cuotas por espacio limitan la frecuencia de consultas en un espacio determinado y se comparten entre todas las apps de Chat que actúan en ese espacio y llaman a los métodos enumerados de la API de Chat para cada cuota.

En la siguiente tabla, se detallan los límites de consultas por espacio:

Cuota por espacio

Métodos de la API de Chat

Límite (cada 60 segundos, compartido
entre todas las apps de Chat del espacio)

Operaciones de lectura por minuto

media.download

spaces.get

spaces.members.get

spaces.members.list

spaces.messages.get

spaces.messages.list

spaces.messages.attachments.get

spaces.messages.reactions.list

900

Operaciones de escritura por minuto

media.upload

spaces.delete

spaces.patch

spaces.messages.create (también se aplica a webhooks entrantes)

spaces.messages.delete

spaces.messages.patch

spaces.messages.reactions.create

spaces.messages.reactions.delete

60

Cuotas por proyecto

Las cuotas por proyecto limitan la frecuencia de consultas para un proyecto de Google Cloud y, por lo tanto, se aplican a una sola app de Chat que llama a los métodos especificados de la API de Chat para cada cuota.

En la siguiente tabla, se detallan los límites de consultas por proyecto. También puedes consultar estos límites en la página Cuotas.

Cuota por proyecto

Métodos de la API de Chat

Límite (cada 60 segundos)

Operaciones de escritura de mensajes por minuto

spaces.messages.create

spaces.messages.patch

spaces.messages.delete

3,000

Lecturas de mensajes por minuto

spaces.messages.get

spaces.messages.list

3,000

Operaciones de escritura de membresía por minuto

spaces.members.create

spaces.members.delete

300

Operaciones de lectura de membresías por minuto

spaces.members.get

spaces.members.list

3,000

Escrituras de espacios por minuto

spaces.setup

spaces.create

spaces.patch

spaces.delete

60

Lecturas de espacios por minuto

spaces.get

spaces.list

spaces.findDirectMessage

3,000

Escrituras de archivos adjuntos por minuto

media.upload

600

Lecturas de archivos adjuntos por minuto

spaces.messages.attachments.get

media.download

3,000

Escrituras de reacciones por minuto

spaces.messages.reactions.create

spaces.messages.reactions.delete

600

Lecturas de reacciones por minuto

spaces.messages.reactions.list

3,000

Límites de uso adicionales

Existen límites de cuota adicionales para crear espacios de tipo GROUP_CHAT o SPACE (mediante el método spaces.create o spaces.setup). Crea menos de 35 espacios por minuto y 210 espacios por hora de estos tipos. Los espacios de tipo DIRECT_MESSAGE no están sujetos a estos límites de cuota adicionales.

Las consultas grandes por segundo (QPS) de cualquier API que se oriente al mismo espacio pueden activar límites internos adicionales que no se pueden ver en la página Cuotas.

Resuelve errores de cuotas basados en el tiempo

Para todos los errores basados en el tiempo (máximo de N solicitudes por X minutos), recomendamos que tu código capte la excepción y use una retirada exponencial truncada para garantizar que los dispositivos no generen una carga excesiva.

La retirada exponencial es una estrategia estándar de manejo de errores para aplicaciones de red. Un algoritmo de retirada exponencial vuelve a intentar las solicitudes mediante tiempos de espera que aumentan de manera exponencial entre solicitudes, hasta un tiempo de retirada máximo. Si las solicitudes aún no tienen éxito, es importante que las demoras entre las solicitudes aumenten con el tiempo hasta que se realice de forma correcta.

Algoritmo de ejemplo

Un algoritmo de retirada exponencial vuelve a intentar las solicitudes de forma exponencial, lo que aumenta el tiempo de espera entre los reintentos hasta un tiempo de retirada máximo. Por ejemplo:

  1. Realizar una solicitud a la API de Google Chat
  2. Si la solicitud falla, espera 1 + random_number_milliseconds y vuelve a intentar la solicitud.
  3. Si la solicitud falla, espera 2 + random_number_milliseconds y vuelve a intentar la solicitud.
  4. Si la solicitud falla, espera 4 + random_number_milliseconds y vuelve a intentar la solicitud.
  5. Y así sucesivamente, hasta un tiempo de maximum_backoff.
  6. Sigue con la espera y los reintentos hasta llegar a una cantidad máxima, pero no aumentes el período de espera entre los reintentos.

Donde:

  • El tiempo de espera es de min(((2^n)+random_number_milliseconds), maximum_backoff), con n incrementado en 1 para cada iteración (solicitud).
  • random_number_milliseconds es una cantidad aleatoria de milisegundos menor o igual que 1,000. Esto ayuda a evitar los casos en los que muchos clientes se sincronizan por alguna situación y todos realizan el reintento a la vez, lo que envía solicitudes en etapas sincronizadas. El valor de random_number_milliseconds se vuelve a calcular después de cada solicitud de reintento.
  • maximum_backoff suele ser de 32 o 64 segundos. El valor adecuado depende del caso práctico.

El cliente puede volver a intentarlo después de que haya alcanzado el tiempo maximum_backoff. Después de este punto, los reintentos no necesitan seguir aumentando el tiempo de retirada. Por ejemplo, si un cliente usa un tiempo maximum_backoff de 64 segundos, después de alcanzar este valor, el cliente puede volver a intentarlo cada 64 segundos. En algún momento, se debe evitar que los clientes vuelvan a intentarlo de forma indefinida.

El tiempo de espera entre los reintentos y la cantidad de reintentos dependen de tu caso de uso y las condiciones de la red.

Solicita un aumento de la cuota por proyecto

Según el uso de recursos de tu proyecto, es posible que desees solicitar un aumento de cuota. Se considera que las llamadas a la API realizadas por una cuenta de servicio usan una sola cuenta. Solicitar una cuota aumentada no garantiza la aprobación. Los aumentos de cuota grandes pueden tardar más en aprobarse.

No todos los proyectos tienen las mismas cuotas. A medida que usas cada vez más Google Cloud con el tiempo, es posible que tus cuotas deban aumentar. Si prevés un aumento considerable en el uso, puedes solicitar ajustes en la cuota de forma proactiva en la página Cuotas de Google Cloud Console.

Para obtener más información, consulta los siguientes recursos: