Threads

Threads has its own OAuth server, separate from Facebook and Instagram, even though it's also operated by Meta.

Scopes OmniPost requests

How OmniPost publishes

Like Instagram, Threads uses a container-then-publish model: POST /{threads-user-id}/threads creates a container (text, image, video, or carousel), OmniPost polls it, then POST /{threads-user-id}/threads_publish makes it live. Meta recommends polling roughly once a minute for up to five minutes — OmniPost handles this internally, so the target simply shows processing during that window.

Media constraints

Quirks to design around

• 500-character cap is much lower than Threads' own app UI historically allowed for some accounts — caption_too_long is a common target failure if you're repurposing long-form copy from another platform.
• Separate OAuth server from Instagram — a user who has connected Instagram has not thereby connected Threads; they're independent connect flows even for the same person.
• threads_basic on every call — Meta requires this scope for all API access, not just publishing, so it's always requested alongside threads_content_publish.

Rate limits

~250 posts per rolling 24-hour window per profile, plus 1,000 replies/24h and 100 deletions/24h. Exceeding it fails the target with platform_rate_limited.

App review, in brief

Threads uses the same Meta App Review pipeline as Instagram: Business Verification, a screencast and written use case per permission, and the app in Live Mode. A Deauthorize Callback URL and Data Deletion Callback/Instructions URL are mandatory and can be shared with your Instagram app configuration if both live under the same Meta App.