unaudited_client_can_only_post_to_private_accounts: what it means and how to publish publicly today
What TikTok's unaudited_client_can_only_post_to_private_accounts error means, why your customer's posts are landing as private, and how to fix it before your app passes audit.
By André LugThis error means your TikTok app has not passed audit. Per TikTok's Content Sharing Guidelines, unaudited API clients can only post content in SELF_ONLY viewership, and the restriction is enforced server-side per client key. There is no client-side workaround — offer self-only posting honestly until your app completes TikTok's audit for the scopes you need, most commonly video.publish.
You call TikTok's Content Posting API with a valid access token, a valid video, and aprivacy_level of PUBLIC_TO_EVERYONE, and the request comes back rejected with a message that says your client can only post to private accounts. Nothing about your token or your video is wrong. This is TikTok telling you, directly, that your app has not passed audit yet — and that until it does, every post it creates is restricted to the author only.
PostGate handles OAuth, publishing and delivery evidence for every network through one API. Start free or read the docs.
What does the error actually mean?
Every TikTok developer app starts in an unaudited state. Per TikTok's own Content Sharing Guidelines: "Unaudited API Clients can only post contents in SELF_ONLY viewership." TikTok lets you build and test the full Content Posting API flow, but it will not let unaudited apps publish content that is visible to anyone other than the account owner. The platform enforces this server-side: it does not matter what your request body says, what your UI shows the user, or what your own documentation promises a customer. If your client key has not completed audit, TikTok silently downgrades — or in stricter cases outright rejects — any attempt to set a public-facing privacy_level.
This is not a bug in your integration and it is not something you can code your way around. It is a platform-level gate that exists specifically so that apps cannot reach real audiences before TikTok has reviewed how they collect consent, present the post, and handle the creator's content.
Where will you actually see it?
The most common trigger is a request to /v2/post/publish/video/init/ (or the photo equivalent) with privacy_level set to anything other than the self-only option — for example PUBLIC_TO_EVERYONE, MUTUAL_FOLLOW_FRIENDS, or FOLLOWER_OF_CREATOR. On an unaudited client, TikTok returns an error (or, depending on the exact endpoint and API version you are on, silently forces the post into a private/self-visible state) rather than letting the publish continue as requested.
It also shows up around the creator_info/query endpoint, which TikTok's own integration guide requires you to call before showing a publish UI — that response includes privacy_level_options, the set of privacy levels the creator can choose from. Do not assume an unaudited app will only see the self-only option there: several developers have reported that privacy_level_options keeps listing PUBLIC_TO_EVERYONE even for unaudited clients, so the endpoint can look like it is offering public posting when the platform will still force the result to SELF_ONLY at publish time regardless of what you send. Treat the SELF_ONLY-only rule from the Content Sharing Guidelines as the operative constraint for an unaudited app, not the options list this endpoint happens to return.
What can you do about it today?
In the short term, there is no client-side workaround, and you should stop looking for one. The correct short-term behavior is to make your integration respect what creator_info/query tells you:
- Query the creator's available privacy options before showing a publish UI, and only offer the options TikTok actually allows for that app/creator pair.
- If the only available option is self-only, say so plainly in your product — "this will post as private while our TikTok integration is in review" is an honest, useful message. Silently downgrading visibility without telling the customer is how support tickets happen.
- Do not retry the same request with a different privacy level hoping for a different result. The gate is applied per client key, not per request, and retries will not change the outcome.
The real fix: pass audit
The only durable fix is completing TikTok's app audit for the scopes you need, most commonly video.publish. Audit review checks that your app's consent flow, permission scopes, and published UI match what you actually do with the data and the content — TikTok reviewers will use your app the way a real user would, so the sandbox flow you submit needs to look like production, not a stub. Until that review completes, treat public posting as unavailable, not delayed.
Budget for review time when you plan a launch. Audit is not instant, and a resubmission after a rejection restarts a chunk of that clock, so get the consent screens, scope requests, and privacy-level handling right on the first submission rather than shipping a placeholder and hoping it slides through.
How does PostGate surface this?
Because TikTok enforces this restriction server-side, any integration — including PostGate — receives the same platform-level signal. PostGate's per-target delivery status and structured error envelope distinguish this case from a generic failure: a target that lands as private due to an unaudited client looks different in your logs than one that failed outright, so your product can message the customer accurately instead of reporting a false success or a confusing rejection.
Frequently asked questions
Can I bypass TikTok's unaudited client restriction?
No. The gate is enforced server-side, per client key — it does not matter what your request body says, what your UI shows, or what your documentation promises. Retrying the same request with a different privacy level will not change the outcome. The only durable fix is completing TikTok’s app audit for the scopes you need.
Why does creator_info/query still list PUBLIC_TO_EVERYONE for my unaudited app?
Several developers have reported that privacy_level_options keeps listing PUBLIC_TO_EVERYONE even for unaudited clients, so the endpoint can look like it is offering public posting when TikTok will still force the result to SELF_ONLY at publish time. Treat the SELF_ONLY-only rule from the Content Sharing Guidelines as the operative constraint for an unaudited app, not the options list this endpoint returns.
How do I get my TikTok app approved for public posting?
Complete TikTok’s app audit for the scopes you need, most commonly video.publish. Reviewers use your app the way a real user would and check that your consent flow, permission scopes, and published UI match what you actually do with the data and content — so the flow you submit needs to look like production, not a stub. Budget for review time: a resubmission after a rejection restarts a chunk of that clock.
What should my product show users while the TikTok app is unaudited?
Query the creator’s available privacy options via creator_info/query before showing a publish UI, and only offer the options TikTok actually allows for that app/creator pair. If the only available option is self-only, say so plainly — "this will post as private while our TikTok integration is in review" is an honest, useful message. Silently downgrading visibility without telling the customer is how support tickets happen.
