Limites de Débit

REST API — Tous les endpoints nécessitent une authentification par Bearer token. Incluez Authorization: Bearer {token} dans chaque requête. Les tokens sont gérés dans Paramètres GitScrum → API. Base URL: https://services.gitscrum.com — Tous les chemins de requête dans cette documentation sont relatifs à cette URL de base.

L'API GitScrum applique des limites de débit pour garantir une utilisation équitable et la stabilité de la plateforme.

Limites par défaut

En-têtes de réponse

Chaque réponse API inclut des en-têtes de limite de débit :

Exemple d'en-têtes

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

429 Too Many Requests

Lorsque vous dépassez la limite de débit, l'API retourne 429 :

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

L'en-tête Retry-After indique le nombre de secondes à attendre avant de réessayer.

Gérer les limites de débit

Backoff exponentiel

Implémentez un backoff exponentiel lorsque vous recevez une réponse 429 :

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

Surveiller les en-têtes

Vérifiez X-RateLimit-Remaining avant de faire des requêtes. Mettez en pause ou ralentissez lorsque la valeur approche zéro.

Bonnes pratiques

• Mettez en cache les réponses — Évitez les requêtes identiques répétées. Mettez en cache les données de workspace, projet et workflow localement.
• Regroupez les opérations — Groupez les modifications liées au lieu de faire des appels individuels.
• Utilisez les webhooks — Abonnez-vous aux événements au lieu de faire du polling.
• Respectez Retry-After — Honorez toujours la valeur de l'en-tête Retry-After avant de réessayer.
• Répartissez les requêtes — Distribuez les appels API uniformément dans le temps plutôt que de les envoyer en rafale.