TikTok API for Business: Access, Review, and What It Allows

The access path

Publishing on behalf of a creator goes through the TikTok for Developers portal and its Content Posting API. The flow has three parts: register an app in the portal, have creators authorise it through the official login so the app holds a token for each account, and call the posting endpoint to upload video or photos. The app is tied to a TikTok developer account, and TikTok reviews it before granting the wider permissions that public publishing needs. For a product, the important consequence is that onboarding a customer account is a TikTok login step rather than something you can do on the customer's behalf. Plan for that in the connection flow, because it is a user-facing step with its own errors.

• Register the app in the TikTok for Developers portal.
• Each creator authorises the app through TikTok login.
• The app holds a token per authorised account.
• Publishing calls act on behalf of the authorised creator.

What an unaudited app can do

Until TikTok reviews an app, it can publish only to private visibility. Posts go out with a privacy level of "Only Me", which means the request succeeds and the content is invisible to everyone else. This is the single most confusing part of the integration for teams testing it: the API returns success, the post exists, and nobody can see it. Nothing about the code is wrong, and no retry changes the outcome. The fix is a review, not a patch, so the practical step is to confirm the app's audit state before treating an invisible post as a bug. For development, "Only Me" is also useful, because it lets a full publish flow be tested end to end without putting unfinished work in front of an audience.

• An unaudited app can publish only with privacy set to "Only Me".
• The publish call still succeeds, which makes the limit easy to miss.
• Public visibility requires the app to pass TikTok review.
• Use the private level deliberately to test a publish flow safely.

Privacy options come from the account, not the code

The privacy level a post can use is not a free choice in the request. TikTok decides which options an account may offer, and the API returns that list per creator, so a correct integration reads the available options before it publishes and uses one of them. When that list comes back empty, the account cannot publish through the API at that moment, and the only correct response is to surface that state to the user rather than retry. Building the read step into the flow, before the publish call, turns a confusing rejection into a clear message about the account.

GET /accounts/{accountId}/privacy-levels

{
  "privacyLevelOptions": [],
  "commentDisabled": true,
  "duetDisabled": true,
  "stitchDisabled": true
}

Limits that apply on top of access

Four constraints sit on top of the app review and are worth checking before a batch runs. The account has a daily publishing ceiling, so a high-volume calendar needs to spread posts rather than fire them at once. The app review state governs whether public visibility is available at all, as described above. The privacy options an account may use are decided by TikTok and returned by the API, so a correct integration reads them before it publishes. And video has to meet the platform format rules, which is where a technically valid upload still gets refused. None of the four is fixed by improving the request, so an integration that reports them as distinct states lets a team tell "try again later" apart from "fix the media" apart from "the app needs review" apart from "this account cannot publish right now".

Getting the media right first

TikTok is strict about video, and most failed uploads are a media problem rather than a permissions problem. A vertical MP4 or MOV with H.264 encoding and a duration between 3 seconds and 10 minutes covers the common cases, and keeping those checks before the upload saves a retry cycle. Photo posts are the other supported type, and they are a separate payload from video rather than a mixed one. Validating the container, the codec, the orientation, and the duration before the request is what separates an integration that publishes reliably from one that fails intermittently and blames the platform.

Business accounts and the wider platform

The Content Posting API is one part of the TikTok developer surface, and the business side of the platform reaches further: advertising, catalogues, and commerce features live in their own products with their own access rules. For a publishing integration, the Content Posting API is the relevant piece, and the rest matters mainly as context for why access is gated. TikTok has an interest in knowing who publishes on behalf of creators, which is what the review process establishes. Reading the access path as a deliberate gate rather than an obstacle is the right mental model, and it means an integration should treat review state as a first-class value it displays rather than a one-time setup detail.

Using a managed path instead

Managing the review, the per-account tokens, the privacy reads, and the daily ceiling is real work, and it is work every product publishing to TikTok repeats. A managed publishing API takes that on and exposes one request shape across platforms, so the TikTok specifics live behind the interface instead of in your code. That does not remove TikTok's rules: the privacy options, the media format, and the daily ceiling still apply, because they come from TikTok and not from the layer in front of it. What it removes is the maintenance of the access path itself. For a team whose product is not social publishing, that trade is usually the right one, and for a team that wants full control of the TikTok relationship, the direct path is the right one.