Aux utilisateurs et intégrateurs qui consomment l'API Boond depuis un script, un connecteur ou un outil tiers d'automatisation, et qui souhaitent optimiser leur nombre d'appels — pour rester à l'aise vis-à-vis des limites comme pour construire une intégration plus propre.

Votre consommation est encadrée par deux mécanismes indépendants, qui se cumulent :

Le détail des seuils est décrit dans l'article dédié : Comprendre les limites d'appel de l'API.

Quelques précisions sur ce qui est décompté:

En cas de dépassement et que le volume n'entre pas dans le cadre de votre quota actuel, vous pouvez souscrire à des packs APIs additionnels.

La première source d'économie, ce sont les appels que l'on peut simplement ne pas faire. Et elle est plus rentable qu'il n'y paraît : chaque appel rejoue l'intégralité de la séquence d'authentification — validation du jeton, résolution de votre instance, chargement du compte et de ses droits, décompte du quota. Rien n'est mutualisé d'un appel au suivant. C'est donc le nombre d'appels, plus encore que leur contenu, qui pèse.

Mettez en cache ce qui bouge peu. Certaines données ne sont normalement pas amenées à changer souvent : référentiels, paramétrage, structure de votre instance. Récupérez-les une fois, conservez-les de votre côté, et rafraîchissez-les à une fréquence raisonnable plutôt qu'à chaque exécution.

Sauvegardez les données figées. Les données historiques qui n'évoluent plus — anciens CRA, factures clôturées, projets terminés — n'ont pas besoin d'être ré-extraites en boucle. Enregistrez-les une fois dans votre système, puis ne rappelez plus que les périodes récentes ou susceptibles de bouger.

N'authentifiez pas à chaque étape. Un réflexe fréquent et coûteux consiste à appeler un endpoint de vérification comme current-user avant chaque requête. L'authentification ne change pas au cours d'un traitement : un seul contrôle en début de session suffit.

Utilisez un compte dédié à votre intégration si celle-ci est intégrée en backend. Faire tourner un flux sur le compte nominatif d'un collaborateur pose deux problèmes :

Un compte de service, au périmètre explicitement défini, évite les deux. Si vous utilisez une App intégrée ou s'appuyant sur les droits du user connecté le compte de service n'a pas de sens et viendrait contourner les configurations de droits de Boond.

Ne redemandez pas ce qui vous a été refusé. Un refus d'accès n'est pas un incident passager : la fiche vous restera inaccessible tant que les droits n'auront pas changé. Mémorisez le refus et cessez de la demander à chaque passage. C'est un motif fréquent, et l'un des plus coûteux : des dizaines de milliers d'appels par mois, tous décomptés, pour une réponse connue d'avance.

Ramenez plus de données par appel — mais posez-vous d'abord la bonne question. Le nombre de résultats par page est ajustable, et le laisser à sa valeur par défaut multiplie mécaniquement vos appels. Deux réserves, toutefois :

Surtout, si vous ramenez un gros volume pour n'en extraire qu'une liste d'identifiants et rappeler ensuite les fiches une par une, c'est le mécanisme lui-même qu'il faut revoir : vous payez deux fois. Interrogez-vous sur ce dont votre traitement a réellement besoin avant d'ajuster la taille des pages.

Groupez plutôt qu'un appel par fiche. Les sous-ressources d'une fiche sont efficaces pour en consulter une ; utilisées pour parcourir toutes vos fiches, elles deviennent le pire des motifs — un appel par entité, rejoué à chaque cycle. C'est, de loin, ce qui gonfle le plus les consommations constatées. Dès qu'une recherche permet de récupérer plusieurs entités connues en un seul appel, en listant leurs références, préférez-la systématiquement — et appliquez ce réflexe partout, pas seulement là où vous l'avez mis en place en premier.

Évitez les appels « au cas où ». Chaque appel devrait répondre à un besoin réel. Si vous ne savez pas si une donnée a changé, ciblez le changement (voir §3) plutôt que de tout re-télécharger par précaution.

Pour la donnée qui bouge, la règle est simple : ne récupérez que ce qui a changé depuis votre dernier passage. Plusieurs leviers, du plus simple au plus fin.

Bornez vos extractions à la fenêtre utile. Une extraction non bornée — « tout, à chaque fois » — gonfle inutilement votre consommation. Restreignez toujours à la fenêtre dont vous avez réellement besoin, en filtrant par date, par période ou par périmètre. Une fenêtre trop large ne coûte d'ailleurs pas qu'en volume : elle fait déborder les pages, et vous finissez par payer en pagination des données que vous n'exploitez pas. Une part importante des appels d'une intégration mal bornée n'existe que pour cette raison.

Passez en incrémental. Concrètement : mémorisez la date de votre dernier run et ne retraitez que le delta — ce qui a été créé ou modifié depuis. C'est souvent une forte réduction du volume d'appels.

Interrogez-vous sur la fréquence. C'est le levier le plus efficace, et le plus souvent négligé : avant d'optimiser vos appels, demandez-vous combien de fois par jour vous avez réellement besoin de les passer. Rejouer un cycle complet toutes les heures sur des CRA, des absences ou des projets — qui ne changent pas quatorze fois par jour — multiplie la consommation sans rien apporter. Alignez la cadence sur la fraîcheur dont votre usage a besoin, pas sur ce que votre planificateur permet.

Ciblez précisément via le journal d'activité. Il recense les créations, modifications et suppressions. Interrogé de façon filtrée, il vous indique quelles fiches ont changé, et souvent quels champs, sur une période donnée — vous n'avez plus qu'à re-récupérer celles-là, au lieu de tout parcourir.

Ou passez à l'événementiel avec les webhooks. Abonnez-vous aux événements de création, mise à jour et suppression des entités qui vous intéressent : Boond vous notifie au fil de l'eau, au lieu que vous interrogiez en boucle.

Espacez les extractions lourdes. Les endpoints d'extraction, de reporting et d'export figurent parmi les plus coûteux, avec les limites les plus strictes. Réservez-les à des traitements planifiés et espacés — heures creuses, découpage — plutôt qu'à des séries rapprochées.

Demandez la compression. Les réponses de l'API sont compressées, mais uniquement si votre client l'annonce, via l'en-tête Accept-Encoding: gzip, deflate. Sans lui, tout transite non compressé, plusieurs fois plus volumineux. C'est une ligne de configuration dans votre client HTTP, et l'un des gains les plus immédiats — vérifiez au passage que votre bibliothèque ne la retire pas.

Le cache des reportings se décide avec votre client. Les endpoints de reporting recalculent par défaut l'intégralité de leurs indicateurs à chaque appel : ce sont les plus coûteux de l'API. Ils peuvent servir un résultat mis en cache, mais ce n'est pas un simple paramètre de requête : l'option relève du paramétrage de l'instance, elle est désactivée par défaut, et sa durée de conservation — de l'ordre de plusieurs jours — est fixée par le client. Convenez avec lui de son activation et de sa durée : le gain est important, à condition d'accepter la fraîcheur correspondante.

Réagissez proprement à un 429. Ce n'est pas une erreur bloquante, mais un signal temporaire :

En appliquant ces principes, votre intégration appelle moins, se met à jour plus vite, et contribue à préserver la stabilité de la plateforme.