Postiz App Review Guide: Publishing Permissions, Cron & Rejection Patterns

A Postiz app review is Meta Advanced Access for the Facebook app behind your Postiz install — the open-source / self-hosted (and SaaS) multi-platform social scheduler — not Postiz’s own license screen, and not X / LinkedIn / TikTok developer setup. Postiz schedules Page posts, Instagram publish, Threads, calendars, and queues across networks. Meta only cares about the Meta scopes you request and whether a cold reviewer can recreate publish proof. This guide diagnoses why Postiz App Review fails: publishing-scope honesty, OAuth redirects, cron/queue fire gaps that look like “API broken,” and cooldown risk. Diagnosis only — not a DIY secret-sauce checklist.

What Postiz typically needs from Meta

Exact scopes depend on which Meta channels you enable in Postiz (self-hosted Docker, VPS, or hosted SaaS). Field packages commonly include:

• pages_manage_posts — create/manage Facebook Page posts from the scheduler (often with pages_show_list / pages_read_engagement helpers when your connect or insights path actually uses them)
• instagram_content_publish — Instagram content publishing API for feed/Reels/Stories paths your build actually uses
• threads_content_publish (with threads_basic) — when the Threads channel is live in your Postiz instance
• business_management — only when multi-asset / Business Manager patterns are truly required for your white-label or team flow

Do not paste every social network’s API names into Meta App Review notes. X, LinkedIn, TikTok, YouTube, and Bluesky use their own developer consoles — they are not fixed by a Meta Postiz app review resubmit. Deep Meta Threads diagnosis: threads_content_publish. Sister scheduler guide: Stackposts app review. Inbox/messaging script guides (different failure mode): ChatPion, BotSailor, Chatwoot.

OAuth, cron, and why Postiz app review “scheduled” fails

Postiz relies on OAuth redirects plus a worker/cron (or queue) that fires scheduled posts. Meta reviewers are not debugging your Docker Compose or Redis queue — but a broken scheduler still kills recreateability:

• OAuth redirect mismatch — redirect URIs in the Meta app do not match the Postiz public URL (www vs bare, http vs https, reverse-proxy path, self-hosted folder).
• Cron / queue not firing as expected — posts stuck “scheduled” forever; screencast shows the calendar UI, live test never publishes.
• Token expiry between schedule and fire — owner’s long-lived token works; reviewer credentials expire before the queued post runs.
• Media / worker failures — Instagram or video paths error while the UI still says “queued.”
• Self-hosted vs SaaS App ID confusion — screencast uses one Postiz Meta app; reviewer opens a tenant or staging URL with different OAuth settings.

For a Postiz app review, fix publish reachability (OAuth callbacks + cron/queue fire) before rewriting permission essays. Messaging-style webhook diagnosis belongs to Chatwoot, ChatPion, and BotSailor; here the failure mode is usually schedule → publish, not inbox events.

Why Postiz app review gets rejected

• Product tour without publish proof — calendar, AI captions, and every network shown; no recording of a Page or Instagram publish path for the requested scopes.
• Scope inflation — messaging, ads, or unused Threads scopes requested “because Postiz can,” while the live demo only schedules a Page photo.
• Admin-only success — owner Pages work; Test User / reviewer never gets a Page or IG professional account Postiz can publish to.
• Use-case vs policy stretch — notes imply spammy mass posting or unclear customer value; Meta reads disallowed automation patterns.
• Screenshot theater — stills of a green “published” badge without a recreateable Login → connect → create post flow.
• Business Manager / verification gaps — app under a BM that cannot support the access level for publishing APIs.

Banner labels vary (“unable to verify the permission(s) requested,” “inadequate demonstration,” “disallowed use case”). Map the banner to missing Postiz app review publish evidence — not to a luckier resubmit day. Related: Unable to Verify Permissions, Inadequate Demonstration, Disallowed Use Case.

pages_manage_posts, Instagram, and Threads in one Postiz package

Many Postiz Meta submissions request pages_manage_posts, instagram_content_publish, and threads_content_publish (plus threads_basic) because agencies schedule those Meta channels from one calendar. That is valid when each module is live — but each still needs recreateable proof. A clean Facebook Page publish does not automatically prove Instagram Content Publishing API behavior (container create, media status, or the surface your Postiz build uses), and it does not prove Threads.

If Instagram or Threads publish is unfinished on your install, drop that scope from the Postiz app review round instead of hoping Meta will approve “the Facebook half.” Narrower, honest packages beat a maximal Meta checklist copied from another seller’s screencast. This guide does not cover WhatsApp template rejection appeals or phone-already-registered operations — those sit outside this App Review diagnosis service.

Postiz vs Stackposts vs inbox scripts (keep Category B lines separate)

Postiz and Stackposts are sister schedulers: both fail on publishing scopes, OAuth redirects, and cron/queue recreateability — not on messaging webhooks. Chatwoot, ChatPion, and BotSailor fail on inbox webhooks and channel/bot proof. Mixing those narratives in one Meta submission confuses reviewers. Keep this Postiz app review package focused on Page/IG/Threads publish modules you enabled. If you also run an inbox or chatbot script on the same BM, treat it as a separate app and separate review story whenever possible.

Common Postiz demo gaps (diagnosis, not secret sauce)

• Instructions that assume the reviewer already knows Postiz’s connect flow, provider settings, and schedule UI.
• Test Page / IG account not granted to the credentials you supplied.
• Screencast jumping past Facebook Login / Page grant into a pre-connected calendar.
• Queued post that never fires during the review window because the worker/cron is off on staging or self-hosted.
• Privacy Policy / data deletion URL on a different domain than the Postiz app Meta sees.

Self-hosted domains, Docker vs bare-metal, and SaaS multi-tenant models differ — copying another agency’s Postiz app review recording usually creates a new mismatch.

When a Postiz specialist audit helps

Useful after one or two Postiz app review rejections when the calendar “works for you” but Live tenants still cannot publish. The audit maps rejection language to evidence gaps: OAuth redirects, Page/IG/Threads connect, which Meta modules need Advanced Access, cron/queue fire proof, and Business Verification blockers.

Not useful if you only want a guaranteed one-size recording or every Meta permission enabled “just in case.” Over-requesting increases failure surface for any Postiz app review package. For installation + multi-network API service framing, see Postiz App Approval.