Messenger error 1: An unknown error occurred

Code 1 is the Graph API's least informative answer: "An unknown error occurred." The error-handling guide files it as "API Unknown", possibly a temporary issue due to downtime, wait and retry, and if it persists, verify you are calling an API that exists. The Messenger error-codes table adds a second, less obvious reading: "Missing permissions can cause this issue. Your app may need Advanced Access, Business Verification, or permissions."

That dual nature defines the handling. Transient code 1 looks like an incident: it appears across varied requests, correlates with Meta Status events, and disappears on retry. Structural code 1 looks like a wall: the same request fails every time, typically an endpoint gated behind Advanced Access or Business Verification answering vaguely instead of with a clean 10 or 200. Distinguishing the two is cheap: retry once with backoff, and if the failure is deterministic, stop retrying and audit access levels.

Meta's own table also documents subcode 1357046 ("Received invalid JSON reply") under code 1 for batch sends, where the batch succeeded yet the endpoint returned an error due to a system delay, a reminder that with code 1, verifying actual message delivery before retrying protects you from double-sending. Its transient siblings are code 2 and 1200; treat all three with the same idempotent-retry machinery.

{
  "error": {
    "message": "An unknown error occurred",
    "type": "OAuthException",
    "code": 1,
    "fbtrace_id": "BLBz/WZt8dN"
  }
}

You cannot prevent unknown errors, only bound their damage: idempotent sends, capped retries, and monitoring that separates deterministic failures from noise. Complete Business Verification early, it silently unlocks access classes whose absence surfaces as vague errors. The retry-class taxonomy (1, 2, 1200 vs throttles vs permanents) is laid out in the Messenger troubleshooting guide, with ceilings in the limits reference.