WhatsApp error 100: Invalid parameter

Code 100 is the Graph API's general-purpose validation failure: a parameter in your request is not recognized, is misspelled, or carries a value of the wrong shape. On the WhatsApp Cloud API it is probably the most frequent error during integration work, because the message payload is a nested JSON structure with many type-specific keys and a single wrong key name triggers it.

The useful information lives in error_data.details and often in the message string itself, which will say something like "Param text['body'] must be a non-empty UTF-8 string" or "(#100) Invalid parameter" followed by the path. Read that field before anything else. Meta's documentation also calls out two special cases: when setting a business public key it must be a valid 2048-bit RSA key in PEM format, and the phone number ID you register must match any previously stored one.

Code 100 does not indicate anything about permissions or account status. The request simply does not match the endpoint's schema.

Code 100 is synchronous and pre-queue: nothing was sent, nothing is billed, and nothing will arrive in a webhook, so a retry is safe once the payload is fixed. One gotcha specific to this code: every Graph API surface uses 100, so an integration that also calls Business Management or Marketing endpoints will see 100s with unrelated meanings - on the Marketing Messages API, for instance, it is documented for sends that are not template messages at all. Log the full message string, not just the number. For template parameter problems, compare 132000 (count mismatch) and 132012 (format mismatch), and validate the payload with the template checker; the field-by-field payload walkthrough in the error-code guide covers the shapes each message type accepts.

{
  "error": {
    "message": "(#100) Invalid parameter",
    "type": "OAuthException",
    "code": 100,
    "error_data": {
      "messaging_product": "whatsapp",
      "details": "Param text['body'] must be a non-empty UTF-8 string."
    },
    "fbtrace_id": "AbCdEfGhIjKlMnOpQr"
  }
}

Build payloads through typed builders or a JSON schema per message type so that unknown keys and wrong types are rejected in your own code, and keep one known-good request per type in your test suite. Surface error_data.details in logs verbatim; it is the fastest route from a code 100 to the offending field.