# Erreur WhatsApp 100 : Invalid parameter, cause et solution URL: https://wa.genuka.com/docs/errors/100 Language: French > Erreur WhatsApp 100 (Invalid parameter) sur la Cloud API : paramètre inconnu, mal orthographié ou trop long. Comment lire details et corriger la requête. L'erreur WhatsApp 100 signifie que votre requête à la Cloud API contient un paramètre que Meta ne reconnaît pas, mal orthographié, ou dont la valeur dépasse une limite. C'est le plus souvent une erreur de contenu : renvoyer la même requête échouera toujours. La cause est en général écrite dans le champ `details` ; avec le sous-code 33, c'est l'identifiant visé qui est en cause. ## Que signifie l'erreur 100 ? Meta la range dans les « autres erreurs » de la Cloud API : > « The request included one or more unsupported or misspelled parameters. » > — [Meta, codes d'erreur de la Cloud API](https://developers.facebook.com/documentation/business-messaging/whatsapp/support/error-codes#other-errors) La solution proposée par Meta liste quatre vérifications : consulter la référence de l'endpoint pour les paramètres acceptés et leur orthographe ; pour les WhatsApp Flows avec endpoint, fournir une clé publique RSA 2048 bits valide au format PEM ; s'assurer que le `phone_number_id` que vous enregistrez correspond à celui stocké précédemment ; et respecter les limites de longueur de chaque type. Dans la réponse de Graph, `message` vaut souvent `(#100) Invalid parameter`, un titre générique. L'information utile est ailleurs : Meta décrit `details` comme le champ qui peut dire « quel paramètre est invalide ou quelles valeurs sont acceptées » (même page). ## Quand l'erreur 100 apparaît-elle ? | Situation | Ce que renvoie Meta | Source | | ------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Paramètre inconnu ou mal orthographié | `(#100) Invalid parameter`, avec le paramètre en cause dans `details` | Meta | | Valeur au-delà d'une limite de longueur | Même code | Meta | | Clé publique Flows qui n'est pas une clé RSA 2048 bits en PEM | Même code | Meta | | Message non-template envoyé sur l'API Marketing Messages | `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) | | Identifiant de numéro ou de compte faux, ou jeton sans accès à cet actif | `error_subcode: 33` et « Unsupported post request. Object with ID '…' does not exist, cannot be loaded due to missing permissions, or does not support this operation », sans `details` | Retours de développeurs : [Activepieces](https://community.activepieces.com/t/whatsapp-business-error/4324), [Fast2SMS](https://www.fast2sms.com/help/?p=17132) | | Envoi d'un numéro vers lui-même | `(#100) Invalid parameter`, sans aucun détail | Constat Genuka | | Suppression d'un template sans droits sur le compte WhatsApp | `(#100) Need permission on either WhatsApp Business Account or owner/shared business` | Constat Genuka | Les deux dernières lignes viennent de nos propres appels. Pour l'envoi vers soi-même, Meta documente d'ailleurs un code dédié, `131021` (« Sender and recipient phone number is the same »), mais c'est un `100` nu que nous avons reçu. ### Où la voir dans Genuka WA ? Genuka WA valide une bonne partie de la requête **avant** Meta, et répond alors sans que Meta ait rien vu : | Contrôle Genuka | Réponse | | --------------------------------------------------------------------- | -------------------------------------------------------------- | | Message sans champ de contenu, média sans `assetId` ni `id` ni `link` | `400 missing_content`, `400 invalid_media` | | Template dont les composants sont mal formés | `400 invalid_template` (désactivable avec `"validate": false`) | | `to` égal au numéro qui envoie | `400 recipient_is_sender` | Quand le refus vient de Meta, Genuka relaie le code 100 sans le reclasser : la classe vaut `unknown`, non réessayable. ```json title="400 — POST /api/v1/messages" { "error": "send_unknown", "message": "…le texte de details, quand Meta en fournit un…", "meta": { "errorClass": "unknown", "retryable": false, "code": 100, "details": "…", "traceId": "AbC…" } } ``` Sur `POST /api/v1/templates`, le même refus revient en `422 meta_rejected`, avec le même objet `meta`. Le champ `raw` de `POST /api/v1/messages` n'est jamais validé par Genuka : les erreurs y remontent telles quelles depuis Meta ([Envoyer des messages](https://wa.genuka.com/docs/messages)). Dans une campagne `MARKETING`, un `100` renvoyé par l'API Marketing Messages fait renvoyer le message par l'endpoint `/messages` classique ; si celui-ci le refuse aussi, le destinataire passe `failed`. ### Que faire du sous-code 33 ? Ce n'est pas une erreur de contenu. Avec `meta.code: 100` et `meta.subcode: 33`, et un message qui commence par « Unsupported post request » (ou « get » pour une lecture), Graph dit que l'objet visé n'existe pas, ou que le jeton n'y a pas accès. Les causes rapportées sont un identifiant de numéro ou de compte WhatsApp erroné, un jeton qui a perdu l'accès à cet actif, ou un accès partenaire retiré ([Fast2SMS](https://www.fast2sms.com/help/?p=17132)). Avec Genuka WA, lisez `GET /api/v1/connections` : un numéro dont le statut n'est plus `connected` relève de la page [erreur 200](https://wa.genuka.com/docs/errors/200) ; un numéro supprimé côté Meta, de la page [erreur 33](https://wa.genuka.com/docs/errors/33). ## Comment corriger l'erreur 100 ? 1. **Lisez `meta.details`.** C'est la seule partie de la réponse qui nomme le problème. Journalisez-la avec `meta.traceId` et l'en-tête `x-request-id`. 2. **Comparez la requête à la référence.** Pour les envois, la [référence API](https://wa.genuka.com/docs/api#messages) et [Envoyer des messages](https://wa.genuka.com/docs/messages) listent chaque champ accepté et ses limites : 4 096 caractères pour un texte, 1 024 pour une légende d'image, 20 pour un titre de bouton, 3 boutons de réponse au plus. 3. **Retirez ce que vous avez ajouté « au cas où ».** Un champ Cloud API recopié dans `raw` mais inconnu de l'endpoint suffit à déclencher un `100`. 4. **Si `details` est vide, réduisez la requête.** Envoyez le même message dépouillé (un `text` simple vers le même numéro), puis réintroduisez les éléments un par un. Si un message minimal échoue aussi, vérifiez que `to` n'est pas le numéro émetteur et écrivez au support Genuka avec `x-request-id` et `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: "Votre colis est parti." }), }); const json = await response.json(); if (!response.ok) { // Tout ce qu'il faut pour diagnostiquer, sans renvoyer la requête. 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": "Votre colis est parti."}, 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" => "Votre colis est parti.", ]), ]); $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": "Votre colis est parti." }' \ | jq '{error, code: .meta.code, details: .meta.details, traceId: .meta.traceId}' ``` ## Comment éviter l'erreur 100 ? * **Gardez la validation de Genuka active.** Sur `POST /api/v1/templates`, ne passez `"validate": false` que pour un composant que Meta accepte et que notre validateur refuse. * **Préférez les champs typés à `raw`.** Les champs typés sont vérifiés dans leur forme avant l'envoi (champs requis, média sans `id` ni lien) ; les limites de longueur et de nombre restent appliquées par Meta, et `raw` n'est pas vérifié du tout. * **Testez chaque nouveau type de message sur un numéro de test** avant de le brancher sur un envoi de masse : un `100` est le même pour tous les destinataires. ## Quels codes sont liés ? * `131008` : il manque un paramètre requis. * `131009` : un paramètre existe, mais sa valeur est invalide. * `131021` : l'expéditeur et le destinataire sont le même numéro. * [132000](https://wa.genuka.com/docs/errors/132000) : le nombre de variables envoyées ne correspond pas au template. * [33](https://wa.genuka.com/docs/errors/33) : numéro supprimé (code 33), à ne pas confondre avec le sous-code 33 du code 100, qui signale un objet introuvable ou inaccessible (numéro supprimé ou accès perdu). * [200](https://wa.genuka.com/docs/errors/200) : l'accès au compte WhatsApp a été retiré ou la permission manque. ## FAQ ### Pourquoi `details` est-il parfois vide ? Meta ne le remplit pas toujours. L'envoi d'un numéro vers lui-même, par exemple, revient en `(#100) Invalid parameter` sans un mot de plus, d'où le contrôle préalable de Genuka WA. ### Faut-il réessayer une requête refusée en 100 ? Non. Le contenu est en cause, ou l'identifiant visé avec le sous-code 33 : la même requête produira la même erreur. Corrigez-la d'abord. ### Quelle différence entre l'erreur 100 et l'erreur 131009 ? Meta décrit 100 comme un paramètre non pris en charge ou mal orthographié, et 131009 comme un paramètre connu dont la valeur est invalide. Les deux se corrigent en lisant `details`. ### Genuka WA a accepté ma requête, pourquoi Meta la refuse-t-il ? Genuka vérifie la forme de la requête ; Meta vérifie aussi ce qu'il est seul à connaître, comme les paramètres propres à un endpoint ou l'état du compte. Le `traceId` relayé dans `meta` est ce que le support de Meta demande. ## 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)