Erreur WhatsApp 100 : Invalid parameter, cause et solution

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

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 ?

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 :

Quand le refus vient de Meta, Genuka relaie le code 100 sans le reclasser : la classe vaut unknown, non réessayable.

{
  "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).

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). 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 ; un numéro supprimé côté Meta, de la page erreur 33.

Comment corriger l'erreur 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: "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"),
  });
}

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 : le nombre de variables envoyées ne correspond pas au template.
• 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 : 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
• Meta — Error codes, Marketing Messages API for WhatsApp
• Activepieces community — code 100, error_subcode 33
• Fast2SMS — Unsupported POST/GET request, object does not exist