The request passed every preflight rule we know about, but the upstream platform still said no. This is rare — when it happens we treat it as a gap in preflight coverage and either add a rule or sharpen an existing one.Documentation Index
Fetch the complete documentation index at: https://docs.letmepost.dev/llms.txt
Use this file to discover all available pages before exploring further.
What triggers it
- A platform rule we don’t yet enforce locally — e.g., a content moderation rejection, an account-state issue (rate-limited at the platform level, suspended), or a constraint introduced after our last update.
- An async media-validation failure on Meta’s container flow (the file passed our size + mime checks but failed deeper inspection).
- A platform-specific rejection we haven’t translated into a preflight rule yet.
Response shape
platform_rejected.json
platformResponse carries the raw upstream body, untouched. That’s the most useful signal when this code surfaces — we don’t summarize it away.
How to handle
- Inspect
platformResponsefor the upstream code / subcode. - If it’s a known opaque rejection (e.g., Instagram’s
OAuthException 2207052), check the matching preflight rule page and follow the remediation there. - File an issue: every
platform_rejectedwe see in production is a candidate for a new preflight rule. The dashboard’s post log makes these easy to spot.
HTTP status
4xx(the platform’s status, passed through) when the upstream said the call is invalid.502 Bad Gatewaywhen the upstream returned a 5xx — we map upstream 5xx to our 502 +platform_unavailableinstead ofplatform_rejected. Seeplatform_unavailablefor that case.
Related
platform_unavailable— upstream returned 5xx; transient.preflight_failed— we caught it before the platform did.