How to Get the TikTok Content Posting API: The Two Limits That Explain Why You Posted Successfully and Got Zero Views

The integration returns 200. The video appears in the account. The view counter sits at zero, then stays at zero, and you spend two days convinced you have shipped a bug.

You have not. You have shipped exactly what TikTok documented, and the documentation for it is two sentences long, sitting in a place nobody links to from the tutorials. This page is those two sentences and what they cost you.

The Sequence, Not the Form

People search "how to get the TikTok content posting API" expecting an application page. It is a chain, and each link can stall independently. Checked 2026-09-20, the documented path runs:

1. A registered app on the TikTok for Developers site.
2. Add the Content Posting API product to that app.
3. Enable the Direct Post configuration for the Content Posting API in your app. Skipping this is the single most common reason an otherwise correct integration cannot post directly.
4. Get approval and authorization of the video.publish scope. Approval is the platform saying your app may request it; authorization is a user granting it. Two different events, and both must happen.
5. The target TikTok user must have authorized your app for the video.publish scope - once per account, not once per app.
6. Hold the access token and open ID of that authorised user.

Get all six and your integration will post. It will also be subject to the two limits below, and those are the part that decides whether posting means anything.

The Two Limits of the Unaudited State

An API client that has not been through TikTok's audit is in a restricted mode by default. Verbatim, from the content-sharing guidelines, checked 2026-09-20:

"Unaudited API Clients can allow up to 5 users to post in a 24 hour window."

And, from the same documentation:

"Unaudited API Clients can only post contents in SELF_ONLY viewership."

The getting-started documentation states the second one a different way - "All content posted by unaudited clients will be restricted to private viewing mode" - which is the phrasing most people eventually find, usually after the second day of debugging.

Put them together and the failure mode writes itself. Five posting users per rolling 24 hours, and everything published is private. Nothing in the API response signals this. The call succeeds because it did succeed. The video exists because it does exist. Visibility was never part of what you asked for. We have written about each of these ceilings separately - the user cap in The Five-User Ceiling That Decides Whether Yours Works, and the way TikTok's rate limits get quoted at wildly different magnitudes in 600 Per Minute and 6 Per Minute Are Both Official - but the pair above is the one that produces the zero-views experience.

The Sentence That Explains the Entire Product Category

Now the part that is genuinely hard to read if you are building a posting tool for yourself. TikTok's intended-use section does not only describe what the API is for; it lists what it is not for, with explicit negative markers. Two of those entries, verbatim:

"A utility tool to help upload contents to the account(s) you or your team manages." - marked as not acceptable<br />"An app that copies arbitrary contents from other platforms to TikTok." - marked as not acceptable

Against the stated purpose: "API Clients should facilitate authentic creators to post original content to TikTok."

Read the first negative one more time. Building a tool to upload your own content to your own accounts is named, by the platform, as outside what this API is for. Not a grey area. Not an inference from the terms. A bullet point with a cross next to it.

We are not going to soften that, because it is the clearest thing the platform has ever said about this category, and it explains something people otherwise find baffling: why software exists that drives an ordinary logged-in browser instead of calling an API. The answer is not that the browser route is clever. It is that the API route was explicitly marked as not being for this, by the people who own the API. Our longer reading of that boundary is in TikTok's API Says Out Loud That It Is Not for Posting to Your Own Accounts.

The honest version of our own position, since we build in this space: running a normal browser session under your own login, with no credentials handed to anyone, with each account producing its own content, with a human reviewing before publication, and at human pacing. What we will not claim is that making content distinct settles the question. TikTok's spam language lists running many accounts with automation as a behaviour in its own right, connected by "or" rather than "and" - so "our output is varied" is not a compliance argument, and anyone selling you one is selling you a story. The platform decides; you keep a human in the loop and stay inside your own accounts.

Planning Around the Audit Without Inventing a Timeline

The audit is the gate that lifts both restrictions. TikTok's documentation is clear that a client "must undergo an audit to verify compliance with our Terms of Service" before those limits come off.

We are not going to publish a number of days. We could not source a first-party review-time figure on 2026-09-20, and the figures circulating in vendor blog posts are exactly the kind of mutually copied estimate that gets repeated until it sounds official. What we can point at is a vendor that documented its own experience of this class of approval, which is at least attributable - see How Long Does Social Media App Approval Take?, where one vendor put an attributable figure on this class of review.

What you can control is the shape of what you submit. Two things follow directly from the intended-use list. First, your app should read as serving creators publishing their own original work, because that is the stated purpose in the document. Second, if what you are building is genuinely an internal utility for accounts your team manages, the intended-use list has already told you the answer, and burning a review cycle to hear it again is an expensive way to confirm it. Photo posting has its own configuration and its own considerations, which we covered in TikTok Now Lets Apps Post Photos Through the API.

Frequently Asked Questions

Why do my API-posted videos get zero views?

Because an unaudited client can only post in SELF_ONLY viewership - private viewing mode. The post succeeded and the video exists in the account, but it is not visible to anyone else. This is documented behaviour rather than a bug, and the only fix is passing the audit. Check your client's audit status before you spend a day reading logs.

How many users can post through an unaudited client?

TikTok states that unaudited API clients can allow up to 5 users to post in a 24 hour window. That is a ceiling on distinct posting users, not on posts, and it is the reason a small pilot behaves perfectly while a real rollout stalls. Design your pilot to prove the flow, not the scale, until the audit clears.

Can I use the Content Posting API for my own accounts?

The intended-use documentation marks a utility tool for uploading content to accounts you or your team manages as not an acceptable use, and marks an app that copies arbitrary content from other platforms the same way. The stated purpose is helping authentic creators post original content. If your use case is the first one, read that list carefully before you build against this API.