You build a TikTok posting integration. The API accepts your request, returns a success response, and the post appears on the account. Everything looks correct.
Then you check the account from another device and the post is not there. It is visible only to the account owner.
Nothing is broken. This is TikTok working as designed, and there is a specific reason it happens.
What TikTok’s documentation actually says
On the Content Posting API, TikTok states plainly that content posted by unaudited clients is restricted to private viewing mode.
That is not an error condition, a rate limit or a configuration mistake. Until your application passes an audit, every post it publishes is forced to self-only visibility, regardless of the privacy level you request.
Unaudited applications face two further restrictions worth knowing: a cap of five users posting within any twenty-four hour period, and a requirement that the accounts posting through the API are set to private.
So the integration can be complete, correct and functional, and still produce nothing the public can see.
The part that catches people out: there are two reviews
This is the detail that turns a surprise into a project delay.
Getting the Content Posting API added to your application is one process. Getting your posts publicly visible is a second, separate audit.
Passing the first does not give you the second. Many teams complete the initial approval, assume they are cleared, build the whole integration, and discover the visibility restriction only when they test with a real account.
The second audit assesses whether your integration complies with TikTok’s content sharing guidelines — specific consent screens, clear disclosure that content will be posted to TikTok, and a privacy setting the user chooses manually with no default.
Why automated systems struggle with that audit
Those guidelines were written with a particular kind of application in mind: one where a human user is present, sees a screen, and consciously approves each post.
If you are building a scheduled publishing system or an automated content pipeline, there is often no user-facing screen at the moment of posting. There is nothing to show a consent dialogue to. That is precisely the shape of integration that tends to be rejected, and there are publicly documented cases of exactly this.
This is worth understanding before you plan a timeline. It is not a matter of resubmitting with better paperwork. If the architecture has no user interface at posting time, it may not fit the model the guidelines assume.
The second API most people miss
Here is the part that resolves the problem for a large share of real projects.
TikTok operates two entirely separate developer platforms. Different portals, different access processes, different rules.
The one most developers find first is the Content Posting API on the developer platform. It is built for applications posting on behalf of third-party creators — a scheduling tool serving many customers’ accounts. The consent and disclosure requirements exist because those creators need to understand what an app is doing with their account.
The second is the Business API, on TikTok’s business developer platform. It includes endpoints for publishing public video and photo posts to an owned account — an account belonging to the business operating the integration.
That distinction matters enormously. If a company is posting to its own TikTok account, the entire consent-and-disclosure problem the audit exists to solve does not apply. There is no third-party creator to protect. The account owner is the one running the system.
On the Business API, the photo endpoint accepts a public privacy level directly, and the video endpoint publishes publicly by definition. Public posting is supported for owned accounts.
What the Business API route requires
It is not approval-free — it is a different approval, and generally a more achievable one for this use case.
You will need a TikTok for Business account, developer registration with a company email and website, an approved developer app, and since March 2026 a completed Accounts API access application. That is ordinary integration onboarding rather than a content-guidelines audit assessing whether your interface shows the right consent screens.
Two practical requirements catch people out:
Media URLs must be verified. You cannot publish photo or video posts using unverified URLs. Media must be hosted on a domain whose ownership you have verified with TikTok. In practice this means writing generated or uploaded images to your own domain or storage bucket, verifying that domain once, and referencing images from there. It is a small task, but it must be in the build plan rather than discovered mid-integration.
There are rate limits. Photo and video posting are each capped at six posts per minute with an upper limit of fifteen per day per account. Comfortable for daily publishing, restrictive for bulk migration.
Images also have format constraints: JPG, JPEG or WebP only, 20 MB per image, and a maximum of 1080 by 1920 pixels in portrait or landscape. Check the current values against the documentation when you build.
How to choose between them
The question is simple: whose account are you posting to?
If you are posting to accounts belonging to your customers — a scheduling product, an agency tool serving many clients — the Content Posting API is the correct route, and you must plan for the content sharing audit and design your interface around its consent requirements. Budget real time for it.
If you are posting to an account the business owns — a company publishing its own content, a brand automating its own feed — the Business API is the better fit. Public posting is supported, the audit that blocks automated flows does not apply, and the onboarding is conventional.
Most businesses automating their own social presence fall into the second category and never need the first.
Before you build
A short checklist that prevents the common failures:
- Decide which API applies based on account ownership, before any code is written.
- If using the Content Posting API, confirm you can satisfy the content sharing guidelines with a user-facing consent step. If your system has no interface at posting time, reconsider the approach.
- If using the Business API, start developer registration and the Accounts API access application early. Each review takes days.
- Plan where generated images will be hosted, and verify that domain with TikTok as part of the build.
- Test with a real account and check visibility from a different account, not the one that posted. This is the check that would have caught the problem at the start.
Takeaways
- Unaudited applications on the Content Posting API publish privately by design. The API reports success while the post stays invisible.
- Getting the API added and getting public visibility are two separate reviews. Passing the first does not grant the second.
- The second audit assumes a user-facing consent screen, which automated pipelines often cannot provide.
- TikTok runs two separate developer platforms. The Business API supports public posting to owned accounts.
- Choose based on account ownership: customers’ accounts point to the Content Posting API, your own account points to the Business API.
- Posting on the Business API requires photos and videos hosted on a domain you have verified with TikTok.
- Always verify visibility from a second account. Checking from the posting account shows you nothing.
All of the above is stated in TikTok’s own documentation across both platforms. The difficulty is that the two platforms are documented separately, so a developer who finds one rarely discovers the other.
This article is general information, not legal or professional advice. Vendor terms and platform rules change, so confirm the current position with the vendor before you act on it. Last reviewed September 2026.