X veröffentlicht Twitter-API-Rate-Limits nicht mehr nach Stufe

Wie sehen die Twitter-API-Rate-Limits 2026 aus?

Nichts in der aktuellen Dokumentation von X legt Twitter-API-Rate-Limits nach Plan-Stufe fest. Die Live-Tabellen sind nach Endpunkt geordnet und in zwei Spalten geteilt, eine für Limits pro App, die gelten, wenn du dich mit einem Bearer Token authentifizierst, und eine für Limits pro Nutzer, die unter OAuth 1.0a oder OAuth 2.0 Nutzer-Tokens gelten. Jede Zahl unten stammt aus docs.x.com/x-api/fundamentals/rate-limits, gelesen am 12. September 2026.

Fenster sind 15 Minuten, sofern der Eintrag nichts anderes sagt. Das sind die Endpunkte, die ein Listening- oder Monitoring-Build tatsächlich berührt.

Zwei Einträge in dieser Tabelle lohnen einen zweiten Blick. Recent Search gibt einer App 450 Anfragen, einem Nutzer aber nur 300, also ist das App-only Bearer Token die stärkere Anmeldung fürs Monitoring. Full-Archive Search wird von einem Limit pro Sekunde ebenso regiert wie von einem pro Fenster, was bedeutet, dass ein Backfill-Job ein Sleep zwischen den Aufrufen braucht statt eines Bursts mit anschließender Wartezeit.

Für welche Stufen gelten die Twitter-API-Rate-Limits?

X betreibt jetzt zwei kommerzielle Ebenen, Pay-per-Use und Enterprise, und die Abo-Stufen Free, Basic und Pro, die ältere Guides noch zitieren, gibt es nicht mehr. Das Changelog datiert den Wechsel. X kündigte den Pay-per-Use-Pilotversuch am 20. Oktober 2025 an und startete die Pay-per-Use-Preise am 6. Februar 2026, während Basic und Pro noch verfügbar waren, und migrierte dann Basic-Abonnenten nach dem 1. Juni 2026 und Pro-Abonnenten nach dem 1. September 2026. Die Rate-Limit-Tabellen oben tragen überhaupt keine Stufen-Spalte, und das ist die ehrliche Antwort auf "Wie hoch sind die Limits bei Basic". Es gibt kein Basic.

Wo X noch nach Ebene trennt, sehen die Zahlen so aus.

Wo widerspricht sich X bei diesen Zahlen?

Drei aktive Seiten auf docs.x.com widersprechen einander, und die Widersprüche sind nicht kosmetisch.

Der erste betrifft die Zahl der Filtered-Stream-Regeln. Die Einführungsseite zum Filtered Stream setzt Enterprise auf "25,000+" Regeln pro Projekt. Die Enterprise-Preisseite, die dasselbe Produkt beschreibt, setzt sie auf "5,000+ rules". Beide Seiten waren am 12. September 2026 aktiv, und keine verlinkt die andere als Korrektur.

Der zweite betrifft die Abfragelänge bei den Post Counts. Die Rate-Limit-Tabelle führt /2/tweets/counts/all mit dem Hinweis "1024 query length". Die Seite zum Query Builder für Counts sagt "Your query can be 512 characters long for pay-per-use customers, or up to 4,096 characters for Enterprise customers" und deckt damit beide Counts-Endpunkte mit einer einzigen Zahl ab. Eine Abfrage mit 1.024 Zeichen gegen /2/tweets/counts/all liegt also innerhalb des Limits der einen Seite und außerhalb des Limits der anderen.

Der dritte ist ein toter Verweis. Beide Query Builder für die Suche und der Regel-Builder für den Filtered Stream sagen dir, dass deine Limits von deiner Zugriffsebene abhängen, und verlinken für die Details auf /x-api/getting-started/about-x-api. Diese Seite enthält keinen Abschnitt zur Zugriffsebene mehr. Sie hat Capabilities, API-Versionen, Ressourcen und Pay-per-Usage-Preise und nichts, was eine Stufe benennt. Die Seite unter docs.x.com/fundamentals/rate-limits trägt die Beschreibung "Understand X API rate limits across access tiers and endpoints" und listet dann keine Stufen, nur einen Link hinaus zur Endpunkt-Tabelle.

Die Lehre für alle, die ein Build budgetieren: Behandle die Tabelle pro Endpunkt als das maßgebliche Dokument und die Prosaseiten als veraltet.

Wie liest man die Rate-Limit-Header?

X gibt bei jeder Antwort drei Header zurück, und sie sind die einzige Echtzeitquelle der Wahrheit.

x-rate-limit-limit: 900
x-rate-limit-remaining: 847
x-rate-limit-reset: 1705420800

x-rate-limit-limit ist die Obergrenze für das laufende Fenster, x-rate-limit-remaining ist der Rest, und x-rate-limit-reset ist ein Unix-Zeitstempel dafür, wann das Fenster umschlägt. Überschreite die Obergrenze und du bekommst ein 429 mit diesem Body:

{
  "errors": [{
    "code": 88,
    "message": "Rate limit exceeded"
  }]
}

Der Fehler code: 88 hat jede Neufassung dieser API seit v1.1 überlebt, also lohnt es sich, explizit darauf zu prüfen statt nur auf den Statuscode. Der Rat von X zur Erholung lautet: x-rate-limit-reset lesen, bis zu diesem Zeitstempel warten und danach exponentielles Backoff anwenden.

Sind Rate Limits dasselbe wie deine Rechnung?

Nein, und X benennt die Trennung direkt: Rate Limits steuern die Anfragefrequenz zugunsten der Systemstabilität, während die Nutzungsabrechnung die abgerufenen Daten berechnet. Du kannst innerhalb jedes Rate Limits bleiben und trotzdem Geld ausgeben, und du kannst ein Rate Limit erreichen, ohne zusätzlich etwas auszugeben.

Lesevorgänge werden pro zurückgegebener Ressource berechnet, nicht pro Anfrage. Ein gelesener Post kostet $0.005 und ein gelesener Nutzer $0.010. Ressourcen werden innerhalb eines 24-Stunden-Fensters in UTC dedupliziert, also wird derselbe Post zweimal am Tag nur einmal berechnet, und X nennt diese Deduplizierung eine weiche Zusage statt eines Versprechens. Der Pay-per-Use-Plan ist auf 3 Millionen gelesene Posts pro monatlichem Abrechnungszyklus gedeckelt, egal wie sanft du deine Anfragen taktest. Das vollständige Kostenbild, inklusive der Schreibseite, ist in der Notiz zu den Twitter-API-Preisen aufgeschlüsselt.

Welches Limit stoppt einen Monitoring-Build wirklich?

Das monatliche Limit für gelesene Posts, nicht das Anfragelimit pro Fenster. Recent Search mit 450 Anfragen pro 15 Minuten und 100 Ergebnissen pro Anfrage sind auf dem Papier 45.000 Posts pro Fenster, was ein Kontingent von 3 Millionen Posts in weniger als einem Tag Dauerabfrage aufbrauchen würde. Die Anfrage-Obergrenze ist großzügig; die Ressourcen-Obergrenze ist das Budget.

Das ändert die Form einer guten Abfrage. Enge Regeln, die wenige Treffer liefern, kosten wenig, und eine breite Regel, die auf ein häufiges Wort passt, verbrennt das Kontingent, während du schläfst. Filtered Stream ist das billigere Instrument für durchgehende Abdeckung, weil er nur liefert, was auf deine Regeln passt, und die Regeln selbst kostenlos vorgehalten werden. Diese Regeln gut zu schreiben ist dieselbe Fähigkeit wie das Schreiben einer guten Suchabfrage, behandelt in der Referenz zu den erweiterten Suchoperatoren von X.

Die andere Hälfte der Rechnung ist, dass X ein einziges Netzwerk ist. Eine Kauffrage, die auf X gestellt wird, wird meist auch auf Reddit und Hacker News gestellt, und diese Plattformen messen den Zugang anders, wie der Vergleich der Reddit-API-Rate-Limits zeigt. Teams, die mit der X-API angefangen und dann die Abdeckungslücke bepreist haben, landen eher beim Listening über mehrere Netzwerke, statt dafür zu zahlen, eines zu verbreitern.

Häufig gestellte Fragen

Wie hoch ist das Rate Limit der X-Such-API?

Recent Search unter /2/tweets/search/recent erlaubt 450 Anfragen pro 15 Minuten mit einem App-only Bearer Token und 300 pro 15 Minuten mit einem Nutzer-Token, mit 10 Ergebnissen standardmäßig und höchstens 100. Full-Archive Search unter /2/tweets/search/all erlaubt 1 Anfrage pro Sekunde und 300 pro 15 Minuten pro App, mit 10 Ergebnissen standardmäßig und höchstens 500.

Hat X noch ein Free-Tier?

Nicht als dokumentiertes Produkt. X startete die Pay-per-Use-Preise am 6. Februar 2026, und die aktuelle Dokumentation zum Zugang führt dich durch Anmeldung, App-Erstellung und Speichern der Zugangsdaten, ohne eine Stufe zu benennen. Das Wort "Free" überlebt nur in Changelog-Einträgen, darunter der Hinweis vom 22. August 2025, der POST /2/users/:id/likes und POST /2/users/:id/following aus dem Free-Tier entfernte.

Was bedeutet HTTP 429 bei der X-API?

Es bedeutet, dass du ein Rate Limit für diesen Endpunkt im laufenden Fenster überschritten hast. Der Response-Body trägt code: 88 und die Meldung "Rate limit exceeded". Lies den Header x-rate-limit-reset für den Unix-Zeitstempel, an dem das Fenster zurückgesetzt wird, und wiederhole die Anfrage nicht davor.

Zählen Rate Limits pro App oder pro Nutzer?

Beides, und welches gilt, hängt davon ab, wie du dich authentifiziert hast. Anfragen mit Bearer Token zählen gegen das Limit pro App, und Anfragen mit OAuth-1.0a- oder OAuth-2.0-Nutzer-Token zählen gegen das Limit pro Nutzer für diesen Nutzer. Mehrere Endpunkte veröffentlichen nur eine der beiden Spalten, was bedeutet, dass der andere Authentifizierungsmodus dort gar nicht angeboten wird.

Wie viele Filtered-Stream-Regeln kann ich betreiben?

Ein Pay-per-Use-Projekt bekommt 1.000 Regeln mit je bis zu 1.024 Zeichen über eine einzelne Verbindung, mit einer Zustellung von höchstens 250 Posts pro Sekunde. Enterprise hebt die Regellänge auf 2.048 Zeichen und erlaubt mehrere Verbindungen. Bei der Regelzahl für Enterprise widersprechen sich die eigenen Seiten von X, mit 25.000+ in der Einführung zum Filtered Stream und 5.000+ auf der Enterprise-Preisseite.

Gelten Rate Limits auch für den Usage-Endpunkt selbst?

Ja. GET /2/usage/tweets, der Endpunkt, der deinen eigenen Post-Verbrauch meldet, ist auf 50 Anfragen pro 15 Minuten pro App gedeckelt und bietet kein Limit pro Nutzer. Den eigenen Verbrauch abzufragen ist billig, aber nicht frei von der Buchhaltung, also lies ihn nach Plan statt vor jedem Aufruf.

Wie viel kostet ein Post-Read über die X-API?

Ein Post-Read kostet 0,005 $ und ein User-Read 0,010 $, abgerechnet pro zurückgegebener Ressource statt pro Request. X dedupliziert Ressourcen innerhalb eines 24-Stunden-Fensters in UTC, sodass derselbe Post an einem Tag zweimal abgerufen nur einmal zählt, auch wenn X diese Deduplizierung selbst als weiche Garantie statt als Zusage bezeichnet. Der Pay-per-Use-Plan deckelt die Post-Reads unabhängig vom Tempo bei 3 Millionen pro Abrechnungszyklus.

Wann hat X die Stufen Basic und Pro abgeschafft?

X startete die Pay-per-Use-Preise am 6. Februar 2026, während Basic und Pro noch verfügbar waren, und stellte beide danach ein. Basic-Abonnenten wurden nach dem 1. Juni 2026 migriert, Pro-Abonnenten nach dem 1. September 2026, womit Enterprise und Pay-per-Use blieben. Ältere Anleitungen, die noch Basic- oder Pro-Limits zitieren, beschreiben eine Preisstruktur, die es nicht mehr gibt.

Warum liegt das Rate Limit pro Nutzer bei manchen Endpunkten höher als pro App?

Es gibt keine einheitliche Regel. Bei /2/tweets erhält ein App-Bearer-Token 3.500 Requests pro 15 Minuten, ein User-Token dagegen 5.000, und /2/tweets/:id folgt demselben Muster mit 450 gegenüber 900. Bei der Recent Search verhält es sich umgekehrt, mit 450 pro App gegenüber 300 pro Nutzer, das stärkere Credential hängt also vom jeweiligen Endpunkt ab und nicht von einer festen Hierarchie zwischen App- und Nutzer-Auth.

Wie lässt sich kontinuierliches X-Monitoring am günstigsten betreiben?

Mit Filtered Stream statt mit gepolltem Search. Recent Search mit 450 Requests pro 15 Minuten und 100 Ergebnissen pro Aufruf kann rechnerisch 45.000 Posts pro Fenster liefern, genug, um ein monatliches Kontingent von 3 Millionen Posts bei durchgehendem Polling in unter einem Tag aufzubrauchen. Filtered Stream liefert nur, was zu den eigenen Regeln passt, und das Halten dieser Regeln kostet nichts, ein gut zugeschnittenes Regelwerk deckt also dieselbe Fläche für einen Bruchteil der Reads ab.