# Ratenbegrenzungen Infos zu API-Ratenbegrenzungen und dem Umgang damit. Stripe verwendet Begrenzungen, um die API-Stabilität zu maximieren und Missbrauch zu verhindern. Behandeln Sie Begrenzungen daher als Höchstwerte und vermeiden Sie unnötige Auslastung. Wenn Sie die Begrenzungen überschreiten, erhalten Sie HTTP-Statusantworten vom Typ `429 Too Many Requests` (zu viele Anfragen). Ratschläge zum Umgang mit `429`-Fehlern finden Sie unter [Sinnvoller Umgang mit Begrenzungen](https://docs.stripe.com/rate-limits.md#handling-limiting-gracefully). ## Begrenzungen Im Allgemeinen werden Begrenzungen in API-Anfragen pro Sekunde je Stripe-Konto gemessen. Die globale Begrenzung gilt für die gesamte API-Nutzung pro Konto, während einige Endpoints eigene zusätzliche Begrenzungen haben. Stripe betrachtet jede benannte API-Operation als separaten Endpoint (zum Beispiel sind `POST /v1/payment_intents` und `GET /v1/payment_intents/{id}` separate Endpoints). Anfragen an `GET /v1/payment_intents/{id}` für verschiedene PaymentIntent-IDs werden auf dasselbe Endpoint-Limit angerechnet. | Ressource | Begrenzungen | | --- | --- | | **Globale API-Begrenzung** | - *Live-Modus* (Use this mode when you’re ready to launch your app. Card networks or payment providers process payments): 100 Anfragen pro Sekunde - *Sandbox* (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 Anfragen pro Sekunde | | Einzelne API-Endpoints (sofern nicht anders angegeben) | 25 Anfragen pro Sekunde | | [Payment Intents API](https://docs.stripe.com/api/payment_intents.md) | 1.000 Aktualisierungsanfragen pro PaymentIntent-Objekt in der Stunde | | [Subscriptions API](https://docs.stripe.com/api/subscriptions.md) | - 10 neue Rechnungen pro Abonnement pro Minute - 20 neue Rechnungen pro Abonnement pro Tag - 200 Mengenaktualisierungen pro Abonnement pro Stunde | | [Files API](https://docs.stripe.com/api/files.md) | - 20 Leseanfragen pro Sekunde - 20 Schreibanfragen pro Sekunde | | [Payouts API](https://docs.stripe.com/api/payouts.md) | - 15 [Erstellungsanfragen](https://docs.stripe.com/api/payouts/create.md) pro Sekunde - 30 [gleichzeitige Anfragen](https://docs.stripe.com/rate-limits.md#concurrency-limits) pro Unternehmen | | *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)-Konten, einschließlich der folgenden: - [Accounts v2](https://docs.stripe.com/api/v2/core/accounts.md) - [Accounts v1](https://docs.stripe.com/api/accounts.md) | - *Live-Modus* (Use this mode when you’re ready to launch your app. Card networks or payment providers process payments): 30 Konten pro Sekunde erstellen - *Sandbox* (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): 5 Konten pro Sekunde erstellen | | [Search API](https://docs.stripe.com/search.md#rate-limits)1 | 20 Leseanfragen pro Sekunde | | [Issuing](https://docs.stripe.com/issuing.md) | Begrenzungen für die Kartenerstellung hängen vom Land und von der Branche des ausstellenden Kontos ab. | Ziehen Sie [Sigma](https://docs.stripe.com/data/sigma.md) oder [Data Pipeline](https://docs.stripe.com/data/data-pipeline.md) als effizientere Optionen für datenintensive Analyseaufgaben in Betracht. ## Begrenzungen für gleichzeitige Anfragen Begrenzungen für gleichzeitige Anfragen beschränken die Anzahl der gleichzeitig aktiven Anfragen, unabhängig von globalen Begrenzungen („rate limits“). Im Gegensatz zu solchen Begrenzungen, die im Allgemeinen nach einer Sekunde zurückgesetzt werden, zählt die Begrenzung für gleichzeitige Anfragen, wie viele Anfragen sich zu einem bestimmten Zeitpunkt in Bearbeitung befinden. Das Erreichen von Begrenzungen für gleichzeitige Anfragen ist seltener als Fehler aufgrund von globalen Begrenzungen und weist in der Regel auf lang andauernde oder ressourcenintensive API-Anfragen hin, wie z. B. Listenanfragen oder solche, die [Erweiterungen](https://docs.stripe.com/expand.md) enthalten. ## Von Begrenzungen betroffene Antworten Anfragen, für die Begrenzungen gelten, geben den HTTP-Statuscode `429 Too Many Requests` (zu viele Anfragen) zurück und enthalten den Header `Stripe-Rate-Limited-Reason`, der erklärt, warum für die Anfrage Begrenzungen gelten. Mögliche Werte für diesen Header sind die folgenden: | Header-Wert | Bedeutung | | --- | --- | | `global-rate` | Sie haben die globale Begrenzung überschritten. Sie können das verhindern, indem Sie Anfragen mit niedrigerer Frequenz senden. | | `endpoint-rate` | Sie haben die Begrenzung für Anfragen an diesen spezifischen API-Endpoint überschritten. Sie können das verhindern, indem Sie Anfragen an diesen Endpoint mit niedrigerer Frequenz senden. | | `global-concurrency` | Sie haben die globale Begrenzung für gleichzeitige Anfragen überschritten. Sie können das verhindern, indem Sie weniger gleichzeitige Anfragen senden. | | `endpoint-concurrency` | Sie haben die Begrenzung für gleichzeitige Anfragen an diesen konkreten API-Endpoint überschritten. Sie können das verhindern, indem Sie weniger gleichzeitige Anfragen an diesen konkreten Endpoint senden. | | `resource-specific` | Sie haben die Begrenzung für Anfragen an jegliche Endpoints innerhalb dieser Ressource überschritten, zum Beispiel die Update- und Create-Endpoints von Abonnements. Sie können das verhindern, indem Sie Anfragen an Endpoints in dieser gesamten Ressource mit niedrigerer Frequenz senden. | Wenn eine Anfrage den Statuscode `429` ohne diese Header zurückgibt, liegt das nicht an einer Begrenzung. Es könnte sich um eine [Sperrzeitüberschreitung](https://docs.stripe.com/rate-limits.md#object-lock-timeouts) handeln. ## Häufige Ursachen und Gegenmaßnahmen Eine Ratenbegrenzung kann unter einer Vielzahl von Bedingungen stattfinden, kommt aber am häufigsten in den folgenden Szenarien vor: - Die Ausführung **einer großen Anzahl eng beieinander liegender Anfragen** kann dazu führen, dass die Anzahl der Anfragen begrenzt wird. Dies ist häufig Teil eines Analyse- oder Migrationsvorgangs. Wenn Sie diese Aktivitäten durchführen, sollten Sie versuchen, die Anfragerate auf der Client-Seite zu steuern (siehe [Sinnvoller Umgang mit Begrenzungen](https://docs.stripe.com/rate-limits.md#handling-limiting-gracefully)). - Ein plötzlicher Anstieg des Zahlungsvolumens, z. B. bei einem **Flash Sale** (Blitzverkauf), kann zu einer Ratenbegrenzung führen. Wir versuchen, unsere Begrenzungsraten so hoch anzusetzen, dass es beim legitimen Zahlungsverkehr die Begrenzungen nie überschritten werden. Wenn Sie jedoch vermuten, dass ein bevorstehendes Ereignis dazu führen könnte, dass die obigen Begrenzungen überschritten werden, [kontaktieren Sie bitte den Stripe-Support](https://support.stripe.com/). - Das Ausstellen vieler langlebiger Anfragen kann die Begrenzung für gleichzeitige Anfragen auslösen. Anfragen variieren hinsichtlich der Menge der genutzten Stripe-Server-Ressourcen und ressourcenintensivere Anfragen können länger dauern und bringen die Gefahr mit sich, dass die Gleichzeitigkeitsbegrenzung neue Anfragen ablehnt. Die Ressourcenanforderungen sind sehr unterschiedlich. Listenanfragen und Anfragen, die [Erweiterungen](https://docs.stripe.com/expand.md) enthalten, verbrauchen im Allgemeinen mehr Ressourcen und benötigen mehr Zeit. Wir empfehlen, die Dauer von Stripe-API-Anfragen zu profilieren und auf Zeitüberschreitungen zu achten, um unerwartet langsame Anfragen zu erkennen. ## Umgang mit Begrenzungen Achten Sie auf `429`-Statuscodes und implementieren Sie einen Wiederholungsmechanismus zum Umgang mit Ratenbegrenzungen. Befolgen Sie einen exponentiellen Backoff-Zeitplan, um das Anfragenvolumen bei Bedarf zu reduzieren, und fügen Sie dem Backoff-Zeitplan den Faktor der Zufälligkeit hinzu, um einen [Thundering Herd Effect](https://en.wikipedia.org/wiki/Thundering_herd_problem) (zu deutsch etwa „stampfender Herdeneffekt), zu vermeiden. (Dieser Begriff beschreibt eine Situation, in der eine große Anzahl von Prozessen oder Anfragen gleichzeitig auf eine Ressource zugreift, nachdem diese kurzzeitig nicht verfügbar war.) Ein ausgereifterer Ansatz besteht darin, den Datenverkehr zu Stripe auf globaler Ebene zu steuern und ihn zu drosseln, wenn Sie eine erhebliche Begrenzung feststellen. Ein gängiges Verfahren zur Steuerung der API-Nutzung ist die Implementierung eines clientseitigen [Token-Bucket-Algorithmus zur Begrenzung](https://en.wikipedia.org/wiki/Token_bucket). Token-Bucket-Implementierungen oder -Bibliotheken sind für die meisten Programmiersprachen verfügbar. ## Sperrzeitüberschreitungen für Objekte Bei Integrationen können Fehler mit dem HTTP-Status `429`, dem Code `lock_timeout` und der folgenden Meldung auftreten: > Auf dieses Objekt kann derzeit nicht zugegriffen werden, da eine andere API-Anfrage oder ein anderer Stripe-Prozess gerade darauf zugreift. Wenn dieser Fehler nur zeitweise auftritt, führen Sie die Anfrage erneut durch. Tritt der Fehler hingegen häufig auf und Sie führen mehrere gleichzeitige Anfragen an ein einzelnes Objekt durch, führen Sie die Anfragen nacheinander oder mit einer niedrigeren Rate aus. Die Stripe-API sperrt Objekte für einige Vorgänge, damit sich gleichzeitige Arbeitslasten nicht gegenseitig beeinträchtigen und ein inkonsistentes Ergebnis erzeugen. Der obige Fehler wird durch eine Anfrage verursacht, mit der versucht wird, eine Sperre zu erzielen, die bereits an anderer Stelle gehalten wird, und die Zeitüberschreitung, nachdem sie nicht rechtzeitig erzielt werden konnte. Stripe verarbeitet diese fehlgeschlagenen Anfragen nicht, was bedeutet, dass ihnen keine [Anfrage-ID](https://docs.stripe.com/api/request_ids.md) zugewiesen wird. Zeitüberschreitungen bei Sperren haben eine andere Ursache als Ratenbegrenzungen, die Abhilfemaßnahmen sind aber ähnlich. Ebenso wie bei Ratenbegrenzungsfehlern empfehlen wir, den Versuch nach einem exponentiellen Backoff-Zeitplan zu wiederholen (siehe [Sinnvoller Umgang mit Begrenzungen](https://docs.stripe.com/rate-limits.md#handling-limiting-gracefully)). Anders als bei Ratenbegrenzungsfehlern wiederholen die in die [SDKs](https://docs.stripe.com/sdks.md) von Stripe integrierten Wiederholungsmechanismen Versuche mit `429`-Statuscodes, die durch Zeitüberschreitungen bei Sperren verursacht werden: #### Ruby ```ruby Stripe.max_network_retries = 2 ``` Sperrkonflikte werden durch gleichzeitige Zugriffe auf verwandte Objekte verursacht. Für Integrationen kann dies erheblich reduziert werden, indem sichergestellt wird, dass Mutationen für das gleiche Objekt in eine Warteschlange gestellt und stattdessen sequentiell ausgeführt werden. Gleichzeitige Vorgänge für die API können weiterhin durchgeführt werden. Versuchen Sie jedoch dafür zu sorgen, dass parallele Vorgänge nur für einheitliche Objekte ausgeführt werden. Es ist auch möglich, dass ein Sperrkonflikt angezeigt wird, dessen Ursache ein Konflikt mit einem internen Stripe-Hintergrundprozess ist. Dies sollte nur selten vorkommen, da es aber außerhalb der Kontrolle der Nutzer/innen liegt, wird empfohlen, dass alle Integrationen in der Lage sein sollten, Anfragen zu wiederholen. ## Belastungstests Es ist üblich, dass sich Nutzer/innen auf ein wichtiges Verkaufsereignis vorbereiten, indem sie ihre Systeme einem Belastungstest unterziehen, bei dem die Stripe API in einer Sandbox ausgeführt wird. Wir raten im Allgemeinen von dieser Praxis ab, da die Grenzwerte für die API in einer Sandbox niedriger sind, sodass der Belastungstest wahrscheinlich auf Grenzwerte stößt, die er in der Produktion nicht erreichen würde. Eine Sandbox ist auch kein perfekter Ersatz für Live-Aufrufe der API, und dies kann etwas irreführend sein. Beispielsweise wird beim Erstellen einer Zahlung im Live-Modus eine Anfrage an ein Zahlungs-Gateway gesendet, die dann in einer Sandbox simuliert wird, was zu deutlich unterschiedlichen Latenzprofilen führt. Als Alternative empfehlen wir, Integrationen so zu erstellen, dass sie über ein konfigurierbares System für die Simulation von Anfragen an die Stripe-API verfügen, das Sie für Belastungstests aktivieren können. Um realistische Ergebnisse zu liefern, sollten sie Latenz simulieren, indem sie sich für eine Zeit im Ruhezustand befinden, den Sie durch Messen der Dauer von Aufrufen der Stripe-API im echten Live-Modus aus der Perspektive der Integration bestimmen. ## Zuordnung von API-Leseanfragen Stripe bietet Zugriff auf seine API-Leseanfragen (GET), um angemessene Suchaktivitäten im Zusammenhang mit Zahlungsintegrationen zu erleichtern. Um die Servicequalität für alle Nutzer/innen zu maximieren, bietet Stripe die folgenden Zuordnungen für Leseanfragen basierend auf der Anzahl der Transaktionen: - Die API-Leseanfragen Ihres Kontos dürfen durchschnittlich 500 pro Transaktion nicht überschreiten. Wenn Sie beispielsweise 100 Transaktionen in 30 Tagen verarbeiten, dürfen Sie in diesem Zeitraum die Anzahl von 50.000 API-Leseanfragen nicht überschreiten. - Bei Verwendung von Connect haben eine Plattform und ihre verbundenen Konten unterschiedliche API-Leseberechtigungen: - Jedes verbundene Konto verfügt über eine eigene Zuordnung für initiierte Anfragen (500 Anfragen pro Transaktion). - Connect-Plattformen verwenden eine separate Zuweisung, um Leseanfragen im Namen ihrer verbundenen Konten durchzuführen, indem sie entweder ihren geheimen API-Schlüssel oder OAuth-Zugriffstoken verwenden. Diese Zuordnung beträgt ebenfalls 500 Anfragen pro Transaktion, basierend auf der aggregierten Transaktionsanzahl der verbundenen Konten. - Die Kennzahlen werden über einen rollierenden Zeitraum von 30 Tagen (die letzten 30 Tage) berechnet. - Jedem Konto, unabhängig von der Anzahl der Transaktionen, werden mindestens 10.000 Leseanfragen pro Monat zugewiesen. - API-Schreibanfragen haben kein Zuordnungslimit. Aufrufe der folgenden API-Endpoints sind von den obigen Zuordnungslimits ausgenommen: - [Datenprodukte](https://docs.stripe.com/data.md) - [Produkte zur Berichterstattung](https://docs.stripe.com/stripe-reports.md) - [Steuerprodukte](https://docs.stripe.com/tax.md) Um Ihr API-Anfragevolumen zu reduzieren, können Sie [Data Pipeline](https://docs.stripe.com/data/data-pipeline.md) für einen vollständigen Export der API-Daten in Ihre lokale Datenbank oder Ihren Anbieter verwenden. > #### Anfragen filtern, um paginierte Aufrufe zu begrenzen > > Einige Listen-Endpoints geben [mehrere Seiten](https://docs.stripe.com/api/pagination.md) mit Ergebnissen zurück und erfordern möglicherweise mehrere Anfragen, um den vollständigen Satz an API-Objekten für einen Listenvorgang zurückzugeben. Wenden Sie nach Möglichkeit Filter an, um Ihre Listenergebnisse einzugrenzen. ## 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.