# Limites de débit Découvrez les limites de débit des API et comment les gérer. Stripe utilise des limites pour optimiser la stabilité de l’API et prévenir les abus; considérez donc ces limites comme des plafonds et évitez toute charge inutile. Si vous dépassez ces limites, vous obtiendrez des réponses d’état HTTP `429 Trop de requêtes`. Pour obtenir des conseils sur la gestion des erreurs `429`, consultez la section [Gestion appropriée des limites](https://docs.stripe.com/rate-limits.md#handling-limiting-gracefully). ## Limites En général, les limites sont mesurées en requêtes API par seconde, par compte Stripe. La limite globale s’applique à l’utilisation totale de l’API par compte, tandis que certains points de terminaison ont leurs propres limites supplémentaires. | Ressource | Limites | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Limite globale de l’API** | - *Mode production* (Use this mode when you’re ready to launch your app. Card networks or payment providers process payments) : 100 requêtes par seconde - *Bac à sable* (A sandbox is an isolated test environment that allows you to test Stripe functionality in your account without affecting your live integration. Use sandboxes to safely experiment with new features and changes) : 25 requêtes par seconde | | Points de terminaison API particuliers (sauf indication contraire) | 25 requêtes par seconde | | [API Payment Intents](https://docs.stripe.com/api/payment_intents.md) | 1 000 requêtes de mise à jour par objet PaymentIntent, par heure | | [API d’abonnements](https://docs.stripe.com/api/subscriptions.md) | - 10 nouvelles factures par abonnement et par minute - 20 nouvelles factures par abonnement et par jour - 200 mises à jour de quantité par abonnement, par heure | | [API de fichiers](https://docs.stripe.com/api/files.md) | - 20 requêtes de lecture par seconde - 20 requêtes d’écriture par seconde | | [API de versements](https://docs.stripe.com/api/payouts.md) | - 15 requêtes de [création](https://docs.stripe.com/api/payouts/create.md) par seconde - 30 [requêtes simultanées](https://docs.stripe.com/rate-limits.md#concurrency-limits) par entreprise | | Comptes *Connect* (Connect is Stripe's solution for multi-party businesses, such as marketplace or software platforms, to route payments between sellers, customers, and other recipients), y compris les deux : - [Comptes v2](https://docs.stripe.com/api/v2/core/accounts.md) - [Comptes v1](https://docs.stripe.com/api/accounts.md) | - *Mode production* (Use this mode when you’re ready to launch your app. Card networks or payment providers process payments) : Création de 30 comptes par seconde - *Bac à sable* (A sandbox is an isolated test environment that allows you to test Stripe functionality in your account without affecting your live integration. Use sandboxes to safely experiment with new features and changes) : Création de 5 comptes par seconde | | [API de recherche](https://docs.stripe.com/search.md#rate-limits)1 | 20 requêtes de lecture par seconde | | [Émission](https://docs.stripe.com/issuing.md) | Les limites de création de cartes dépendent du pays et du secteur du compte d’émission. | Envisagez d’utiliser [Sigma](https://docs.stripe.com/data/sigma.md) ou [Data Pipeline](https://docs.stripe.com/data/data-pipeline.md) pour des options plus efficaces lors de tâches d’analyse nécessitant un volume important de données. ## Limites de simultanéité Les limites de simultanéité restreignent le nombre de requêtes actives simultanément, indépendamment des autres limites. Contrairement aux autres limites qui se réinitialisent généralement après une seconde, la limite de simultanéité compte le nombre de requêtes en cours à un moment donné. Atteindre les limites de simultanéité est moins fréquent que les erreurs de limites, et indique généralement des requêtes API de longue durée ou nécessitant beaucoup de ressources, telles que les requêtes de liste ou celles qui incluent des [extensions](https://docs.stripe.com/expand.md). ## Réponses soumises à la limite Les requêtes soumises à une limite renvoient un code d’état HTTP `429 Trop de requêtes` et incluent un en-tête `Stripe-Rate-Limited-Reason` qui explique pourquoi la requête a été limitée. Les valeurs possibles pour cet en-tête sont : | Valeur de l’en-tête | Signification | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `global-rate` | Vos requêtes ont dépassé la limite globale. Vous pouvez éviter cela en envoyant des requêtes à une fréquence plus faible. | | `endpoint-rate` | Vos requêtes vers ce point de terminaison API spécifique ont dépassé la limite. Vous pouvez éviter cela en envoyant des requêtes vers ce point de terminaison à une fréquence plus faible. | | `global-concurrency` | Vos requêtes ont dépassé la limite de simultanéité globale. Vous pouvez éviter cela en envoyant moins de requêtes simultanées. | | `endpoint-concurrency` | Vos requêtes vers ce point de terminaison API spécifique ont dépassé la limite de simultanéité. Vous pouvez éviter cela en envoyant moins de requêtes simultanées vers ce point de terminaison. | | `resource-specific` | Vous avez atteint une limite liée à une ressource API spécifique. Consultez la documentation de cette ressource pour en savoir plus. | Si une requête renvoie un code d’état `429` sans ces en-têtes, cela n’est pas dû à une limite. Il peut s’agir d’un [délai d’expiration de verrouillage](https://docs.stripe.com/rate-limits.md#object-lock-timeouts). ## Causes de limitation fréquentes et solutions La limitation du débit peut se produire pour diverses raisons, mais les scénarios ci-dessous sont les plus courants : - L’exécution d’**un grand nombre de requêtes à des intervalles resserrés** peut entraîner une limitation du débit. Cette situation survient souvent dans le cadre d’une opération d’analyse ou de migration. Lorsque vous lancez une telle activité, essayez de gérer le nombre de requêtes côté client (voir [Gestion appropriée des limites](https://docs.stripe.com/rate-limits.md#handling-limiting-gracefully)). - Une hausse soudaine du débit, comme dans le cas d’un **solde-éclair**, peut entraîner la limitation du débit. Nous essayons de fixer nos limites à un niveau suffisamment élevé pour que le trafic de paiement légitime ne dépasse jamais les limites. Toutefois, si vous craignez qu’un événement à venir puisse vous faire dépasser les limites indiquées ci-dessus, veuillez [contacter le service d’assistance Stripe](https://support.stripe.com/). - L’émission de nombreuses requêtes longues peut déclencher la limitation de simultanéité. Les requêtes n’utilisent pas toutes la même quantité de ressources sur les serveurs de Stripe. Les requêtes plus gourmandes peuvent tendre à durer plus longtemps et risquent d’entraîner le rejet de nouvelles requêtes par le limiteur de simultanéité. Les exigences en matière de ressources sont très variables, mais les requêtes de listes et les requêtes qui incluent des [extensions](https://docs.stripe.com/expand.md) sont généralement plus gourmandes et prennent plus de temps. Nous vous suggérons d’analyser la durée des requêtes envoyées aux API Stripe et de surveiller d’éventuelles expirations pour identifier celles qui sont anormalement lentes. ## Gérer la limitation Surveillez les codes d’état `429` et mettez en place un mécanisme de relance pour gérer la limitation du débit. Respectez un calendrier de retrait exponentiel pour réduire le volume de requêtes lorsque cela est nécessaire, et ajoutez un aspect aléatoire au calendrier de retrait pour éviter un [effet de réaction de masse](https://en.wikipedia.org/wiki/Thundering_herd_problem). Une approche plus sophistiquée consiste à contrôler le trafic vers Stripe à un niveau global et à le ralentir si vous détectez une limite importante. Une technique courante pour contrôler l’utilisation de l’API consiste à appliquer un [algorithme de limitation par seau à jetons](https://en.wikipedia.org/wiki/Token_bucket) côté client. Des mises en œuvre ou des bibliothèques de seau à jetons sont disponibles pour la plupart des langages de programmation. ## Expirations du verrouillage d’objets Les intégrations peuvent rencontrer des erreurs avec l’état HTTP `429`, le code `lock_timeout`, et le message suivant : > Cet objet n’est pas accessible pour le moment, car une autre requête API ou un autre processus Stripe l’utilise actuellement. Si vous rencontrez cette erreur ponctuellement, resoumettez votre requête. Si vous la rencontrez fréquemment et que vous soumettez plusieurs requêtes simultanées pour un même objet, soumettez-les en série ou à une fréquence moindre. L’API de Stripe verrouille des objets lors de certaines opérations afin que les charges de travail concurrentes n’interfèrent pas et ne produisent des résultats incohérents. L’erreur ci-dessus est causée par une requête qui tente d’acquérir un verrou déjà bloqué ailleurs et qui expire après avoir échoué à l’acquérir à temps. Stripe ne traite pas ces requêtes ayant échoué, ce qui signifie qu’aucun [identifiant de requête](https://docs.stripe.com/api/request_ids.md) ne leur est attribué. Les délais de verrouillage n’ont pas les mêmes causes que la limitation du débit, mais les solutions à ces deux phénomènes sont similaires. Comme pour les erreurs liées à la limitation du débit, nous vous recommandons de relancer la requête selon des intervalles exponentiels (consultez la section sur [Gestion appropriée des limites](https://docs.stripe.com/rate-limits.md#handling-limiting-gracefully)). Toutefois, les mécanismes automatiques intégrés dans les [trousses SDK](https://docs.stripe.com/sdks.md) de Stripe relancent les requêtes générant un code `429` causé par l’expiration d’un verrouillage, mais non celles générant une erreur liée à la limitation du débit : #### Ruby ```ruby Stripe.max_network_retries = 2 ``` Les conflits de verrouillage sont causés par des accès simultanés à des objets liés. Les intégrations peuvent fortement réduire ce problème en s’assurant que les mutations sur un même objet sont mises en file d’attente et exécutées de manière séquentielle. Les opérations parallèles sur les API sont acceptées, mais essayez de vous assurer que ce type d’opération ne concerne que des objets uniques. Il est également possible qu’un conflit de verrouillage soit lié à une procédure Stripe exécuté en arrière-plan. Ce type de situation ne se produit que rarement, mais l’utilisateur n’a alors aucune solution. Nous recommandons de faire en sorte que toutes les intégrations puissent relancer les requêtes. ## Test de charge Il est courant que les utilisateurs se préparent à un événement commercial d’envergure en effectuant des tests de charge de leurs systèmes avec l’API Stripe étant exécutée dans un bac à sable. Nous déconseillons généralement cette pratique, car les limites de l’API sont plus basses dans un bac à sable : le test de charge risque donc d’atteindre des limites qu’il n’atteindrait pas en mode production. Par ailleurs, le bac à sable n’est pas un substitut idéal au mode production en matière d’appels à l’API, ce qui peut être trompeur. Par exemple, la création d’un paiement en mode production envoie une requête à une passerelle de paiement. Dans un bac à sable, cette requête est simulée et les profils de latence sont alors très différents. Nous vous recommandons de développer vos intégrations de sorte qu’elles disposent d’un système configurable de simulation de requêtes à l’API de Stripe que vous pouvez activer lors des tests de charge. Pour obtenir des résultats réalistes, il doit simuler une latence en patientant pendant un délai que vous déterminez après avoir échantillonné la durée d’appels aux API de Stripe en mode production du point de vue de l’intégration. ## Allocations de requête de lecture d’API Stripe donne accès à ses requêtes d’API de lecture (GET) pour faciliter les activités de recherche raisonnable liée aux intégrations de paiement. Afin de maximiser la qualité de service pour tous les utilisateurs, Stripe fournit les allocations suivantes pour les requêtes de lecture en fonction du nombre de transactions : - Les requêtes de lecture d’API de votre compte ne doivent pas dépasser une moyenne de 500 par transaction. Par exemple, si vous traitez 100 transactions en 30 jours, vous ne devez pas dépasser 50 000 requêtes de lecture d’API pendant cette période. - Lors de l’utilisation de Connect, une plateforme et ses comptes connectés disposent d’autorisations de lecture d’API distinctes : - Chaque compte connecté dispose de sa propre allocation pour les requêtes initiées (500 requêtes par transaction). - Les plateformes Connect utilisent une allocation distincte pour effectuer des requêtes de lecture au nom de leurs comptes connectés à l’aide de leur clé API secrète ou de jetons d’accès OAuth. Cette allocation est également de 500 demandes par transaction en fonction du nombre total de transactions sur ses comptes connectés. - Les ratios sont calculés sur une période glissante de 30 jours (les 30 derniers jours). - Chaque compte, quel que soit le nombre de transactions, dispose d’une allocation minimale de 10 000 requêtes de lecture par mois. - Les requêtes d’écriture d’API n’ont pas de limite d’allocation. Les appels vers les points de terminaison API suivants sont exclus des limites d’allocation ci-dessus : - [Produits de données](https://docs.stripe.com/data.md) - [Rapports sur les produits](https://docs.stripe.com/stripe-reports.md) - [Produits fiscaux](https://docs.stripe.com/tax.md) Pour réduire le volume de vos requêtes d’API, envisagez d’utiliser [Data Pipeline](https://docs.stripe.com/data/data-pipeline.md) pour exporter complètement les données d’API vers votre base de données ou votre fournisseur local. > #### Filtrer les requêtes pour limiter les appels paginés > > Certains points de terminaison de liste renvoient [plusieurs pages](https://docs.stripe.com/api/pagination.md) de résultats et peuvent nécessiter plusieurs requêtes pour renvoyer l’ensemble complet des objets API pour une opération de liste. Appliquez des filtres lorsque cela est possible pour affiner les résultats de votre liste.