Limites de requêtes

Wajub limite le débit sur plusieurs axes à la fois : votre équipe, la clé utilisée, l'IP appelante et quelques endpoints sensibles. Une requête doit passer toutes ces limites. La première qui se déclenche décide de votre 429.

Les limites

Lisez la limite, ne la codez pas en dur

Votre quota d'équipe dépend de votre plan et de tout plafond personnalisé que le support a défini pour vous. Plutôt que de recopier un tableau qui peut changer sans prévenir, relisez-le dans chaque réponse :

X-RateLimit-Limit: 360
X-RateLimit-Remaining: 357
X-RateLimit-Reset: 1748083260

Ces trois en-têtes ne décrivent que le compteur de l'équipe. Les compteurs par clé, par IP et par endpoint ne sont pas exposés : un 429 peut donc arriver alors que X-RateLimit-Remaining semble encore confortable. Le champ type du corps indique lequel s'est déclenché.

À quoi ressemble un 429

Lisez type avant de réagir. Un 429 de type team ou ip signifie qu'il faut ralentir partout ; un 429 de type endpoint signifie que seule cette ressource est saturée et que le reste de votre trafic peut continuer ; un 429 de type api_key signifie que c'est cet identifiant précis qui bloque, pas votre compte.

Les limitations plus strictes sur les écritures de payout répondent avec un corps plus court, sans type. Traitez tout 429 de la même façon : lisez Retry-After, attendez, réessayez.

Attente progressive

Respectez Retry-After quand il est présent, et rabattez-vous sur une attente exponentielle avec une part d'aléa (jitter) quand il ne l'est pas. Le jitter compte : sans lui, tous les workers limités à la même seconde réessaient à la même seconde.

async function withRetry(send, max = 3) {
for (let attempt = 0; ; attempt++) {
  const res = await send();

  if (res.status !== 429 || attempt >= max) return res;

  const header = Number(res.headers.get('retry-after'));
  const wait = Number.isFinite(header) && header > 0
    ? header
    : 2 ** attempt * (0.5 + Math.random() * 0.5);

  await new Promise((r) => setTimeout(r, wait * 1000));
}
}

L'exemple PHP réutilise les mêmes $options, donc la même clé d'idempotence : la nouvelle tentative ne peut pas créer un second paiement. Consultez Idempotence.