TikTok API Upload Limit: vier Zahlen auf einer Seite – und jede zählt etwas anderes
- Die Zahl 15 steht in der offiziellen Dokumentation, aber als Posting-Cap pro Creator-Konto – und sie wird laut Originaltext über alle API-Clients hinweg geteilt.
- Die Zahl fünf zählt keine Posts, sondern Nutzer: "Unaudited API Clients can allow up to 5 users to post in a 24 hour window." Sie gilt nur vor dem Audit.
- Der Creator-Cap hat gar keine Zahl. Er ergibt sich laut Dokumentation aus den Schätzungen, die Sie selbst im Audit-Formular angegeben haben.
- Die vierte Begrenzung ist keine Zahl, sondern ein Zustand: Ungeprüfte Clients posten ausschließlich in SELF_ONLY – sichtbar nur für den Kontoinhaber.
Sie planen eine Veröffentlichungsstrecke und wollen wissen, wie viele Videos am Tag durch die Leitung passen. In Foren und Anbieter-Dokus kursiert dafür eine Zahl: fünfzehn Posts in 24 Stunden. Sie steht so oft da, dass sie wie eine Spezifikation wirkt.
Ich habe die offizielle Seite am 21. September 2026 geholt und gelesen. Die Fünfzehn steht tatsächlich dort. Nur zählt sie nicht das, wofür sie überall zitiert wird. Auf derselben Seite stehen insgesamt vier Begrenzungen, und keine zwei von ihnen zählen dieselbe Einheit.
Die Fünfzehn zählt Creator-Konten, nicht Ihren Client
Im Abschnitt zu den Caps heißt es wörtlich: "Posting cap: There is a limit on the number of posts that can be made to a creator account in a 24-hour window via Direct Post API. The upper limit may vary among creators (typically around 15 posts per day/ creator account) and is shared across all API Clients using Direct Post."
Drei Dinge daran werden beim Zitieren regelmäßig abgeschnitten. Erstens: Die Grenze hängt am Creator-Konto, nicht an Ihrer Anwendung. Zweitens: "typically around" und "may vary" – es ist ausdrücklich keine feste Spezifikation, sondern ein typischer Wert. Drittens, und das ist betrieblich das Wichtigste: Sie wird über alle Direct-Post-Clients hinweg geteilt. Wenn ein Konto zusätzlich über ein zweites Werkzeug bespielt wird, rechnet das in denselben Topf.
Vier Begrenzungen auf einer Seite, und jede zählt eine andere Einheit: Nutzer, Creator-Konten, Posts – und einmal gar keine Zahl, sondern einen Sichtbarkeitszustand.
Das erklärt, warum Erfahrungsberichte sich so zuverlässig widersprechen. Wer über ein einzelnes Konto arbeitet, stößt an eine andere Wand als jemand, der zwanzig Konten anbindet; wer vor dem Audit testet, an eine dritte. Alle drei berichten anschließend wahrheitsgemäß von "dem Limit" – und meinen verschiedene Sätze derselben Seite.
Die Fünf zählt Nutzer – und sie gilt nur, solange Sie ungeprüft sind

Der zweite Wert steht ein paar Zeilen darüber und gilt ausschließlich vor dem Audit: "User cap: Unaudited API Clients can allow up to 5 users to post in a 24 hour window. All user accounts using the API client to post must be set to private at the time of posting."
Gezählt werden Personen, nicht Uploads. Und der zweite Satz wird fast nie mitzitiert, obwohl er der härtere ist: Die Konten müssen zum Zeitpunkt des Postens auf privat stehen. Das ist keine Empfehlung, sondern eine Bedingung der Nutzung im ungeprüften Zustand. (Die Seite existiert nur als englischsprachige Originalseite; eine deutsche Fassung gibt es nicht.)
Der Unterschied zwischen "fünf Nutzer" und "fünf Uploads" klingt nach Wortklauberei, verändert die Planung aber vollständig. Wer fünf Uploads liest, denkt an eine Tagesmenge und rechnet hoch. Wer fünf Nutzer liest, versteht, dass die Grenze an der Anzahl der angebundenen Konten hängt – und dass ein sechstes Konto nicht dadurch hinzukommt, dass man seltener postet. Es sind zwei verschiedene Ressourcen, und die Dokumentation teilt sie konsequent.
Der Creator-Cap ist die einzige Grenze, die Sie selbst geschrieben haben
Die dritte Begrenzung enthält überhaupt keine Zahl: "Creator cap: There will be a 24-hour active creator cap for each API client based on the usage estimates provided in the audit application form."
Anders gesagt: Die Obergrenze, an die Sie später stoßen, ist die Schätzung, die Sie im Antragsformular selbst eingetragen haben. Das erklärt, warum zwei Teams mit identischer Technik unterschiedliche Decken melden – und warum die Suche nach "der echten Zahl" ins Leere läuft. Es gibt keine allgemeingültige; es gibt Ihre.
Für die Praxis heißt das vor allem eines: Diese Zahl entsteht an einem Tag, an dem noch niemand weiß, wie das Projekt in sechs Monaten aussieht – nämlich beim Ausfüllen des Antrags. Wer dort defensiv schätzt, weil er "erst mal klein anfangen" will, schreibt sich eine Decke, die später erklärungsbedürftig ist. Das ist keine technische Frage und keine, die man durch Optimierung im Code löst.
Die vierte Begrenzung ist keine Zahl, sondern ein Zustand

"Private Viewership: Unaudited API Clients can only post contents in SELF_ONLY viewership." Wer vor dem Audit veröffentlicht, veröffentlicht für genau eine Person: den Kontoinhaber. Um das später zu ändern, muss laut Dokumentation erst das Konto auf öffentlich gestellt und anschließend jeder einzelne Beitrag auf "Everyone" umgestellt werden – von Hand.
Für die Planung heißt das: Die Frage "wie viele Videos pro Tag" ist vor dem Audit gar nicht die relevante Frage. Vor dem Audit ist die Reichweite null, unabhängig von der Menge.
Diese vierte Begrenzung erklärt auch eine Beobachtung, die in Foren regelmäßig auftaucht: Der Testlauf funktioniert, die Statuscodes sind sauber, die Beiträge erscheinen im Konto – und trotzdem passiert nichts. Wer das für ein Reichweitenproblem hält, sucht anschließend an der falschen Stelle: an Hashtags, an Uhrzeiten, an der Länge. Gesucht werden müsste am Zustand der Sichtbarkeit, und der steht nicht in der Auswertung, sondern in der Dokumentation.
Und es gibt noch einen Satz, der vor jeder Kapazitätsrechnung gelesen werden sollte. Im Abschnitt Intended Use führt TikTok als nicht akzeptabel auf: "A utility tool to help upload contents to the account(s) you or your team manages." Damit ist der mit Abstand häufigste Anwendungsfall – die eigenen Konten automatisch bespielen – ausdrücklich außerhalb des vorgesehenen Zwecks beschrieben. Bevor Sie Limits optimieren, klären Sie also, ob Ihr Vorhaben überhaupt in der Zweckbeschreibung vorkommt.
Wenn es das nicht tut, bleiben zwei Wege: die nativen Planungsfunktionen der Plattform, oder Konten im eigenen Browser betreiben statt über die Schnittstelle. Wir bauen mit NoobClaw den zweiten Weg – Anmeldung im eigenen Browser, keine Weitergabe von Passwörtern, je Konto eigene Inhalte, menschliche Prüfung vor der Veröffentlichung. Auch dabei gilt: Ob eine Betriebsweise regelkonform ist, entscheidet die Plattform und nicht der Anbieter des Werkzeugs. Was die Richtlinien zu mehreren Konten sagen, steht in Darf man mehrere TikTok-Accounts haben?; warum die Frage nach der Tagesfrequenz separat gestellt werden muss, in Wie oft am Tag auf TikTok posten?. Eine Plattform, die ihre Grenzen anders zuschneidet, zeigt der Reels-Text.
Häufige Fragen
Stimmen die 15 Posts pro 24 Stunden?
Die Zahl steht in der offiziellen Dokumentation, allerdings als Posting-Cap pro Creator-Konto und mit den Einschränkungen "typically around" und "may vary among creators". Zusätzlich heißt es, das Limit werde über alle Direct-Post-Clients hinweg geteilt. Als feste Obergrenze für eine einzelne Anwendung taugt die Zahl deshalb nicht.
Was ändert sich nach dem Audit?
Laut Dokumentation gelten der Nutzer-Cap von fünf und die SELF_ONLY-Sichtbarkeit für ungeprüfte Clients. Creator-Cap und Posting-Cap gelten ausdrücklich für geprüfte wie ungeprüfte Clients. Ein Audit hebt also nicht alle Begrenzungen auf, sondern zwei von vieren.
Gibt es die Seite auch auf Deutsch?
Nein. Die Content Sharing Guidelines von TikTok for Developers liegen nur als englischsprachige Originalseite vor; alle Zitate in diesem Text stammen von dort, abgerufen am 21. September 2026. Die Seite selbst weist als Stand den 4. August 2026 aus. Wer eine deutschsprachige Fassung zitiert bekommt, liest eine Übersetzung eines Dritten – und damit eine Quelle, die beim nächsten Update der Originalseite nicht mitwandert.
