​
Quotas

Le rate-limiting s’applique de façon uniforme, sans distinction de scope ni d’endpoint (chaque requête compte pour 1) :
  • 600 requêtes / 60 s par clé API
  • 300 requêtes / 60 s par IP (en l’absence de clé)
La fenêtre est fixe (60 s). Les limites sont par clé, pas par compte. Utiliser plusieurs clés (par environnement, par micro-service) répartit la charge entre elles, chaque clé ayant son propre compteur de quota.

​
Headers

Chaque réponse inclut : 
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 47
X-RateLimit-Reset: 1731843299
  • Limit : quota total pour la fenêtre actuelle (600 par clé, 300 par IP)
  • Remaining : appels restants avant 429
  • Reset : timestamp Unix (en secondes) où la fenêtre se réinitialise

​
Quand vous dépassez

Réponse 429 Too Many Requests avec un header Retry-After (en secondes) : 
Retry-After: 12
et un corps JSON : 
{
  "statusCode": 429,
  "error": "Too Many Requests",
  "message": "Rate limit exceeded (600/60s)",
  "retryAfter": 12
}
Le 429 est une exception au format d’erreur standard ({ statusCode, message, code }) : son corps porte error et retryAfter, pas de champ code. Le SDK Node respecte le header automatiquement : sur 429 avec Retry-After, il attend min(Retry-After × 1000, 5000) ms (plafond 5 s) avant de réessayer. Si vous appelez l’API en direct : 
if (res.status === 429) {
  const wait = Number(res.headers.get('Retry-After') ?? '5');
  await sleep(wait * 1000);
  return retry();
}

​
Stratégie côté votre app

Pour un pic de trafic connu (campagne marketing, drop produit) :
  1. Pre-chauffer : créer les payment intents en avance, partager les URLs au moment du drop
  2. Demander une augmentation : contactez le support (info@izichange.com) avec vos volumes prévus
Les webhooks ne consomment pas votre quota. C’est l’inverse : IzichangePay vous envoie des événements.