Limites de requêtes (rate limits)
Pour que le service reste stable pour tous, Cord applique une limite de requêtes par IP.
La limite
Il existe un plancher global d’environ 500 requêtes par minute et par IP sur l’ensemble des routes. En outre, chaque clé API a sa propre limite : 600 requêtes par minute pour une clé secrète (sk_) et 120 par minute pour une clé publiable (pk_, plus restreinte car elle est exposée dans le navigateur). Toutes ces limites s’entendent par minute (fenêtre glissante de 60 secondes), et non par seconde. Pour des intégrations B2B classiques (synchroniser des catalogues, créer des devis, consulter les créances), la marge est très confortable.
Indépendamment de la limite de requêtes, votre offre d’abonnement comprend un quota mensuel d’appels à l’API ; le dépasser renvoie également un 429, mais avec code: "api_quota_exceeded" au lieu d’un problème de débit — la solution consiste alors à passer à une offre supérieure, et non à relancer plus lentement.
Gérer les 429
Si vous dépassez la limite de requêtes, Cord répond 429 Too Many Requests avec un en-tête Retry-After: 60 (en secondes). Votre application doit le gérer avec un backoff exponentiel :
- Si vous recevez un 429, patientez puis relancez (respectez
Retry-Afters’il est présent). - Si la requête échoue à nouveau, doublez le délai d’attente : 1 s, 2 s, 4 s, 8 s…
- Fixez un nombre maximal de tentatives pour ne pas tourner en boucle.
Bonnes pratiques : regroupez les lectures avec la pagination (limit/offset) plutôt que de multiplier les petits appels, et évitez le polling agressif — pour être informé des changements, utilisez les webhooks plutôt que d’interroger l’API en boucle.