# WhatsApp error 100: Invalid parameter — cause and fix URL: https://wa.genuka.com/en/docs/errors/100 Language: English > WhatsApp Cloud API error 100 (Invalid parameter): an unknown, misspelled or too-long parameter. How to read details and fix the request. 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](https://developers.facebook.com/documentation/business-messaging/whatsapp/support/error-codes#other-errors) 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? | Situation | What Meta returns | Source | | ------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | Unknown or misspelled parameter | `(#100) Invalid parameter`, with the offending parameter in `details` | Meta | | Value over a length limit | Same code | Meta | | Flows public key that is not a 2048-bit RSA key in PEM | Same code | Meta | | Non-template message sent to the Marketing Messages API | `details`: "Message must be a template message." | [Meta](https://developers.facebook.com/documentation/business-messaging/whatsapp/support/error-codes#marketing-messages-api-for-whatsapp-error-codes) | | Wrong phone number or account ID, or a token without access to that asset | `error_subcode: 33` and "Unsupported post request. Object with ID '…' does not exist, cannot be loaded due to missing permissions, or does not support this operation", with no `details` | Developer reports: [Activepieces](https://community.activepieces.com/t/whatsapp-business-error/4324), [Fast2SMS](https://www.fast2sms.com/help/?p=17132) | | Sending from a number to itself | `(#100) Invalid parameter`, with no detail at all | Genuka observation | | Deleting a template without rights on the WhatsApp account | `(#100) Need permission on either WhatsApp Business Account or owner/shared business` | Genuka observation | 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: | Genuka check | Response | | ---------------------------------------------------------------------- | ------------------------------------------------------------------- | | Message with no content field, media with no `assetId`, `id` or `link` | `400 missing_content`, `400 invalid_media` | | Template with malformed components | `400 invalid_template` (can be turned off with `"validate": false`) | | `to` equal to the sending number | `400 recipient_is_sender` | When the refusal comes from Meta, Genuka relays code 100 without reclassifying it: the class is `unknown`, not retryable. ```json title="400 — POST /api/v1/messages" { "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](https://wa.genuka.com/en/docs/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](https://www.fast2sms.com/help/?p=17132)). With Genuka WA, read `GET /api/v1/connections`: a number whose status is no longer `connected` belongs on the [error 200](https://wa.genuka.com/en/docs/errors/200) page; a number deleted on Meta's side, on the [error 33](https://wa.genuka.com/en/docs/errors/33) page. ## How do I fix error 100? 1. **Read `meta.details`.** It is the only part of the response that names the problem. Log it with `meta.traceId` and the `x-request-id` header. 2. **Compare the request with the reference.** For sends, the [API reference](https://wa.genuka.com/en/docs/api#messages) and [Send messages](https://wa.genuka.com/en/docs/messages) list every accepted field and its limits: 4,096 characters for a text, 1,024 for an image caption, 20 for a button title, at most 3 reply buttons. 3. **Remove what you added "just in case".** A Cloud API field copied into `raw` but unknown to the endpoint is enough to trigger a `100`. 4. **If `details` is empty, shrink the request.** Send the same message stripped down (a plain `text` to the same number), then add elements back one at a time. If a minimal message fails too, check that `to` is not the sending number and contact Genuka support with `x-request-id` and `meta.traceId`. **Node.js** ```ts 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"), }); } ``` **Python** ```python import os import requests response = requests.post( "https://wa.genuka.com/api/v1/messages", headers={"Authorization": f"Bearer {os.environ['GENUKA_WA_API_KEY']}"}, json={"connectionId": "con_1", "to": "+237690000001", "text": "Your parcel is on its way."}, timeout=30, ) if not response.ok: body = response.json() meta = body.get("meta") or {} print({ "status": response.status_code, "error": body.get("error"), "meta_code": meta.get("code"), "details": meta.get("details") or body.get("message"), "trace_id": meta.get("traceId"), "request_id": response.headers.get("x-request-id"), }) ``` **PHP** ```php true, CURLOPT_RETURNTRANSFER => true, CURLOPT_USERAGENT => "acme-crm/1.0 (+https://example.com)", CURLOPT_HTTPHEADER => [ "Authorization: Bearer " . getenv("GENUKA_WA_API_KEY"), "Content-Type: application/json", ], CURLOPT_POSTFIELDS => json_encode([ "connectionId" => "con_1", "to" => "+237690000001", "text" => "Your parcel is on its way.", ]), ]); $body = json_decode(curl_exec($ch), true); $status = curl_getinfo($ch, CURLINFO_RESPONSE_CODE); curl_close($ch); if ($status >= 400) { error_log(json_encode([ "status" => $status, "error" => $body["error"] ?? null, "meta_code" => $body["meta"]["code"] ?? null, "details" => $body["meta"]["details"] ?? ($body["message"] ?? null), "trace_id" => $body["meta"]["traceId"] ?? null, ])); } ``` **curl** ```bash curl -s -X POST https://wa.genuka.com/api/v1/messages \ -H "Authorization: Bearer $GENUKA_WA_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "connectionId": "con_1", "to": "+237690000001", "text": "Your parcel is on its way." }' \ | jq '{error, code: .meta.code, details: .meta.details, traceId: .meta.traceId}' ``` ## 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](https://wa.genuka.com/en/docs/errors/132000): the number of variables sent does not match the template. * [33](https://wa.genuka.com/en/docs/errors/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](https://wa.genuka.com/en/docs/errors/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](https://developers.facebook.com/documentation/business-messaging/whatsapp/support/error-codes) * [Meta — Error codes, Marketing Messages API for WhatsApp](https://developers.facebook.com/documentation/business-messaging/whatsapp/support/error-codes#marketing-messages-api-for-whatsapp-error-codes) * [Activepieces community — code 100, error\_subcode 33](https://community.activepieces.com/t/whatsapp-business-error/4324) * [Fast2SMS — Unsupported POST/GET request, object does not exist](https://www.fast2sms.com/help/?p=17132)