Threads API App Review: Why threads_content_publish and threads_manage_replies Get Rejected
The Threads API runs on the same App Review model as Facebook and Instagram — but the permission names, the tester rules, and the token lifecycle are different enough that teams who already ship Meta integrations still get stuck the first time they connect Threads.
The Threads Permission Model
Every Threads API app is built on a dedicated Threads use case inside a Meta app — not the standard Facebook Login flow. Access is controlled by five distinct scopes, and each one only works for real, non-tester users after it clears App Review:
threads_basic
Required for every Threads endpoint. Lets your app read the user’s profile and the media they’ve posted.
threads_content_publish
Required for publishing endpoints — single posts, carousels, text, images, and video.
threads_manage_replies
Required for POST calls to reply endpoints — posting or moderating replies on behalf of the user.
threads_read_replies
Required for GET calls to reply endpoints — reading reply threads.
threads_manage_insights
Required for GET calls to the insights endpoints — views, likes, and engagement data.
The Tester Trap
This is where most teams misjudge their own readiness. Threads testers (accounts added under App Roles in the App Dashboard) can grant an app any of the five permissions immediately — no App Review needed. A demo that works perfectly for the developer and a handful of invited testers can still be completely unreviewed and unapproved for the public.
For any Threads user without a role on the app to grant these permissions, each one must be individually approved through App Review, and the app itself must be published. Teams that test only with tester accounts often discover the gap only after real users start hitting authorization walls in production.
Where Submissions Get Stuck
- Public media hosting missed — Threads downloads media from a publicly accessible URL at the moment of publishing. Images or video sitting behind auth-gated storage fail silently.
- Screencast doesn’t match the scope requested — reviewers expect to see the exact permission in action (e.g. a reply being posted for threads_manage_replies), not just the app’s general UI.
- Token refresh logic missing — long-lived tokens last 60 days and permission grants for public-profile users last 90 days; apps that don’t implement the refresh call lose access silently after that window.
- Private-profile users assumed to auto-renew — a permission grant from a private Threads account cannot be extended by refreshing the token; the user must re-grant it manually.
- Over-scoping — requesting threads_manage_insights or threads_manage_replies when the app only actually publishes content is a common, avoidable rejection trigger.
Token Lifecycle Basics
Short-lived token
Valid for 1 hour. Issued after the user completes the Authorization Window and your app exchanges the authorization code.
Long-lived token
Valid for 60 days. Exchanged from a still-valid short-lived token; refreshable before expiry via the refresh endpoint.
FAQ
Only if non-tester users need to grant the permissions. An internal tool used solely by invited testers can run without it — but it can’t serve the public.
No. Threads API access requires adding the dedicated Threads use case to a Meta app, which issues its own Threads app ID and secret — separate from the app’s main Facebook Login credentials.
No. threads_content_publish, threads_manage_replies, and threads_read_replies are separate scopes reviewed independently — each must be requested and justified on its own.
This sits inside the same review pipeline used for Facebook Login permissions and the Meta App Review use case description guide — see the Facebook & Meta App Review service page for submission support. Meta makes all App Review and permission approval decisions independently; this is not an official Meta partnership and no review outcome can be guaranteed.