Postiz and TikTok: what the open GitHub issues actually say

Using GitHub's search API against the public gitroomhq/postiz-app repository, we ran a title-only search for issues (not pull requests) containing the word "tiktok". As of this writing, that search returns:

• 5 open issues with "TikTok" in the title.
• 20 closed issues with "TikTok" in the title — meaning at least 25 distinct TikTok-titled issues have been filed against the project over its history.

A broader, full-text search for the word "tiktok" anywhere in an issue's title, body, or comments — not just the title — returns a larger number, but a good chunk of those hits are issues about other platforms (Instagram, Facebook, LinkedIn) that simply mention TikTok in passing, for comparison or context. We don't think that broader number represents "issues about TikTok not working," so we're not reporting it. The title-scoped numbers above are the ones we can stand behind, and you can rerun the same search yourself at github.com/gitroomhq/postiz-app/issues?q=is:issue tiktok in:title.

Three of the five open, TikTok-titled issues describe real publish-time or connect-time failures, not feature requests:

• Issue #1773 — a TikTok connection fails with a NotEnoughScopes (409) error at the final step, even though the reporter shows TikTok's own redirect callback granting all six requested scopes. The generic error message may be masking a different underlying cause elsewhere in the connection flow.
• Issue #1854 — on Postiz's own managed cloud, TikTok Direct Post fails at publication time with "Daily active user quota reached, please try again later." Postiz accepts and schedules the post, then the job errors out at send time. Because this is an app-level quota tied to Postiz Cloud's own TikTok developer application, no individual customer can fix it from their side.
• Issue #1563 — self-hosters applying for TikTok's Direct Post API audit are getting rejected because Postiz's UI doesn't follow several requirements from TikTok's own Content Sharing Guidelines, most notably that privacy status must have no default value. The reporter says this "blocks Postiz users from getting Direct Post approval indefinitely," forcing a fallback to upload-only posting, which only sends the video to the user's TikTok inbox rather than posting it directly. The issue has six comments as of this writing.

The other two open, TikTok-titled issues (#1314 and #1362) are labeled as feature requests describing the same underlying audit-compliance gap from a different angle, rather than separate bugs.

Twenty closed, TikTok-titled issues is not, by itself, evidence of a badly maintained project — closed means fixed, and Postiz's maintainers have shipped real fixes for TikTok-specific bugs repeatedly: a duplicate-publish bug from a retried in-flight job, a privacy_level field silently dropped in upload mode that left posts stuck in QUEUE forever, a cover-frame timestamp placed in the wrong part of the request body, and more. What it does show is a pattern: TikTok's publishing API changes shape and requirements often enough, and is strict enough about exact request structure, that it keeps generating new platform-specific bugs even in an actively maintained project with frequent releases.

This isn't unique to Postiz. TikTok's Content Posting API imposes two constraints that most other platforms don't combine: a strict, audited UX-compliance process for Direct Post (TikTok reviews your app's actual interface, not just your API calls, against its Content Sharing Guidelines), and a hard active-user cap on unaudited apps — TikTok's own docs state that "Unaudited API Clients can allow up to 5 users to post in a 24 hour window." Any tool that hasn't completed TikTok's audit is operating under both constraints simultaneously, and a self-hosted deployment adds a third: every self-hoster who wants Direct Post has to pass that same UI-compliance audit independently, on their own TikTok developer app, rather than inheriting an approval one vendor already earned.

Being open source doesn't make a tool more or less likely to hit a TikTok-side change — it changes who has to act, and how fast. When a managed vendor's TikTok integration breaks, the vendor ships a fix and every customer gets it automatically on the next deploy. When a self-hosted tool's TikTok integration breaks, a fix has to land upstream, a self-hoster has to notice it, pull the new image, and redeploy — and if the fix requires a fresh TikTok app audit (as issue #1563 describes), that self-hoster is on the hook for their own audit submission, not just a software update. That's a real cost of self-hosting worth going in with eyes open, not a reason to avoid open-source tools outright — plenty of teams have the operational appetite for exactly that tradeoff.

As a managed API, a PostGate integration doesn't depend on you passing TikTok's own Direct Post UX audit against your own interface — TikTok audits PostGate's own connection and posting flow once, centrally. When TikTok does return an app-level restriction like an active-user cap, PostGate's structured error envelope carries the real platform code and message through instead of collapsing it into a generic failure, so you know whether a failure is something to retry, something to fix in your request, or a platform-side limit outside your control. See the errors guide and what the active-user cap actually is for the mechanics.