TikTok Posting API: Direct Post, Inbox Upload and a Safer Workflow

The TikTok posting API is TikTok's official Content Posting API. It gives approved apps two distinct ways to send content to an authorized creator account: Direct Post can publish a finished post, while inbox upload sends media for the creator to finish inside TikTok. Both flows are asynchronous. Neither an upload nor an accepted initialization request proves that a public post exists.

This guide was checked against TikTok for Developers documentation on September 25, 2026. It separates TikTok's native rules from Postdom's application contract so you can choose the right path without treating a wrapper, an audit, or a submitted request as evidence of publication.

TikTok posting API: Direct Post or inbox upload?

TikTok uses one Content Posting API name for two workflows that should not be collapsed into the same promise. Direct Post uses the video.publish scope and sends a finished post toward the creator's profile. Upload uses video.upload and sends media to the creator's TikTok inbox, where they must open the notification, edit if needed and complete the post themselves.

TikTok's Direct Post reference and upload guide are the controlling sources. If your product says “published” after the init call, it is describing intent as an outcome.

The fast decision

• Choose Direct Post when the creator can review the finished media, caption, disclosures, privacy and interaction choices in your product before submission.
• Choose inbox upload when the creator needs TikTok-native editing, effects, sounds or a final manual step.
• Choose neither if your use case is an internal uploader for accounts only you or your team manage. TikTok's content-sharing guidelines explicitly say Direct Post clients should serve authentic creators and a wide audience, not a private internal utility.

What you need before calling TikTok's Content Posting API

A developer account is not a universal API key. For Direct Post, you need a registered TikTok app, the Content Posting API product, approval for video.publish, authorization from the target TikTok user for that scope, and a valid user access token. Scope approval and user authorization are separate: TikTok's scope overview says each user can grant, deny or later revoke individual scopes.

For inbox upload, request video.upload instead. The target user must authorize that scope, and your product must explain that the media is waiting in TikTok rather than already posted.

If TikTok will pull media from your URL, use a verified domain or URL prefix. If you choose file upload, TikTok returns a temporary upload URL and expects the declared bytes to be transferred there. Do not invent a public media URL for a local file or reuse an expired upload URL.

Public posting needs more than the scope

TikTok says content from unaudited Direct Post clients is restricted to private viewing. Its content-sharing guidelines currently add two explicit unaudited-client restrictions:

• up to five users may post in a 24-hour window;
• those accounts must be private at the time of posting, and content must use SELF_ONLY visibility.

TikTok also documents a client-specific active-creator cap and a creator-level daily posting cap that may vary. The documentation says the latter is typically around 15 posts per creator per day and is shared across Direct Post clients. “Typically” is not a guaranteed fixed quota, so read the current creator and API response instead of encoding 15 as universal capacity.

TikTok does not promise an audit turnaround in the cited documentation. Do not plan a launch around a competitor article's estimate or describe audit approval as guaranteed.

Inbox upload has a separate operational cap: TikTok's current upload reference says a creator may have no more than five pending shares in a 24-hour period. That is not the same as the unaudited Direct Post five-user cap or the variable creator posting cap. Treat each limit as a different control and report which one blocked a request.

The Direct Post sequence developers should actually implement

1. Query the latest creator information

Call POST /v2/post/publish/creator_info/query/ with the authorized user's token. TikTok's creator-info reference returns the creator identity, current privacy options, disabled interaction settings and max_video_post_duration_sec.

Use that response on the export screen. Display the creator's nickname so the person knows which account will receive the post. Offer only the returned privacy options, respect disabled comments, Duet and Stitch controls, and reject video that exceeds that creator's current duration privilege.

Do not preselect a privacy level. TikTok's guidelines require a deliberate user choice. A stored “consent=true” field cannot prove that the person saw the current media, caption and settings.

2. Show the exact post and collect the required decisions

The creator should see the media, caption, account identity, privacy level and available interaction choices before submission. Handle branded-content and AI-generated-content declarations truthfully. A generic approval of a campaign or plan is not the same thing as consent to send this exact version of a post.

TikTok's current Direct Post body includes required branded-content toggles and an optional is_aigc field. Those declarations answer different questions. An AI label is not a paid-partnership disclosure.

The posting screen also needs TikTok's Music Usage Confirmation declaration immediately before the publish control. If the creator selects branded content, show the required version that incorporates TikTok's Branded Content Policy. Keep commercial-content disclosure off by default, leave any preset caption or other editable text editable, and do not transfer media until the creator has reviewed the exact post and given express consent.

3. Initialize the post once

For video Direct Post, a minimal URL-pull request looks like this. Replace every placeholder, and use only a privacy_level value returned for the current creator:

POST https://open.tiktokapis.com/v2/post/publish/video/init/
Authorization: Bearer <user access token>
Content-Type: application/json; charset=UTF-8

{
  "post_info": {
    "title": "<editable creator-reviewed caption>",
    "privacy_level": "<value returned by creator_info>",
    "disable_comment": true,
    "disable_duet": true,
    "disable_stitch": true,
    "brand_content_toggle": false,
    "brand_organic_toggle": false
  },
  "source_info": {
    "source": "PULL_FROM_URL",
    "video_url": "https://<verified-domain>/<video>.mp4"
  }
}

This safe example keeps comments, Duet and Stitch disabled. Change a disable_* field to false only when the latest creator-info response permits that interaction and the creator deliberately enables it on the posting screen.

The endpoint uses video.publish. TikTok currently documents a limit of six requests per minute for each user access token on this initialization endpoint. That is an endpoint-specific rate limit—not a universal allowance for the entire TikTok API.

Choose PULL_FROM_URL for media hosted on a verified URL, or FILE_UPLOAD when your application will transfer the bytes to the returned upload URL. The successful initialization response includes a publish_id; file upload also returns an upload_url that TikTok says is valid for one hour.

For FILE_UPLOAD, replace source_info with the exact byte and chunk values for the asset you will send:

{
  "source": "FILE_UPLOAD",
  "video_size": 50000000,
  "chunk_size": 10000000,
  "total_chunk_count": 5
}

Those integers are one coherent illustration, not defaults. Recalculate all three from the real asset and chunk plan; do not send the values as strings.

A successful initialization response gives you an identifier, not a published-post receipt:

{
  "data": {
    "publish_id": "<save this value>",
    "upload_url": "<present for FILE_UPLOAD>"
  },
  "error": {
    "code": "ok",
    "message": "",
    "log_id": "<support reference>"
  }
}

4. Keep the publish_id and follow the original attempt

Use POST /v2/post/publish/status/fetch/ with the same publish_id, or consume TikTok's content-posting webhooks. TikTok's status reference distinguishes upload/download processing, inbox delivery, PUBLISH_COMPLETE and FAILED.

POST https://open.tiktokapis.com/v2/post/publish/status/fetch/
Authorization: Bearer <the same user's access token>
Content-Type: application/json; charset=UTF-8

{ "publish_id": "<saved publish_id>" }

TikTok currently documents 30 status-fetch requests per minute for each user access token. Status processing has no guaranteed completion time. Public content may also wait for moderation before a public post ID is returned. Poll with backoff inside that endpoint-specific limit, stop after a bounded window, and hand the unresolved publish_id to an operator rather than starting a duplicate request because the first response was slow.

When TikTok reports a failure, separate retryable infrastructure problems from terminal account, authorization, policy or media problems. Reconcile the original attempt before sending the same content again.

Photos use a different request shape

TikTok's current Content Posting API supports photo posts, but you should not turn that into “the video endpoint accepts carousels.” The photo reference uses POST /v2/post/publish/content/init/ and requires post_mode and media_type.

Photo and video restrictions change independently. Link to TikTok's current media documentation and validate the actual asset; do not copy a file-size, aspect-ratio or duration number from a provider article and present it as a permanent platform rule.

Direct TikTok integration or a managed posting API?

Build directly when TikTok-native controls are central to your product and you can own the developer application, audit, user authorization, latest-creator-info screen, media transfer, consent, status reconciliation and ongoing policy maintenance.

Use a managed layer when its narrower contract fits your workflow and you want one application-facing interface for connection, scheduling, approvals and destination results. The managed provider still has to state its own supported media, settings, account types and evidence. It does not erase TikTok's user consent, policy or provider processing.

Postdom is the managed path for teams building approval-aware publishing into a backend or AI agent. The TikTok automation workflow shows the current product boundary, while the TikTok API explainer covers TikTok's broader developer catalogue. If you only need a human-facing calendar, use the TikTok scheduling guide.

What Postdom's released MCP helper currently does

The public `@postdom/mcp@0.4.0` package exposes a publish_video workflow. It resolves a connected account by the returned providerAccountId, accepts an existing media URL or stored media handle, sends one tracked Postdom request, and lets the caller follow the same Postdom post ID with get_publish.

For TikTok, that released helper currently fixes these settings:

• privacy_level: SELF_ONLY;
• comments, Duet and Stitch disabled;
• AI-made disclosure set to true;
• content-preview and express-consent assertions set to true.

Those true fields are assertions, not evidence that a human actually previewed or consented. The helper does not expose per-call overrides for those TikTok settings or commercial-content controls. Stop if the media is not AI-made, if public visibility is required, if interactions should be enabled, or if branded-content controls are needed.

The public Postdom MCP evidence page discloses that the released-package test uses a fake key and loopback responses. It verifies the released request contract and same-ID receipt handling; it does not prove a live TikTok authorization, audit, upload or publication. A Postdom status should never be translated into a native TikTok state unless the product has actual provider evidence for that mapping.

1. list_accounts()
   Copy the TikTok account's providerAccountId.

2. publish_video({
     account_ids: ["<providerAccountId returned by list_accounts>"],
     video_url: "https://your-verified-host.example/video.mp4",
     caption: "Reviewed caption",
     intent: "Publish the approved TikTok video",
     publish_at: "<agreed UTC instant>",
     idempotency_key: "<stable key for this unchanged request>"
   })
   Save the returned Postdom post id.

3. get_publish({
     post_id: "<Postdom post id returned by publish_video>"
   })

The video URL above is illustrative, not a real asset. A later publish_at value does not change SELF_ONLY into public visibility.

Not ready to create a workspace? Inspect the released MCP tools, setup and evidence boundary first.

A preflight checklist that prevents the most expensive mistakes

• Confirm whether the job is Direct Post or inbox upload.
• Use the correct approved scope and the current user's authorization.
• Query creator info when rendering the export screen.
• Show the creator identity, exact media, caption and available settings.
• Require a deliberate privacy choice and truthful disclosures.
• Validate duration against the current creator response.
• Verify the media URL prefix or upload the exact declared bytes.
• Persist the native publish_id or managed-provider post ID.
• Reconcile the original attempt before retrying.
• Report publication and public visibility only from evidence that establishes those outcomes.