WhatsApp error 100: Invalid parameter — cause and fix

WhatsApp error 100 means your Cloud API request contains a parameter Meta does not recognise, a misspelled one, or a value over a length limit. It is usually a content error: sending the same request again will always fail. The cause is generally spelled out in the details field; with subcode 33, the ID you are targeting is what is wrong.

What does error 100 mean?

Meta files it under the Cloud API's "other errors":

"The request included one or more unsupported or misspelled parameters." — Meta, Cloud API error codes

Meta's suggested fix lists four checks: read the endpoint reference for the supported parameters and their spelling; for WhatsApp Flows with an endpoint, provide a valid 2048-bit RSA public key in PEM format; make sure the phone_number_id you register matches the one stored previously; and stay under each type's length restrictions.

In the Graph response, message is often (#100) Invalid parameter, a generic title. The useful information is elsewhere: Meta describes details as the field that can say "which parameter is invalid or what values are acceptable" (same page).

When does error 100 happen?

The last two rows come from our own calls. For a send to oneself, Meta actually documents a dedicated code, 131021 ("Sender and recipient phone number is the same"), but what we received was a bare 100.

Where do you see it in Genuka WA?

Genuka WA validates much of the request before Meta, and then answers without Meta seeing anything:

When the refusal comes from Meta, Genuka relays code 100 without reclassifying it: the class is unknown, not retryable.

{
  "error": "send_unknown",
  "message": "…the details text, when Meta provides one…",
  "meta": {
    "errorClass": "unknown",
    "retryable": false,
    "code": 100,
    "details": "…",
    "traceId": "AbC…"
  }
}

On POST /api/v1/templates, the same refusal comes back as 422 meta_rejected with the same meta object. The raw field of POST /api/v1/messages is never validated by Genuka: errors come straight back from Meta (Send messages).

In a MARKETING campaign, a 100 from the Marketing Messages API makes Genuka resend the message through the regular /messages endpoint; if that refuses it too, the recipient turns failed.

What about subcode 33?

It is not a content error. With meta.code: 100 and meta.subcode: 33, and a message starting with "Unsupported post request" (or "get" for a read), Graph is saying the target object does not exist, or the token has no access to it. The reported causes are a wrong phone number or WhatsApp account ID, a token that lost access to that asset, or partner access that was removed (Fast2SMS). With Genuka WA, read GET /api/v1/connections: a number whose status is no longer connected belongs on the error 200 page; a number deleted on Meta's side, on the error 33 page.

How do I fix error 100?

const response = await fetch("https://wa.genuka.com/api/v1/messages", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.GENUKA_WA_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ connectionId: "con_1", to: "+237690000001", text: "Your parcel is on its way." }),
});
const json = await response.json();

if (!response.ok) {
  // Everything needed to diagnose, without sending the request again.
  console.error({
    status: response.status,
    error: json.error,
    metaCode: json.meta?.code,
    details: json.meta?.details ?? json.message,
    traceId: json.meta?.traceId,
    requestId: response.headers.get("x-request-id"),
  });
}

How do I prevent error 100?

• Keep Genuka's validation on. On POST /api/v1/templates, only pass "validate": false for a component Meta accepts and our validator refuses.
• Prefer typed fields over raw. Typed fields are checked for shape before sending (required fields, media with no id or link); length and count limits are still enforced by Meta, and raw is not checked at all.
• Test each new message type on a test number before wiring it into a bulk send: a 100 is the same for every recipient.

Related error codes

• 131008: a required parameter is missing.
• 131009: the parameter exists, but its value is invalid.
• 131021: sender and recipient are the same number.
• 132000: the number of variables sent does not match the template.
• 33: number deleted (code 33), not to be confused with subcode 33 of code 100, which flags an object that cannot be found or accessed (deleted number or lost access).
• 200: access to the WhatsApp account was removed, or a permission is missing.

FAQ

Why is details sometimes empty?

Meta does not always fill it. Sending from a number to itself, for instance, comes back as (#100) Invalid parameter with nothing more, which is why Genuka WA checks for it first.

Should I retry a request refused with 100?

No. The content is at fault, or the target ID with subcode 33: the same request will produce the same error. Fix it first.

What is the difference between error 100 and error 131009?

Meta describes 100 as an unsupported or misspelled parameter, and 131009 as a known parameter whose value is invalid. Both are fixed by reading details.

Genuka WA accepted my request, so why does Meta refuse it?

Genuka checks the shape of the request; Meta also checks what only it knows, such as endpoint-specific parameters or the state of the account. The traceId relayed in meta is what Meta support asks for.

Sources

• Meta — Error codes
• Meta — Error codes, Marketing Messages API for WhatsApp
• Activepieces community — code 100, error_subcode 33
• Fast2SMS — Unsupported POST/GET request, object does not exist