Limites de débit

Limites par défaut

Les deux fenêtres sont évaluées à chaque requête. La fenêtre la plus étroite (60/minute) gouverne les rafales courtes ; la fenêtre horaire gouverne la charge soutenue. Si l'une ou l'autre fenêtre est dépassée, la requête est rejetée avec 429 Too Many Requests — vous n'avez pas besoin d'inspecter quelle fenêtre s'est déclenchée, honorez seulement l'en-tête Retry-After.

Réponse au rejet

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Window: per_minute
X-RateLimit-Limit: 60

{ "error": "rate_limited" }

Retry-After est toujours un nombre entier de secondes — le délai le plus petit en toute sécurité avant que la prochaine requête ne réussisse. X-RateLimit-Limit reflète le plafond pour la fenêtre qui s'est déclenchée.

Fenêtres glissantes versus fixes

La fenêtre par minute est fixée à la minute calendaire (UTC). Une requête à 13:42:59 et une à 13:43:01 tombent dans des compartiments différents. La fenêtre par heure est un véritable agrégat glissant sur les 60 dernières minutes. Cela signifie que pendant une utilisation normale, vous ne déclencherez jamais le plafond horaire à moins que vous ne déclenchiez également le plafond par minute à répétition.

Comportement client recommandé

• Sur 429, dormez pendant au moins Retry-After secondes et réessayez une fois.
• Utilisez du jitter : retryAfter + random(0, 5) secondes pour éviter le troupeau tonitruant lorsque de nombreux workers atteignent la limite ensemble.
• Si vous contrôlez la taille de lot, exécutez pas plus de 50 requêtes/minute par clé — vous garde en toute sécurité sous le plafond.
• Pour les travaux à fort volume (export de données, provisionnement massif d'utilisateurs), émettez une clé par worker plutôt que de partager une seule clé.
• Ne traitez pas 429 comme une erreur à alerter. Alertez uniquement sur les échecs répétés après backoff exponentiel.

Schéma de réessai

Un exemple Node minimal qui respecte Retry-After avec du jitter :

async function call(path) {
  for (let attempt = 0; attempt < 4; attempt++) {
    const res = await fetch(`https://api.limeplate.com${path}`, {
      headers: { Authorization: `Bearer ${process.env.SCH_API_KEY}` },
    });
    if (res.status !== 429) return res;
    const wait = parseInt(res.headers.get('Retry-After') || '60', 10);
    const jitter = Math.floor(Math.random() * 5);
    await new Promise(r => setTimeout(r, (wait + jitter) * 1000));
  }
  throw new Error('exhausted retries on 429');
}

Demande d'un quota plus élevé

La plupart des intégrations s'inscrivent confortablement dans les limites par défaut. Si votre charge de travail a véritablement besoin d'un plafond plus élevé — par exemple, un rafraîchissement Looker nocturne qui extrait la progression pour 10 000 utilisateurs — écrivez à support@securecodinghub.com avec le nom de la clé API, l'objectif de l'intégration et le pic de requêtes/minute que vous attendez. Nous pouvons augmenter les limites par clé sans faire tourner le token.

Ce qui n'est pas limité en débit

Les livraisons de webhook entrantes que vous acceptez de SecureCodingHub ne sont pas limitées en débit de notre côté. Les livraisons de webhook sortantes que nous envoyons à votre point de terminaison suivent un calendrier de réessai séparé documenté sous Webhooks.