If you are trying to post to TikTok from n8n, Make, or your own code, you will hit this wall in roughly this order:
- The credential connects fine.
- The upload call fails.
- You start TikTok's App Review.
- App Review asks for a demo video of the working integration you cannot build yet.
That last one is the part that feels impossible. It isn't, but the way out is not obvious and the error messages actively point the wrong way. Here is what actually happens, from having gone through the audit and shipped against this API.
Sandbox first — you do not need App Review to get a token
You can get a real, working access token today. Add your own TikTok account as a target user in your app's sandbox, and the OAuth flow completes normally.
That is also the answer to the chicken-and-egg problem: you record the demo video in sandbox. Reviewers expect that. You are not required to have a live public integration before review — you are required to show the flow working, including the consent screen, which sandbox does.
If you are seeing Unable to sign without access token, that is not an App Review problem at all. It means no user access token is stored: either the authorization code flow never finished, or the token is not being attached to the request. Starting App Review will not fix it, and it costs you days.
The restriction nobody documents clearly
Here is the one that catches everybody, because the error names the symptom instead of the cause.
An unaudited app can only post as private. TikTok's enum for that is SELF_ONLY. If you send anything else — PUBLIC_TO_EVERYONE, or a friendly-looking "public" — the call fails with:
unaudited_client_can_only_post_to_private_accounts
Which reads like something is wrong with the account. Nothing is wrong with the account. The app has not passed audit yet.
And it is per creator, not just per app. Even after your app is audited, an individual creator's allowed levels depend on their own settings — a private account will not accept PUBLIC_TO_EVERYONE no matter what your app is allowed to do. So you cannot hardcode a privacy level and hope.
The API tells you, if you ask first:
POST /v2/post/publish/creator_info/query/
→ { "data": { "privacy_level_options": ["PUBLIC_TO_EVERYONE", "MUTUAL_FOLLOW_FRIENDS", "SELF_ONLY"], ... } }
Call that before every publish, and pick a level from what comes back. That single call turns a confusing rejection into a decision you can make.
One more, related: branded content cannot be posted as SELF_ONLY. If you set branded_content_toggle, you must also choose a non-private level. Two rules that individually make sense and together produce a contradiction you can only hit at runtime.
The chunk rules will bite you at specific file sizes
For FILE_UPLOAD, TikTok wants chunks between 5MB and 64MB, and the final chunk may exceed chunk_size (up to 128MB). Maximum total: 4GB.
The trap is arithmetic. If you compute total_chunk_count = ceil(size / chunk_size), you will eventually produce a final chunk under 5MB, and TikTok rejects it. It only happens at certain file sizes, which is a miserable way to find a bug.
Use floor, and let the last chunk absorb the remainder:
const chunk = 32 * 1024 * 1024; // inside 5–64MB
const total = size <= 64 * 1024 * 1024 ? 1 : Math.floor(size / chunk);
// last chunk = size - (total - 1) * chunk, which lands between 32MB and 64MB
I verified this against every size from 3MB to 1GB with a plain loop asserting each chunk against the documented bounds. Thirty seconds of test code for a bug that would otherwise look random.
What the demo video needs to show
Reviewers are strict about one thing in particular: the use case "auto-posting to my own account" gets scrutinised, because it is what spam looks like from the outside. Show the consent flow, show the user choosing what goes out, show the post appearing. Do not show a script publishing unattended — that is the shape they reject.
If you would rather not do any of this
A pre-audited service posts through its own approved app, so you skip review entirely. There are several — Blotato, Upload-Post, and PostWire, which is mine. I mention it because the alternative is the four-step wall at the top of this post, and it is fair to know that skipping it is an option.
What I would keep from this either way: call creator_info before you publish. Whether you go direct or through a service, the allowed privacy levels are a property of the creator at that moment, and asking is the only reliable way to know.
Top comments (1)
Hello Perufitlife, I am Kane Lim from Hong Kong. I have over 10 years of development experience. I am writing this because your post was interesting.
Your explanation of the TikTok API review trap is extremely practical. The creator_info query is particularly important because it turns publishing from a hardcoded operation into capability negotiation.
I would take this architecture one step further by introducing a publish policy layer in n8n. Before every upload, resolve creator capabilities, privacy options, account state, content classification, and branded content constraints into a validated publish command. The workflow should reject invalid combinations before reaching TikTok rather than depending on runtime API errors.
For chunked uploads, I would also make the uploader resumable. Persist upload session state, byte ranges, checksums, retry counters, and idempotency metadata in Redis or PostgreSQL. With exponential backoff and deterministic chunk boundaries, transient network failures do not require restarting a multi gigabyte upload.
For production automation, I would separate OAuth token lifecycle management from publishing entirely. Encrypt refresh tokens, rotate credentials safely, monitor expiration, and implement a dead letter queue for failed publications. Observability should expose correlation IDs across OAuth, creator_info, upload, publish, and verification stages.
This effectively converts TikTok integration from a fragile API workflow into a capability driven state machine with validation, recovery, and auditability. That pattern is useful far beyond TikTok and could become a reusable social publishing abstraction.
I would like to get to know you better and discuss about your post. Would you please contact me? t_g_@kanelim1997