Rate Limits
Wie wir rate-limiten
Rate Limiting läuft pro Account, gemessen in Requests pro Sekunde (QPS). Die Obergrenze hängt nur davon ab, ob du jemals Credits gekauft hast, plus eine kleine Anhebung bei den beiden höchsten Abo-Stufen.
Es gibt kein Monats- und kein Tageslimit — du kannst beliebig viele Credits pro Monat verbrauchen, solange du unter der Obergrenze pro Sekunde bleibst.
Stream-Abonnements (Account-Monitoring) sind getrennt von der REST API. Ein Stream-Plan enthält weder API-Credits noch ein höheres REST-Rate-Limit: REST-Aufrufe werden mit Credits bezahlt, und bis du Credits gekauft hast, bleibt dein Account auf dem kostenlosen Limit von einem Request alle 5 Sekunden.
Konkrete Limits
| Account-Status | Rate Limit |
|---|---|
Brandneuer Account (nie bezahlt) 0,2 req/s — genug zum Ausprobieren der API, motiviert zur ersten Aufladung. | 1 Request / 5 Sekunden |
Jeder Account, der mindestens einmal Credits gekauft hat Ein einmaliger Credit-Kauf reicht; kein Abo erforderlich. | 20 req/s |
Starter-, Builder- und Pro-Abonnements Diese Pläne unterscheiden sich bei Credits, Bonus und Credit-Rückgabe, nicht beim Durchsatz. Du brauchst dauerhaft mehr QPS? Siehe Scale und Business unten. | 20 req/s |
Scale-Abonnement | 50 req/s |
Business-Abonnement | 500 req/s |
Größerer Bedarf Schreib an contact@twitterapi.io mit deinem Use-Case und den erwarteten dauerhaften req/s. | Auf Anfrage |
Plan auswählen? Siehe /subscribe — Starter, Builder und Pro unterscheiden sich bei Credit-Vergabe, Aufladungs-Bonus-Prozent und rollierender Credit-Rückgabe. Wenn du dauerhaft mehr als 20 req/s brauchst, sind Scale (50 req/s) und Business (500 req/s) die Stufen, bei denen die Obergrenze steigt.
Burst-Traffic? Beim Erreichen der Obergrenze gibt es ein HTTP 429 (kein Retry-After-Header wird gesendet). Warte etwa eine Sekunde und versuche es mit exponentiellem Backoff erneut — wir sperren den Account nicht.