Ein Rate Limit begrenzt, wie viele Anfragen du in einem Zeitfenster senden darfst. Bei der offiziellen X API hat jeder Endpoint sein eigenes Limit pro 15 Minuten, getrennt gezählt für deine App und für jeden Nutzer-Token. Wer es überschreitet, bekommt HTTP 429, bis das Fenster zurückgesetzt wird. Auch Drittanbieter-APIs begrenzen Anfragen, meist pro Sekunde oder pro Minute über alle Endpoints hinweg.

Dieser Beitrag listet die offiziellen Limits der meistgenutzten Endpoints auf, erklärt die Header und die 429-Antwort und stellt die veröffentlichten Limits einiger Alternativen daneben. Alles wurde am 2026-10-10 geprüft. Wir betreiben TwittrAPI, eine der Alternativen, lies diesen Teil also mit diesem Wissen.

So funktionieren die Rate Limits der X API

Die Seite zu den X-Rate-Limits beschreibt drei Regeln:

  • Fenster. Limits werden alle 15 Minuten oder alle 24 Stunden zurückgesetzt. Die Tabellen auf dieser Seite zeigen 15-Minuten-Limits, sofern nichts anderes dasteht.
  • Pro Endpoint. Jeder Endpoint hat sein eigenes Limit. Ist dein Such-Limit aufgebraucht, bleibt das Limit für die Nutzer-Abfrage unberührt.
  • Pro App oder pro Nutzer. Anfragen mit einem App-only-Bearer-Token zählen für das Limit der App. Anfragen mit dem OAuth-1.0a- oder OAuth-2.0-Token eines Nutzers zählen für das Limit dieses Nutzers.

Enterprise-Kunden bekommen individuelle Limits.

Limits der gängigen Endpoints

Das sind die 15-Minuten-Limits von derselben Seite:

EndpointWas er machtPro AppPro Nutzer
GET /2/tweetsPosts per ID abrufen3.5005.000
GET /2/tweets/:idEinen Post abrufen450900
GET /2/users/:idEinen Nutzer per ID abrufen300900
GET /2/users/by/username/:usernameEinen Nutzer per Username abrufen300900
GET /2/tweets/search/recentAktuelle Posts suchen450300
GET /2/users/:id/tweetsPosts eines Nutzers10.000900
GET /2/users/:id/followersFollower eines Nutzers300300

Zwei Dinge fallen auf. Nutzer-Abfragen sind mit einem App-Token auf 300 Anfragen pro 15 Minuten begrenzt, das sind 20 pro Minute. Follower-Listen haben für Apps und Nutzer dasselbe Limit von 300. Die Follower vieler großer Accounts abzurufen dauert deshalb sehr lange, auch wenn du es bezahlen kannst.

Rate Limits und Rechnung sind getrennt

Seit 2026 rechnet die X API nach Nutzung ab: Du kaufst Guthaben, und jeder gelesene Post kostet 0,005 $, jeder gelesene Nutzer 0,010 $, laut der Preisseite der X API. Die Rate Limits ändern sich nicht damit, wie viel du ausgibst. Ein größeres Guthaben bringt keine zusätzlichen Anfragen pro Fenster.

Zusätzlich zu den Rate Limits gibt es eine Nutzungsgrenze. Nutzungsbasierte Abrechnung endet bei 3 Millionen gelesenen Posts pro monatlichem Abrechnungszeitraum, darüber brauchst du Enterprise. Die Preisseite sagt außerdem, dass eine Ressource, die du am selben UTC-Tag mehrfach abrufst, nur einmal berechnet wird.

Beide Grenzen wirken zusammen. Die aktuelle Suche liefert höchstens 100 Posts pro Anfrage, 450 Anfragen in einem Fenster können also bis zu 45.000 Posts zurückgeben, was beim Preis für gelesene Posts bis zu 225 $ kostet. Wiederholst du das alle 15 Minuten, erreichst du die Grenze von 3 Millionen in deutlich weniger als einem Tag. X API Preise 2026 enthält weitere Rechenbeispiele.

Header und die 429-Antwort

Jede Antwort der X API enthält drei Header:

HeaderBedeutung
x-rate-limit-limitErlaubte Anfragen im Fenster
x-rate-limit-remainingVerbleibende Anfragen im aktuellen Fenster
x-rate-limit-resetUnix-Zeit, zu der das Fenster zurückgesetzt wird

Ist das Limit aufgebraucht, antwortet die API mit HTTP 429, dem Fehlercode 88 und der Meldung „Rate limit exceeded“. X empfiehlt, x-rate-limit-reset zu lesen und bis zu diesem Zeitpunkt zu warten. Gibt es keine Reset-Zeit, hilft exponentielles Backoff. Der Beispielcode von X wartet mindestens 60 Sekunden, bevor er es erneut versucht.

Ein kleiner Python-Helfer dafür:

import random
import time
 
import requests
 
 
def get_with_backoff(url, headers, max_tries=5):
    for attempt in range(max_tries):
        resp = requests.get(url, headers=headers, timeout=30)
        if resp.status_code != 429:
            return resp
 
        reset = resp.headers.get("x-rate-limit-reset")
        retry_after = resp.headers.get("retry-after")
        if reset:
            wait = max(int(reset) - time.time(), 1)
        elif retry_after:
            wait = int(retry_after)
        else:
            wait = min(60 * 2**attempt, 900)
        time.sleep(wait + random.uniform(0, 1))
    raise RuntimeError("still rate limited after retries")

Er berücksichtigt auch Retry-After, das mehrere Drittanbieter-APIs statt eines Reset-Zeitstempels senden. Die kleine zufällige Verzögerung verhindert, dass mehrere Worker im selben Moment erneut versuchen.

Veröffentlichte Limits der Alternativen

Drittanbieter-APIs für öffentliche X-Daten legen eigene Limits fest. Sie werden meist pro Account über alle Endpoints gezählt, nicht pro Endpoint. Das sind die Werte, die jeder Anbieter veröffentlicht.

twitterapi.io: nach Kontostatus

Die QPS-Seite von twitterapi.io sagt, dass Accounts, die noch nie bezahlt haben, auf 0,2 Anfragen pro Sekunde begrenzt sind, also eine Anfrage alle 5 Sekunden. Ein einmaliger Guthabenkauf erhöht das auf 20 Anfragen pro Sekunde. Abos reichen von 20 pro Sekunde in den unteren Tarifen bis zu 500 pro Sekunde bei Business. Wer darüber liegt, bekommt 429 mit einem Retry-After-Header, und laut der Seite wird der Account nicht gesperrt.

Andere Seiten von twitterapi.io nennen andere Zahlen. Die Einführung der Dokumentation erwähnt bis zu 200 QPS pro Client. Wir zitieren die eigene Limit-Seite und empfehlen, bei ihnen nachzufragen.

SocialData: 120 Anfragen pro Minute

Die Rate-Limit-Seite von SocialData setzt 120 Anfragen pro Minute und Nutzer über alle Endpoints und sagt, höhere Limits gebe es kostenlos per E-Mail. Die Fehlerseite sagt, ein 429 bedeute Überschreitung, und empfiehlt exponentielles Backoff. Ein 402 bedeutet, dass das Guthaben zu niedrig ist, also ein anderes Problem als ein Rate Limit.

RapidAPI: Plan-Kontingent plus Fenster pro Minute

Jede auf RapidAPI verkaufte API, auch unsere, kann zwei Arten von Limits haben. Die Dokumentation zu den Antwort-Headern von RapidAPI beschreibt sie:

  • x-ratelimit-requests-limit und x-ratelimit-requests-remaining zeigen das Kontingent deines Plans, das je nach Plan täglich oder monatlich zurückgesetzt wird.
  • x-ratelimit-limit und x-ratelimit-remaining zeigen ein 60-Sekunden-Fenster. Ist es aufgebraucht, kommt 429. Diese Header erscheinen nur, wenn die API ein solches Limit hat.

Das Kontingent ist das, was du bezahlt hast. Das Minutenfenster liefert 429, wenn du zu schnell sendest.

TwittrAPI

Bei RapidAPI und JojAPI stehen die Limits jedes Plans im Eintrag auf dem Marktplatz. Bei Direktkonten hängen die Limits vom Konto ab, frag den Support, wenn du mehr Durchsatz brauchst. Wer darüber liegt, bekommt HTTP 429. Unsere Dokumentation zu Rate Limits (englisch) behandelt Backoff, und die offiziellen SDKs für Python und Node.js wiederholen 429-Antworten für dich. Direktkonten können höhere Stufen buchen, bis zu 1.000 Anfragen pro Sekunde in Eigenregie, auf der Preisseite. TwittrAPI für Teams (englisch) deckt mehr ab.

Wir rechnen pro Aufruf ab, ab 0,065 $ pro 1.000 Aufrufe bei den Direkt-Preisen. Aufrufe, die mit 400, 407, 408, 409 oder einem 5xx-Fehler fehlschlagen, werden erstattet.

Im Vergleich

Offizielle X APItwitterapi.ioSocialDataTwittrAPI
Einheit des LimitsAnfragen pro Endpoint je 15 Min (oder 24 Std)Anfragen pro Sekunde, pro AccountAnfragen pro Minute, pro NutzerPro Plan auf Marktplätzen, pro Account bei Direkt
Beispiel300 Nutzer-Abfragen / 15 Min pro App20/s nach jedem Kauf120/MinSiehe Eintrag oder Support fragen
Über dem Limit429, Code 88429 mit Retry-After429429
Monatsgrenze3 Mio. gelesene Posts bei Abrechnung nach NutzungAuf der Limit-Seite nicht genanntNicht genanntPlan-Kontingent auf Marktplätzen; Prepaid-Guthaben bei Direkt

Unter den Limits bleiben

Die meisten 429-Fehler kommen von wenigen Gewohnheiten. Diese Punkte helfen bei jeder der genannten APIs:

  1. Cache, was sich nicht ändert. Profile und alte Posts ändern sich langsam. Speichere sie und lade sie nach Zeitplan neu.
  2. Nutze Batch-Endpoints. GET /2/tweets nimmt viele IDs und hat das höchste Abruf-Limit der Tabelle. Manche Drittanbieter-APIs haben ähnliche Sammelabfragen.
  3. Verteile Anfragen. Eine gleichmäßige Rate unter dem Limit schlägt Bursts mit anschließendem Warten.
  4. Lies die Header. Werde langsamer, wenn die verbleibende Zahl klein wird, statt auf das 429 zu warten.
  5. Bei 429 zurückfahren, dann weitermachen. Wiederhole nie in einer engen Schleife. Das hält dich länger im Limit.

Wenn du überlegst, x.com direkt zu scrapen, um API-Limits zu umgehen: Auch dort hat X eigene Grenzen. How to scrape Twitter (X) data in 2026 (englisch) erklärt, worauf du stößt.

Häufige Fragen

Wie hoch ist das Rate Limit der X API?

Es gibt keine einzelne Zahl. Jeder Endpoint hat sein eigenes Limit pro 15-Minuten-Fenster, getrennt gezählt pro App und pro Nutzer. Die Nutzer-Abfrage per Username erlaubt zum Beispiel 300 Anfragen pro 15 Minuten pro App und 900 pro Nutzer.

Wie lange gilt ein Rate Limit der X API?

Bis das aktuelle Fenster zurückgesetzt wird, je nach Endpoint nach 15 Minuten oder 24 Stunden. Der Header x-rate-limit-reset nennt die genaue Zeit.

Was bedeutet der Fehler 429 mit Code 88?

Du hast mehr Anfragen gesendet, als der Endpoint im aktuellen Fenster erlaubt. Warte bis zu der Zeit in x-rate-limit-reset und mach dann weiter.

Erhöht mehr Geld die Rate Limits der X API?

Nicht bei der Abrechnung nach Nutzung. Dein Guthaben bezahlt Anfragen, aber die Limits pro Fenster bleiben gleich. Enterprise-Kunden bekommen individuelle Limits.

Haben Twitter-APIs von Drittanbietern Rate Limits?

Ja. Sie gelten meist pro Account pro Sekunde oder pro Minute. twitterapi.io, SocialData und die Pläne bei RapidAPI veröffentlichen ihre jeweils selbst. Bei einem TwittrAPI-Key schaust du in den Eintrag auf dem Marktplatz oder fragst beim Support nach einem Direktkonto. Die günstigste Twitter API 2026 vergleicht die Preise, und unsere API kannst du mit 0,50 $ Testguthaben über /start ausprobieren.

Quellen