Quelles sont les limites d'appels API de Salesforce et comment les gérer ?

Lorsqu'une ETI connecte Salesforce à son SI (ERP, portail client, outils marketing, data lake), chaque échange de données consomme un appel API. Salesforce plafonne ce volume par un quota quotidien. Comprendre ce mécanisme est essentiel dès la phase de cadrage : une intégration mal pensée peut saturer le quota et bloquer des flux critiques. Voici comment fonctionnent ces limites et comment les anticiper.

Comment Salesforce calcule les limites d'appels API

Salesforce applique une limite d'appels API sur 24 heures glissantes (rolling window), et non par jour calendaire. Le compteur se réinitialise en continu : à tout moment, la plateforme vérifie le nombre d'appels effectués sur les dernières 24 heures.

Le quota total d'une organisation dépend de deux facteurs principaux :

• L'édition Salesforce souscrite (Enterprise, Unlimited, etc.), qui fixe une allocation de base par licence ;
• Le nombre et le type de licences utilisateurs actives dans l'organisation.

Concrètement, le quota se calcule en additionnant une allocation par licence à un socle minimum garanti par organisation. Plus vous avez de licences d'une édition donnée, plus votre plafond quotidien augmente. Comme les valeurs exactes évoluent et varient selon les contrats, la source de référence reste la documentation officielle Salesforce (Salesforce Developer Limits) et votre contrat de licence. Il est déconseillé de se fier à des chiffres mémorisés : vérifiez toujours la valeur en vigueur pour votre organisation.

Où consulter votre quota et votre consommation réelle

Salesforce fournit plusieurs moyens de suivre l'usage :

• Dans Setup, la page System Overview affiche la consommation d'API sur les 24 dernières heures par rapport au quota ;
• L'objet OrganizationLimits (accessible via l'API REST) expose en temps réel les limites et leur utilisation ;
• Les en-têtes de réponse API (Sforce-Limit-Info) indiquent, à chaque appel, le nombre d'appels restants.

Mettre en place une supervision de ces indicateurs est une bonne pratique dès la mise en production. Cela permet de détecter une dérive avant qu'elle ne provoque un blocage.

Quels appels sont comptabilisés

La plupart des API principales de Salesforce sont soumises au quota : REST API, SOAP API, Bulk API et Bulk API 2.0. Certaines API ont toutefois des règles spécifiques :

• La Bulk API traite les données par lots : un seul appel peut charger plusieurs milliers d'enregistrements, ce qui réduit fortement la consommation par volume de données ;
• Le Streaming API et les Platform Events reposent sur des mécanismes de notification (push) avec leurs propres limites d'événements, distinctes du quota d'appels classique ;
• Certaines opérations internes (déclenchées par l'interface utilisateur standard) ne consomment pas de crédits API.

Cette distinction est déterminante : deux intégrations qui synchronisent le même volume de données peuvent avoir une consommation d'API très différente selon l'API choisie.

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

Quand le quota des 24 heures glissantes est atteint, les appels supplémentaires sont refusés avec une erreur (par exemple REQUEST_LIMIT_EXCEEDED). Les flux d'intégration échouent tant que la fenêtre glissante n'a pas libéré des crédits. Pour une ETI, cela peut se traduire par :

• Des données non synchronisées entre Salesforce et l'ERP ;
• Un portail client affichant des informations obsolètes ;
• Des campagnes marketing bloquées faute de mise à jour des contacts.

Salesforce propose des augmentations de quota, généralement via l'achat de licences supplémentaires ou une négociation contractuelle. Mais acheter du quota est rarement la première réponse : dans la majorité des cas, le dépassement révèle une architecture d'intégration à optimiser.

Bonnes pratiques pour rester sous le plafond

Une intégration bien conçue consomme peu d'API pour un volume de données important. Les leviers principaux :

1. Privilégier les opérations en masse : utiliser la Bulk API pour les synchronisations volumineuses plutôt que des appels unitaires enregistrement par enregistrement ;
2. Passer à l'événementiel : les Platform Events et le Change Data Capture permettent de pousser les changements plutôt que d'interroger Salesforce en boucle (polling) ;
3. Mettre en cache les données peu volatiles côté applications tierces, pour éviter des lectures répétées ;
4. Filtrer et cibler les requêtes : ne récupérer que les enregistrements modifiés depuis la dernière synchronisation ;
5. Superviser la consommation et poser des alertes à un seuil d'usage (par exemple 70 % du quota) ;
6. Répartir les traitements lourds dans le temps, en évitant les pics simultanés.

Ces choix se décident au cadrage de l'architecture d'intégration. Un middleware (MuleSoft ou un iPaaS tiers) peut aussi centraliser et lisser les appels, mais introduit son propre coût et ses propres limites à évaluer.

Ce qu'il faut retenir avant de lancer un projet d'intégration

Les limites d'appels API ne sont pas un obstacle en soi : elles imposent une discipline d'architecture. Le point de vigilance est d'estimer, dès le cadrage, le volume d'appels prévisionnel par flux et par jour, puis de le comparer au quota réel de votre organisation. Ce dimensionnement conditionne aussi le budget (licences, middleware) et la robustesse de vos synchronisations.

Si vous préparez une intégration Salesforce et souhaitez faire évaluer votre dimensionnement API par des intégrateurs qualifiés, INTEGREER peut vous mettre en relation avec des prestataires adaptés à votre contexte, en toute neutralité et sans engagement. L'objectif est de vous permettre de comparer des approches d'architecture avant de vous décider.