Rate limits

ExtentAPI applique un token bucket par clé API pour lisser le trafic sans bloquer les bursts légitimes.

Limites par défaut

Endpoint	Limite	Burst
POST /v1/scraper/jobs	50 / sec	100
POST /v1/extractor/extractions	50 / sec	100
GET /v1/scraper/jobs/:id	200 / sec	400
GET /* (lecture générique)	200 / sec	400

Les valeurs réelles peuvent être ajustées par client sur demande.

Headers de réponse

Toute réponse 200 inclut :

x-ratelimit-limit: 50
x-ratelimit-remaining: 47
x-ratelimit-reset: 1716288000

En cas de dépassement :

HTTP/1.1 429 Too Many Requests
Retry-After: 2
x-ratelimit-remaining: 0

Stratégie de retry

Honorer Retry-After est obligatoire côté votre code. Une implémentation correcte :

async function callWithRetry(req, maxAttempts = 5) {
  for (let i = 0; i < maxAttempts; i++) {
    const res = await fetch(req);
    if (res.status !== 429) return res;
    const wait = Number(res.headers.get("retry-after") ?? 2);
    await new Promise((r) => setTimeout(r, wait * 1000));
  }
  throw new Error("rate-limit retry exhausted");
}

Multi-clés / multi-tenant

• Chaque ApiClient a son propre bucket. Vous pouvez paralléliser en émettant plusieurs clés par environnement.
• Les compteurs sont par-clé, jamais agrégés par tenant — utiliser 10 clés vous donne 10× le débit (dans la limite des quotas globaux).

Hors rate-limit

• Crédits insuffisants → 402 (cf. Crédits).
• Quota journalier dépassé → 429 quota_exceeded (cf. Quotas).
• Burst trop violent → 429 rate-limit.

Trois codes voisins, trois causes orthogonales. Le corps de réponse explicite la classification :

{
  "error": {
    "code": "rate_limited",
    "message": "Too many requests",
    "retryAfterSec": 2
  }
}