Skip to main content
Before the API forwards a post to a platform, it runs every documented constraint locally — character count, media format, alt-text length, URL reachability, scope checks. When something fails the response is an preflight_failed error carrying the rule id that fired, plus a ruleUrl field with the absolute link to this page set — so a client doesn’t need to know the slug convention to deep-link a failure straight to its docs.

​
Why preflight

The most-cited developer complaint about social media APIs is that constraints are documented somewhere, but the runtime error doesn’t say which constraint you tripped. Examples from the research corpus that drove this product:
  • Instagram Reels rejecting Google Drive URLs as OAuthException 2207052.
  • LinkedIn returning generic 422s for URN format mismatches.
  • Threads returning HTTP 200 with a status code embedded in the body.
Preflight runs every documented rule before the upstream call. If we know it’ll fail, we surface the rule id immediately rather than wait for the platform to reject opaquely.

​
Reading a rule id

Rule ids look like <platform>.<surface>.<check>: 
bluesky.text.max_graphemes
threads.media.alt_text_max_graphemes
instagram.media.reachable
pinterest.image.size_max
Each one has its own page below — the rule id is the canonical link.

​
Rule catalog

​
Bluesky

​
Threads

​
Instagram

​
Facebook

​
LinkedIn

​
Pinterest

​
Twitter / X

​
Cross-platform

​
Validation without publishing

When POST /v1/posts/validate ships, you’ll be able to run the same preflight without the upstream call — useful in CI or before queueing a scheduled post. Today, the same validation runs synchronously on POST /v1/posts and returns the rule id on the first failure.