Limitation de débit des API Inqom (Rate Limiting)

Afin de garantir la stabilité, la performance et l’équité d’accès à nos API, un mécanisme de rate limiting est appliqué sur api.inqom.com.

Ce dispositif vise à prévenir les surcharges liées à des boucles d’appels excessives ou à des intégrations mal configurées, susceptibles d’impacter les performances globales de la plateforme pour l’ensemble des utilisateurs.

Quelle est la limite appliquée ?

Les appels effectués vers nos API via api.inqom.com sont limités à 15 requêtes par seconde par ClientId / utilisateur

• Chaque couple ClientId + username (utilisé pour l'authentification) dispose de son propre quota.

• La limite s’applique toutes routes confondues.

• La limite est glissante sur une seconde.

Que se passe-t-il en cas de dépassement ?

Si la limite est dépassée, notre API vous retournera :

HTTP 429 – Too Many Requests

Cela signifie que trop d’appels ont été effectués dans une fenêtre de temps trop courte. Ce n’est donc pas une erreur fonctionnelle mais une sécurité visant à se protéger des attaques et des mauvaises usages.

Bonnes pratiques d’intégration

Gestion des erreurs 429 (retry avec backoff exponentiel)

1) Identifier la cause

• Pic d’activité ponctuel ?

• Boucle infinie ?

• Trop d’appels parallèles ?

• Mauvaise gestion des retries ?

2) Implémenter un mécanisme de retry intelligent

Attendre avant de réessayer et augmenter progressivement le délai d’attente puis arrêter après un nombre maximal de tentatives

Exemple de stratégie recommandée :

Limiter le parallélisme

Évitez les batchs massifs lancés en parallèle et les traitements multi-threads sans contrôle. Nous vous recommandation donc d'implémenter un throttling qui limitera vos nombre d’appels simultanés.

Privilégier les delta et les endpoints paginés

Lorsque disponible, utilisez la pagination et ne récupérer pas tout l’historique à chaque appel en mettant en place des appels incrémentaux (delta). Par exemple, plutôt que de relire toutes les écritures comptables, utiliser les endpoints de changements lorsqu'ils sont disponibles (cf. API Accounting Ecriture).

Mettre en cache les données stables

Ne pas rappeler inutilement les référentiels (TVA, régimes fiscaux, formes légales…) et les axes analytiques. Si une donnée ne change pas souvent --> mettez-la en cache.

✔️ File d’attente interne

✔️ Gestion centralisée des appels API

✔️ Rate limite côté client

✔️ Retry avec backoff exponentiel

✔️ Logs d’erreurs 429

✔️ Monitoring du volume d’appels

Besoin d'aide ?

Si vous constatez des 429 fréquents malgré une implémentation conforme ou que vous avez une suspicion de mauvaise configuration, contactez-nous à api@inqom.com en précisant :

• le(s) appel(s) précis en erreur,

• votre ClientId,

• l’environnement (Prod / Staging),

• et l’heure des erreurs.