GitScrum / Docs

Límites de Tasa

Límites de tasa de la API de GitScrum. Comprende las cuotas de solicitudes y cómo manejar respuestas 429.

REST API — Todos los endpoints requieren autenticación mediante Bearer token. Incluye Authorization: Bearer {token} en cada solicitud. Los tokens se gestionan en Configuración de GitScrum → API. Base URL: https://services.gitscrum.com — Todas las rutas de solicitud en esta documentación son relativas a esta URL base.

La API de GitScrum aplica límites de tasa para garantizar un uso justo y la estabilidad de la plataforma.

Límites predeterminados

LímiteValor
Solicitudes por minuto60
AlcancePor token

Headers de respuesta

Cada respuesta de la API incluye headers de límite de tasa:

HeaderDescripción
X-RateLimit-LimitMáximo de solicitudes permitidas por ventana
X-RateLimit-RemainingSolicitudes restantes en la ventana actual
X-RateLimit-ResetTimestamp Unix cuando la ventana se reinicia

Ejemplo de headers

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 1738900800

429 Too Many Requests

Cuando excedes el límite de tasa, la API devuelve 429:

{
  "error": "Too Many Requests",
  "message": "Rate limit exceeded. Retry after 32 seconds.",
  "retry_after": 32
}

El header Retry-After indica cuántos segundos esperar antes de reintentar.

Manejo de límites de tasa

Backoff exponencial

Implementa backoff exponencial cuando recibas una respuesta 429:

# Pseudocode
wait = 1
while response.status == 429:
  sleep(wait)
  wait = wait * 2
  retry request

Monitorear headers

Verifica X-RateLimit-Remaining antes de hacer solicitudes. Pausa o reduce la velocidad cuando el valor se acerque a cero.

Mejores prácticas

  • Cachea respuestas — Evita solicitudes idénticas repetidas. Cachea datos de workspace, proyecto y workflow localmente.
  • Agrupa operaciones — Agrupa cambios relacionados en lugar de hacer llamadas individuales.
  • Usa webhooks — Suscríbete a eventos en lugar de hacer polling de cambios.
  • Respeta Retry-After — Siempre respeta el valor del header Retry-After antes de reintentar.
  • Distribuye solicitudes — Distribuye las llamadas a la API uniformemente en el tiempo en lugar de enviarlas en ráfagas.