Limitation de débit

Pour garder l'API saine pour tout le monde, nous appliquons des limites de débit par clé API (ou par IP pour les appels non authentifiés).

Limites

Les deux limites tournent en parallèle. Atteindre l'une renvoie 429 rate_limited.

Réponse

En cas de throttle :

HTTP/1.1 429 Too Many Requests
Retry-After: 6
Content-Type: application/json
 
{
  "error": {
    "type": "rate_limit_error",
    "code": "rate_limited",
    "message": "Too many requests. Retry after 6 seconds.",
    "requestId": "req_8a4f2e10bb55"
  }
}

Retry-After indique combien de secondes attendre avant la réouverture de la fenêtre. Respectez-le toujours plutôt que de réessayer immédiatement.

Stratégie

1. Ne pollez pas en boucle serrée. Si vous synchronisez tous les enregistrements la nuit, paginez les résultats — ne martelez pas GET /v1/objects/contact?limit=1 50 000 fois.
2. Utilisez une file avec concurrence bornée pour les écritures en lot. 5 requêtes simultanées est un bon point de départ.
3. Lisez Retry-After à chaque 429. Ne codez pas une pause en dur.
4. Le backoff exponentiel n'est utile que pour les 5xx. Pour les 429, le serveur vous a déjà donné la bonne attente.

Demander plus

Si votre intégration a légitimement besoin de plus de 100 req/min, contactez support@boxioo.com. Nous pouvons relever la limite par clé au cas par cas.

Note d'implémentation

Les limites sont suivies par instance indépendamment. Dans un setup multi-instances (compteur Redis), le plafond effectif est la somme sur les instances, vous pouvez donc parfois observer un débit légèrement supérieur à la limite nominale. Considérez ces chiffres comme des garanties souples, pas des plafonds durs.