Messenger error 1200: Temporary send message failure

Code 1200 is the Messenger Platform's internal error: "Temporary send message failure. Please try again later." Meta's own Send API error documentation filed it under Internal Errors, the only code in that bucket, and the message means exactly what it says. The failure is on Meta's side or in the transient path between your request and delivery; your request was well-formed, authenticated, permitted, in-window and addressed to a reachable person, and the platform still could not send it right now.

That makes 1200 the one Messenger error where a retry is not just acceptable but the designed response. It is also rare enough in steady state that its frequency is a useful signal: isolated 1200s are background noise; a burst of them usually correlates with a Meta platform incident, which you can confirm on the Meta Status dashboard before touching your own code. During large incidents 1200 often appears alongside code 1 ("unknown error") and code 2 ("unexpected error, please retry"), the Graph API's generic transient pair.

The engineering risk with 1200 is not the error itself but naive retry logic. A tight retry loop turns a five-minute platform blip into a self-inflicted rate-limit problem (613 or 4), and a retry without idempotency can double-send when the first attempt actually succeeded after the response timed out. Retries need backoff, jitter, a retry budget, and deduplication keyed on your own message identifier.

What is NOT wrong: everything you control. Do not rotate tokens, resubmit for review, or rewrite payloads in response to 1200; if the error persists beyond your retry budget, capture the fbtrace_id values and open a Developer Support ticket, that trace is what lets Meta find the request in their logs.

{
  "error": {
    "message": "Temporary send message failure. Please try again later.",
    "type": "OAuthException",
    "code": 1200,
    "fbtrace_id": "Fz54k3GZrio"
  }
}

You cannot prevent Meta-side blips; you can make them invisible. Send through a durable queue so a failed attempt is a state transition, not a lost message, with backoff, retry budgets and idempotency built in. Separate the retryable class (1200, 1, 2) from throttling (back off harder) and from permanent errors (never retry) in one error-classification function. Where each code falls is summarized in the Messenger troubleshooting guide, with the platform's ceilings in the limits reference.