Limites de débit

Chaque route a son propre plafond, exprimé en requêtes par minute et par adresse IP. Une lecture est large, une écriture l'est moins, et les opérations sensibles — celles qui émettent un secret — sont volontairement serrées.

Plafonds appliqués

Type d'appel	Plafond	Exemples
Lecture de liste ou de fiche	120 / min	GET /v1/entities, GET /v1/campaigns
Écriture courante	10 à 30 / min	POST /v1/entities, PUT /v1/entities/{id}
Envoi de message	60 / min	POST /v1/notifications/emails
Opération sensible	5 / min	création ou rotation d'une clé API

S'y ajoute un plafond global de 1 000 requêtes par minute et par IP, tous endpoints confondus, qui borne le total quelle que soit la répartition de vos appels.

Le compteur est propre à chaque adresse IP : deux serveurs qui appellent l'API ne se pénalisent pas l'un l'autre. En revanche, plusieurs de vos processus derrière une même sortie réseau partagent le même compteur.

Dépassement

Au-delà du plafond, l'API répond 429 Too Many Requests :

{ "error": "Trop de requêtes, ralentissez" }

Le seau se recharge en continu, pas d'un bloc à heure fixe : après un 429, quelques secondes d'attente suffisent à récupérer du crédit. Un backoff exponentiel — attendre 1 s, puis 2, puis 4 — est la bonne réponse ; boucler immédiatement ne fait qu'entretenir le refus.

En-têtes de quota

L'API ne renvoie pas d'en-têtes X-RateLimit-*. Le quota restant ne se lit donc pas : on traite le 429 quand il arrive, au lieu de l'anticiper.

Bonnes pratiques

• Préférer une liste paginée à des appels unitaires en boucle : un GET de 100 fiches coûte une requête, cent GET en coûtent cent.
• Écouter les webhooks plutôt que d'interroger l'API pour détecter un changement.
• Étaler les traitements de masse (imports, synchronisations) au lieu de les lancer d'un seul tenant.