# Limites de débit Découvrez les limites de débit des API et comment les gérer. Stripe utilise des limites d’appels pour maximiser la stabilité de l’API et éviter les abus. Considérez les limites comme des maximums et évitez les charges inutiles. Si vous dépassez les limites, vous obtenez des réponses d’état HTTP `429 Too Many Requests`. 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 de débit En général, les limites d’appels sont mesurées en requêtes d’API par seconde, par compte Stripe. La limite d’appels globale s’applique à l’utilisation totale de l’API par compte, tandis que certains endpoints ont leurs propres limites supplémentaires. Stripe considère chaque opération d’API nommée comme un endpoint distinct (par exemple, `POST /v1/payment_intents` et `GET /v1/payment_intents/{id}` constituent des endpoints distincts). Les requêtes envoyées à `GET /v1/payment_intents/{id}` pour différents identifiants PaymentIntent sont comptabilisées dans la limite du même endpoint. | Ressource | Limites | | --- | --- | | **Limite d’appels 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 - *Environnement de test* (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 | | Endpoints d’API individuels (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 Subscriptions](https://docs.stripe.com/api/subscriptions.md) | - 10 nouvelles factures par abonnement, par minute - 20 nouvelles factures par abonnement et par jour - 200 mises à jour de quantité par abonnement et par heure | | [API Files](https://docs.stripe.com/api/files.md) | - 20 requêtes read par seconde - 20 requêtes write par seconde | | [API Payouts](https://docs.stripe.com/api/payouts.md) | - 15 requêtes [create](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), incluant : - [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 - *Environnement de test* (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 Search](https://docs.stripe.com/search.md#rate-limits)1 | 20 requêtes read par seconde | | [Issuing](https://docs.stripe.com/issuing.md) | Les limites de création de cartes bancaires 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 obtenir des options plus efficaces lors de tâches d’analyse nécessitant de nombreuses données. ## Limites de simultanéité Les limites de simultanéité restreignent le nombre de requêtes simultanément actives, indépendamment des limites d’appels. Contrairement aux limites d’appels, qui se réinitialisent en général 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 courant que les erreurs de limite d’appels, et indique généralement des requêtes d’API longues ou nécessitant beaucoup de ressources, telles que les requêtes de liste ou celles qui incluent des [développements](https://docs.stripe.com/expand.md). ## Réponses soumises aux limites d’appels Les requêtes qui sont soumises à une limite d’appels renvoient un code d’état HTTP `429 Too Many Requests` 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` | Vous avez dépassé la limite d’appels globale. Vous pouvez éviter cela en envoyant des requêtes à un rythme plus lent. | | `endpoint-rate` | Vous avez dépassé la limite d’appels vers cet endpoint d’API spécifique. Vous pouvez éviter cela en envoyant des requêtes vers cet endpoint à un rythme plus lent. | | `global-concurrency` | Vous avez dépassé la limite de simultanéité globale. Vous pouvez éviter cela en envoyant moins de requêtes simultanées. | | `endpoint-concurrency` | Vous avez dépassé la limite de simultanéité d’appels vers cet endpoint d’API spécifique. Vous pouvez éviter cela en envoyant moins de requêtes simultanées vers cet endpoint spécifique. | | `resource-specific` | Vous avez dépassé la limite d’appels liée aux requêtes vers n’importe quel endpoint de cette ressource, par exemple les endpoints de création et de mise à jour des abonnements. Vous pouvez éviter cela en envoyant des requêtes vers les endpoints de cette ressource à une fréquence plus faible. | Si une requête renvoie un code d’état `429` sans ces en-têtes, elle n’est pas le résultat d’une limite d’appels. Il peut s’agir d’un [délai d’attente 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 intervenir pour diverses raisons, mais les scénarios suivants 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’une **vente flash** peut entraîner le déclenchement de la limitation du débit. Nous essayons de fixer nos limites suffisamment haut pour que le trafic des paiements légitimes ne soit jamais dépassé. Toutefois, si vous craignez qu’un événement entraîne un dépassement de ces limites, [contacter le service de support Stripe](https://support.stripe.com/). - L’émission de nombreuses requêtes longues peut déclencher la limite de simultanéité. Les requêtes varient en fonction de la quantité de ressources de serveur Stripe qu’elles utilisent, et les requêtes nécessitant plus de ressources peuvent prendre plus de temps et risquent de faire en sorte que le limiteur de simultanéité rejette de nouvelles requêtes. Les besoins en ressources varient considérablement, mais les requêtes de liste et les requêtes qui incluent des [développements](https://docs.stripe.com/expand.md) utilisent généralement plus de ressources et prennent plus de temps. Nous suggérons de profiler la durée des requêtes d’API Stripe et de surveiller les délais d’attente pour identifier celles qui sont anormalement lentes. ## Gérer la limitation Surveillez les codes d’état `429` et mettez en œuvre un mécanisme de relance pour gérer la limitation du débit. Suivez un calendrier de retrait exponentiel pour réduire le volume de requêtes si nécessaire, et ajoutez de l’aléatoire au calendrier de retrait pour éviter un [effet de thundering herd](https://en.wikipedia.org/wiki/Thundering_herd_problem). Une approche plus sophistiquée consiste à contrôler le trafic vers Stripe globalement et à le limiter en cas de dépassement important du débit. Une technique courante pour contrôler l’utilisation de l’API est d’implémenter un [algorithme de limitation de débit par token](https://en.wikipedia.org/wiki/Token_bucket) côté client. Des implémentations ou des bibliothèques de ce type 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 pour éviter toute interférence par des charges de travail parallèles et la génération d’un résultat incohérent. L’erreur ci-dessus est causée par une requête qui essaie de verrouiller un objet déjà verrouillé et qui expire, car l’opération n’a pas abouti dans les délais. Stripe ne traite pas ces requêtes échouées, car l’[ID de requête](https://docs.stripe.com/api/request_ids.md) n’a pas abouti dans les délais. Les expirations des verrouillages 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 [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 [SDK](https://docs.stripe.com/sdks.md) de Stripe relancent les requêtes aboutissant à un code `429` causé par l’expiration d’un verrouillage, mais pas celles aboutissant à 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é à un processus 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 Les utilisateurs ont l’habitude de se préparer à un événement commercial majeur en soumettant leurs systèmes à un test de charge dans le cadre duquel l’API Stripe est exécutée dans un environnement de test. Nous déconseillons généralement cette pratique, car les limites de l’API sont plus basses dans un environnement de test. Le test de charge risque donc d’atteindre des limites qu’il n’atteindrait pas en mode production. Le mode test n’est pas non plus un substitut idéal au mode production en matière d’appel aux API, ce qui peut donc être trompeur Par exemple, la création d’un paiement en mode production entraîne l’envoi d’une requête à une plateforme de paiement. En mode test, cette requête est simulée et les profils de latence sont donc nettement 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 Stripe pouvant être activé 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. ## Affectation des requêtes de lecture API Stripe permet d’accéder à ses requêtes API de lecture (GET) afin de faciliter une activité de recherche raisonnable liée aux intégrations de paiement. Afin d’optimiser la qualité de service pour tous les utilisateurs, Stripe fournit les affectations suivantes pour les requêtes de lecture en fonction du nombre de transactions : - Les requêtes API lues par votre compte ne doivent pas dépasser 500 en moyenne par transaction. Par exemple, si vous traitez 100 transactions en 30 jours, vous ne devez pas dépasser 50 000 requêtes API lues au cours de cette période. - Lors de l’utilisation de Connect, une plateforme et ses comptes connectés disposent de quotas d’API de lecture distincts : - Chaque compte connecté dispose de sa propre affectation pour les requêtes qu’il initie (500 requêtes par transaction). - Les plateformes Connect utilisent une affectation 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 affectation est également de 500 requêtes par transaction, sur la base du nombre total de transactions effectuées 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 son nombre de transactions, dispose d’une affectation minimale de 10 000 requêtes de lecture par mois. - Les requêtes API d’écriture n’ont pas de limite d’affectation. Les appels aux endpoints d’API suivants sont exclus des limites d’affectation ci-dessus : - [Produits alimentés par les données](https://docs.stripe.com/data.md) - [Produits de rapports](https://docs.stripe.com/stripe-reports.md) - [Produits fiscaux](https://docs.stripe.com/tax.md) Pour réduire votre volume de requêtes API, envisagez d’utiliser [Stripe Data Pipeline](https://docs.stripe.com/data/data-pipeline.md) pour une exportation complète des données API vers votre base de données ou fournisseur local. > #### Filtrer les requêtes pour limiter les appels paginés > > Certains endpoints de la liste renvoient [plusieurs pages](https://docs.stripe.com/api/pagination.md) de résultats et plusieurs requêtes peuvent être nécessaires pour renvoyer l’ensemble des objets de l’API pour une opération de liste. Lorsque cela est possible, appliquez des filtres pour affiner les résultats de votre liste. ## Request a limit increase Request a limit increase for high-traffic applications through [Stripe Support](https://support.stripe.com/contact). If you request a large increase, contact Stripe Support at least 6 weeks in advance.