Skip to main content
Statut : prêt pour la production via WhatsApp Web (Baileys). Le Gateway gère la ou les sessions associées ; il n’existe pas de canal WhatsApp Twilio distinct.

Installation

openclaw onboard et openclaw channels add --channel whatsapp proposent d’installer le plugin lors de sa première sélection ; openclaw channels login --channel whatsapp propose le même processus d’installation si le plugin est absent. Les extractions de développement utilisent le chemin local du plugin ; les installations stables/bêta installent d’abord @openclaw/whatsapp depuis ClawHub, avec repli sur npm. Le runtime WhatsApp est distribué en dehors du paquet npm principal d’OpenClaw ; ses dépendances d’exécution restent donc avec le plugin externe. Installation manuelle :
Utilisez le paquet npm seul (@openclaw/whatsapp) uniquement pour le repli vers le registre ; épinglez une version exacte uniquement pour une installation reproductible.

Association

La politique par défaut des messages privés est l’association pour les expéditeurs inconnus.

Dépannage des canaux

Diagnostics intercanaux et procédures de réparation.

Configuration du Gateway

Modèles et exemples complets de configuration des canaux.

Configuration rapide

1

Configurer la politique d’accès

2

Associer WhatsApp (code QR)

La connexion s’effectue uniquement par code QR. Sur les hôtes distants ou sans interface graphique, prévoyez un moyen fiable de transmettre le code QR actif au téléphone avant de lancer la connexion ; les codes QR affichés dans le terminal, les captures d’écran ou les pièces jointes de discussion peuvent expirer pendant leur transmission.Pour un compte spécifique :
Pour rattacher un répertoire d’authentification existant ou personnalisé avant la connexion :
3

Démarrer le Gateway

4

Approuver la première demande d’association (mode association)

Les demandes d’association expirent après 1 heure ; le nombre de demandes en attente est limité à 3 par compte.
Un numéro WhatsApp distinct est recommandé (la configuration et les métadonnées sont optimisées pour ce cas), mais les configurations avec un numéro personnel ou une conversation avec soi-même sont entièrement prises en charge.

Modèles de déploiement

  • identité WhatsApp distincte pour OpenClaw
  • listes d’autorisation des messages privés et limites de routage plus claires
  • risque réduit de confusion avec les conversations avec soi-même
L’intégration initiale prend en charge le mode avec numéro personnel et écrit une configuration de référence adaptée aux conversations avec soi-même : dmPolicy: "allowlist", allowFrom incluant votre propre numéro, selfChatMode: true. Les protections d’exécution pour les conversations avec soi-même reposent sur le numéro personnel associé ainsi que sur allowFrom.

Modèle d’exécution

  • Le Gateway gère le socket WhatsApp et la boucle de reconnexion.
  • Un processus de surveillance suit indépendamment deux signaux : l’activité brute du transport WhatsApp Web et l’activité des messages applicatifs. Une session silencieuse mais connectée n’est pas redémarrée simplement parce qu’aucun message n’est arrivé récemment ; une reconnexion n’est forcée que lorsque les trames de transport cessent d’arriver pendant une fenêtre interne fixe (non configurable par l’utilisateur) ou lorsque les messages applicatifs restent silencieux au-delà de 4 fois le délai normal des messages. Juste après la reconnexion d’une session récemment active, cette première fenêtre utilise le délai normal des messages, plus court, au lieu de la fenêtre multipliée par 4. OpenClaw peut répondre automatiquement aux messages hors ligne que Baileys transmet au début de cette reconnexion, dans la limite de la durée de vie de la déduplication des identifiants de messages ; le démarrage initial conserve la courte protection contre l’historique obsolète.
  • Les délais du socket Baileys sont définis explicitement sous web.whatsapp.* : keepAliveIntervalMs (intervalle des signaux ping de l’application), connectTimeoutMs (délai d’expiration de la négociation initiale), defaultQueryTimeoutMs (attentes des requêtes Baileys, ainsi que délais d’expiration d’OpenClaw pour les envois sortants, la présence et les accusés de lecture entrants).
  • Les envois sortants nécessitent un écouteur WhatsApp actif pour le compte cible ; sinon, ils échouent immédiatement.
  • Les envois aux groupes joignent des métadonnées natives de mention pour les jetons @+<digits> et @<digits> (dans le texte et les légendes des médias) lorsque le jeton correspond aux métadonnées actuelles d’un participant, y compris dans les groupes basés sur un LID.
  • Les discussions de statut et de diffusion (@status, @broadcast) sont ignorées.
  • Les discussions directes utilisent les règles de session des messages privés (session.dmScope ; la valeur par défaut main regroupe les messages privés dans la session principale de l’agent). Les sessions de groupe sont isolées par JID (agent:<agentId>:whatsapp:group:<jid>).
  • Les canaux et newsletters WhatsApp peuvent être des cibles sortantes explicites par l’intermédiaire de leur JID @newsletter natif, en utilisant les métadonnées de session de canal (agent:<agentId>:whatsapp:channel:<jid>) plutôt que la sémantique des messages privés.
  • Le transport WhatsApp Web respecte les variables d’environnement de proxy standard sur l’hôte du Gateway (HTTPS_PROXY, HTTP_PROXY, NO_PROXY, ainsi que leurs variantes en minuscules). Préférez la configuration du proxy au niveau de l’hôte aux paramètres propres à chaque canal.
  • Lorsque messages.removeAckAfterReply est activé, OpenClaw supprime la réaction d’accusé de réception dès qu’une réponse visible est remise.

Appeler le demandeur actuel avec MeowCaller (expérimental)

Le plugin peut exposer whatsapp_call lors des tours d’agent provenant de WhatsApp. Il utilise MeowCaller pour passer un appel vocal WhatsApp au demandeur actuellement autorisé et lire un message TTS d’OpenClaw après sa réponse. L’outil ne possède aucun paramètre de numéro de destination ; une invite ne peut donc pas rediriger l’appel. Désactivé par défaut.
MeowCaller est expérimental, ne possède aucune version étiquetée et utilise une session d’appareil associé whatsmeow distincte : il ne peut pas réutiliser les identifiants Baileys du plugin. L’association ajoute un autre appareil associé au même compte WhatsApp ; scannez le code avec l’identité utilisée par OpenClaw. Le mode avec numéro personnel ou conversation avec soi-même ne peut pas s’appeler lui-même ; utilisez un numéro OpenClaw dédié pour appeler votre numéro personnel.
1

Activer les appels expérimentaux

Ajoutez actions.calls: true à la configuration du canal WhatsApp et redémarrez le Gateway :
Si ce paramètre est absent ou vaut false, OpenClaw n’expose pas l’outil whatsapp_call.
2

Installer la CLI MeowCaller vérifiée

L’adaptateur attend un exécutable meowcaller dans le PATH de l’hôte du Gateway. Jusqu’à la fusion de la PR MeowCaller nº 7, compilez la branche vérifiée :
Vérifiez que $HOME/.local/bin figure dans le PATH du service Gateway. Cette révision comporte des commandes explicites pair et notify d’envoi uniquement ; notify n’ouvre aucun microphone, haut-parleur, périphérique vidéo ni capture de diagnostic. Ne la remplacez pas par la commande play de l’exemple de CLI en amont.
3

Associer l’appareil MeowCaller

Demandez à l’agent WhatsApp de vérifier la configuration des appels (l’action d’état whatsapp_call indique le répertoire d’état propre au compte et la commande d’association). Pour le compte par défaut :
Exécutez cette commande de manière interactive, scannez le code QR depuis WhatsApp > Linked devices, puis attendez MeowCaller linked device ready. Gardez wa-voip.db privé : il s’agit de la session MeowCaller. Les comptes autres que celui par défaut obtiennent leur propre chemin de stockage par l’intermédiaire de l’action d’état ; sous Windows, exécutez sa commande PowerShell.
4

Configurer le TTS et appeler depuis WhatsApp

Configurez un fournisseur TTS compatible avec la téléphonie, redémarrez le Gateway, puis envoyez une demande telle que Call me and say the build finished. L’outil détermine l’expéditeur à partir du contexte entrant fiable, synthétise un fichier WAV privé temporaire, exécute MeowCaller pendant une fenêtre d’appel limitée, puis supprime le fichier audio. OpenClaw transmet explicitement le stockage du compte, attend un code de sortie nul après la réponse, la lecture et le raccrochage, et considère une expiration du délai ou un code de sortie non nul comme un échec de l’appel de l’outil.
Limites : appels audio sortants individuels uniquement, aucun numéro de destination arbitraire, aucune authentification partagée avec la connexion de discussion, aucun appel vers soi-même en mode avec numéro personnel ou conversation avec soi-même, audio synthétisé limité à 60 secondes, aucun accusé d’audibilité côté combiné au-delà de l’achèvement de la réponse, de la lecture et du raccrochage par MeowCaller, et OpenClaw arrête le processus compagnon après une fenêtre limitée de 115 à 175 secondes (couvrant les phases de connexion, de réponse, de lecture et d’arrêt de MeowCaller).

Invites d’approbation

WhatsApp peut afficher les invites d’approbation d’exécution et de plugin sous forme de réactions 👍/👎, contrôlées par la configuration générale de transfert des approbations :
approvals.exec et approvals.plugin sont indépendants ; l’activation de WhatsApp en tant que canal associe uniquement le transport et n’envoie rien, sauf si la famille d’approbations correspondante est activée et routée vers ce canal. Le mode session transmet les approbations natives par emoji uniquement pour les approbations provenant de WhatsApp. Le mode cible utilise le pipeline de transfert partagé pour les cibles explicites et ne crée pas de diffusion distincte vers les messages privés des approbateurs. Les réactions d’approbation WhatsApp nécessitent des approbateurs explicitement définis dans allowFrom (ou "*"). defaultTo définit les cibles ordinaires par défaut des messages, et non une liste d’approbateurs. Les commandes manuelles /approve suivent toujours le processus normal d’autorisation des expéditeurs WhatsApp avant la résolution de l’approbation.

Hooks de plugin et confidentialité

Les messages WhatsApp entrants peuvent contenir du contenu personnel, des numéros de téléphone, des identifiants de groupe, des noms d’expéditeurs et des champs de corrélation de session. WhatsApp ne diffuse pas aux plugins les charges utiles entrantes du hook message_received, sauf si vous les activez explicitement :
Limitez l’activation à un seul compte sous channels.whatsapp.accounts.<id>.pluginHooks.messageReceived. Activez cette option uniquement pour les plugins auxquels vous faites confiance pour traiter le contenu et les identifiants WhatsApp entrants.

Contrôle d’accès et activation

channels.whatsapp.dmPolicy :allowFrom accepte les numéros au format E.164 (normalisés en interne). Il s’agit uniquement d’une liste de contrôle d’accès des expéditeurs de messages privés : elle ne bloque pas les envois sortants explicites vers les JID de groupe ou les JID de canal @newsletter.Remplacement pour les configurations multicomptes : channels.whatsapp.accounts.<id>.dmPolicy (ainsi que .allowFrom) prévaut sur les valeurs par défaut du canal pour ce compte.Remarques sur l’exécution :
  • les associations persistent dans le magasin d’autorisations du canal et fusionnent avec les allowFrom configurés
  • l’automatisation planifiée et le destinataire de secours du Heartbeat utilisent des cibles de livraison explicites ou les allowFrom configurés ; les approbations d’association par message privé ne deviennent pas implicitement des destinataires Cron/Heartbeat
  • si aucune liste d’autorisations n’est configurée, le numéro personnel associé est autorisé par défaut
  • OpenClaw n’associe jamais automatiquement les messages privés fromMe sortants (les messages que vous vous envoyez depuis l’appareil associé)

Liaisons ACP configurées

WhatsApp prend en charge les liaisons ACP persistantes via le niveau supérieur bindings[] :
Les conversations directes correspondent aux numéros E.164 ; les groupes correspondent aux JID de groupe WhatsApp. Les listes d’autorisations de groupes, la politique relative aux expéditeurs et les contrôles de mention ou d’activation sont appliqués avant qu’OpenClaw ne vérifie l’existence de la session ACP liée. Une liaison correspondante contrôle le routage — les groupes de diffusion ne distribuent pas cette interaction aux sessions WhatsApp ordinaires.

Comportement du numéro personnel et de la conversation avec soi-même

Lorsque le numéro personnel associé figure également dans allowFrom, les protections de conversation avec soi-même s’activent : les accusés de lecture sont ignorés pour ces interactions, le déclenchement automatique par JID de mention qui vous notifierait vous-même est désactivé et les réponses utilisent par défaut [{identity.name}] (ou [openclaw]) lorsque messages.responsePrefix n’est pas défini.

Normalisation des messages et contexte

Les messages entrants sont encapsulés dans l’enveloppe entrante partagée. Une réponse citée ajoute le contexte sous cette forme :
Les métadonnées de réponse (ReplyToId, ReplyToBody, ReplyToSender, JID/E.164 de l’expéditeur) sont renseignées lorsqu’elles sont disponibles. Si la cible citée est un média téléchargeable, OpenClaw l’enregistre dans le magasin habituel des médias entrants et expose MediaPath/MediaType afin que l’agent puisse l’examiner directement au lieu de voir uniquement <media:image>.
Les messages contenant uniquement un média sont normalisés sous forme d’espaces réservés : <media:image>, <media:video>, <media:audio>, <media:document>, <media:sticker>.Les notes vocales de groupe autorisées sont transcrites avant le contrôle de mention lorsque le corps contient uniquement <media:audio>, de sorte que prononcer la mention du bot dans la note vocale peut déclencher la réponse. Si la transcription ne mentionne toujours pas le bot, elle reste dans l’historique de groupe en attente à la place de l’espace réservé brut.Les corps de messages de localisation s’affichent sous forme de coordonnées succinctes. Les libellés et commentaires de localisation, ainsi que les détails de contact ou de vCard, s’affichent comme des métadonnées non fiables dans un bloc délimité, et non comme du texte intégré à l’invite.
Les messages de groupe non traités sont mis en mémoire tampon, puis injectés comme contexte lorsque le bot est finalement déclenché.
  • limite par défaut : 50
  • configuration : channels.whatsapp.historyLimit, avec messages.groupChat.historyLimit comme solution de repli
  • 0 désactive cette fonctionnalité
Marqueurs d’injection : [Chat messages since your last reply - for context] et [Current message - respond to this].
Activés par défaut pour les messages entrants acceptés. Pour les désactiver globalement :
Remplacement par compte : channels.whatsapp.accounts.<id>.sendReadReceipts. Les interactions de conversation avec soi-même ignorent les accusés de lecture, même lorsqu’ils sont activés globalement.

Livraison, découpage et médias

  • limite de découpage par défaut : channels.whatsapp.textChunkLimit = 4000
  • channels.whatsapp.streaming.chunkMode = "length" | "newline" ; newline privilégie les limites de paragraphes (lignes vides), puis se rabat sur un découpage respectant la limite de longueur
  • prend en charge les charges utiles d’image, de vidéo, d’audio (note vocale PTT) et de document
  • l’audio est envoyé comme charge utile Baileys audio avec ptt: true, ce qui l’affiche comme une note vocale « push-to-talk » ; audioAsVoice est conservé dans les charges utiles de réponse afin que les notes vocales produites par synthèse vocale restent sur ce chemin, quel que soit le format source du fournisseur
  • l’audio Ogg/Opus natif est envoyé comme audio/ogg; codecs=opus ; tout autre format (y compris les sorties MP3/WebM de la synthèse vocale Microsoft Edge) est transcodé avec ffmpeg en Ogg/Opus mono à 48 kHz avant la livraison PTT
  • /tts latest envoie la dernière réponse de l’assistant sous forme d’une seule note vocale et empêche les envois répétés de la même réponse ; /tts chat on|off|default contrôle la synthèse vocale automatique pour la conversation actuelle
  • l’activation de gifPlayback: true sur une vidéo permet la lecture en GIF animé
  • forceDocument/asDocument achemine les images, GIF et vidéos sortants via la charge utile de document Baileys afin d’éviter la compression des médias par WhatsApp, tout en conservant le nom de fichier résolu et le type MIME
  • les légendes s’appliquent au premier média d’une réponse multimédia, sauf pour les notes vocales PTT : l’audio est envoyé en premier sans légende, puis la légende est envoyée dans un message texte distinct (les clients WhatsApp n’affichent pas les légendes des notes vocales de manière cohérente)
  • la source du média peut être HTTP(S), file:// ou un chemin local
  • limite d’enregistrement entrant et limite d’envoi sortant : channels.whatsapp.mediaMaxMb (valeur par défaut : 50)
  • remplacement par compte : channels.whatsapp.accounts.<id>.mediaMaxMb
  • les images sont automatiquement optimisées (redimensionnement et ajustement progressif de la qualité) pour respecter les limites, sauf si forceDocument/asDocument demande une livraison sous forme de document
  • en cas d’échec d’envoi d’un média, la solution de secours pour le premier élément envoie un avertissement textuel au lieu d’abandonner silencieusement la réponse

Citation des réponses

channels.whatsapp.replyToMode contrôle la citation native des réponses (les réponses sortantes citent visiblement le message entrant) : Remplacement par compte : channels.whatsapp.accounts.<id>.replyToMode.

Niveau de réaction

channels.whatsapp.reactionLevel contrôle l’étendue de l’utilisation des réactions emoji par l’agent : Remplacement par compte : channels.whatsapp.accounts.<id>.reactionLevel.

Réactions d’accusé de réception

channels.whatsapp.ackReaction envoie une réaction immédiate à la réception d’un message entrant, sous le contrôle de reactionLevel (supprimée lorsque "off") :
Remarques : envoyée immédiatement après l’acceptation du message entrant (avant la réponse) ; si ackReaction est présent sans emoji, WhatsApp utilise l’emoji d’identité de l’agent destinataire, avec « 👀 » comme valeur de secours (omettez ackReaction ou définissez emoji: "" pour désactiver l’accusé de réception) ; les échecs sont consignés dans les journaux, mais ne bloquent pas la livraison de la réponse ; le mode de groupe mentions ne réagit qu’aux interactions déclenchées par une mention, tandis que l’activation de groupe always contourne cette vérification ; WhatsApp utilise uniquement channels.whatsapp.ackReaction (l’ancien messages.ackReaction ne s’applique pas ici).

Réactions d’état du cycle de vie

Définissez messages.statusReactions.enabled: true pour permettre à WhatsApp de remplacer la réaction d’accusé de réception au cours d’une interaction, au lieu de conserver un emoji de réception statique, en parcourant des états tels que mise en file d’attente, réflexion, activité des outils, Compaction, terminé et erreur :
Remarques : channels.whatsapp.ackReaction contrôle toujours l’admissibilité pour les messages privés et les groupes ; l’état de mise en file d’attente utilise le même emoji effectif que les réactions ordinaires d’accusé de réception ; WhatsApp dispose d’un seul emplacement de réaction du bot par message, les mises à jour du cycle de vie remplacent donc la réaction actuelle sur place ; messages.removeAckAfterReply: true efface la réaction d’état finale après la durée de maintien configurée pour la réussite ou l’erreur ; les catégories d’emoji d’outils comprennent tool, coding, web, deploy, build et concierge.

Comptes multiples et identifiants

Les identifiants de compte proviennent de channels.whatsapp.accounts. Le compte sélectionné par défaut est default s’il est présent, sinon le premier identifiant de compte configuré (trié par ordre alphabétique). Les identifiants de compte sont normalisés en interne pour la recherche.
  • chemin d’authentification actuel : ~/.openclaw/credentials/whatsapp/<accountId>/creds.json (sauvegarde : creds.json.bak)
  • l’ancienne authentification par défaut dans ~/.openclaw/credentials/ est toujours reconnue et migrée pour les flux du compte par défaut
openclaw channels logout --channel whatsapp [--account <id>] efface l’état d’authentification WhatsApp de ce compte. Lorsqu’un Gateway est joignable, la déconnexion arrête d’abord l’écouteur actif de ce compte, afin que la session liée cesse de recevoir des messages avant le prochain redémarrage. openclaw channels remove --channel whatsapp arrête également l’écouteur actif avant de désactiver ou de supprimer la configuration du compte.Dans les anciens répertoires d’authentification, oauth.json est conservé tandis que les fichiers d’authentification Baileys sont supprimés.

Outils, actions et écritures de configuration

  • La prise en charge des outils de l’agent inclut l’action de réaction WhatsApp (react).
  • Contrôles des actions : channels.whatsapp.actions.reactions, channels.whatsapp.actions.polls (les actions existantes utilisent par défaut true), channels.whatsapp.actions.calls (valeur par défaut : false, voir MeowCaller ci-dessus).
  • Les écritures de configuration initiées par le canal sont activées par défaut ; désactivez-les via channels.whatsapp.configWrites: false.

Dépannage

Symptôme : l’état du canal indique qu’il n’est pas lié.
Symptôme : le compte lié subit des déconnexions ou des tentatives de reconnexion répétées.Les comptes silencieux peuvent rester connectés au-delà du délai d’expiration normal des messages ; le mécanisme de surveillance ne redémarre que lorsque l’activité du transport WhatsApp Web s’arrête, que le socket se ferme ou que l’activité au niveau de l’application reste silencieuse au-delà de la fenêtre de sécurité plus longue (voir le modèle d’exécution ci-dessus).Si les journaux affichent status=408 Request Time-out Connection was lost de manière répétée, ajustez les délais du socket Baileys sous web.whatsapp. Commencez par réduire keepAliveIntervalMs en dessous du délai d’inactivité de votre réseau et par augmenter connectTimeoutMs sur les connexions lentes ou sujettes aux pertes :
Correctif :
Si la boucle persiste après la correction de la connectivité de l’hôte et des délais, sauvegardez le répertoire d’authentification du compte et rétablissez la liaison :
Si ~/.openclaw/logs/whatsapp-health.log indique Gateway inactive, mais que openclaw gateway status et openclaw channels status --probe indiquent tous deux un état sain, exécutez openclaw doctor. Sous Linux, doctor avertit de la présence d’anciennes entrées crontab qui appellent le script retiré ~/.openclaw/bin/ensure-whatsapp.sh ; supprimez ces entrées avec crontab -e — Cron peut ne pas disposer de l’environnement du bus utilisateur systemd, ce qui amène cet ancien script à signaler incorrectement l’état du Gateway.
Symptôme : openclaw channels login --channel whatsapp échoue avant d’afficher un code QR utilisable, avec status=408 Request Time-out ou une déconnexion du socket TLS.La connexion à WhatsApp Web utilise l’environnement de proxy standard de l’hôte du Gateway (HTTPS_PROXY, HTTP_PROXY, variantes en minuscules, NO_PROXY). Vérifiez que le processus du Gateway hérite de l’environnement du proxy et que NO_PROXY ne correspond pas à mmg.whatsapp.net.
Les envois sortants échouent immédiatement lorsqu’aucun écouteur actif du Gateway n’existe pour le compte cible. Vérifiez que le Gateway est en cours d’exécution et que le compte est lié.
Les lignes de la transcription enregistrent ce que l’agent a généré ; la livraison WhatsApp est vérifiée séparément. OpenClaw considère une réponse automatique comme envoyée uniquement après que Baileys a renvoyé un identifiant de message sortant pour au moins un envoi visible de texte ou de média.Les réactions d’accusé de réception sont des reçus indépendants envoyés avant la réponse — une réaction réussie ne prouve pas que la réponse ultérieure contenant du texte ou un média a été acceptée. Recherchez auto-reply delivery failed ou auto-reply was not accepted by WhatsApp provider dans les journaux du Gateway.
Vérifiez dans cet ordre : groupPolicy, groupAllowFrom/allowFrom, les entrées de la liste d’autorisation groups, le contrôle des mentions (requireMention + motifs de mention) et les clés en double dans openclaw.json (les entrées JSON5 ultérieures remplacent les précédentes — conservez un seul groupPolicy par portée).Si channels.whatsapp.groups est présent, WhatsApp peut toujours observer les messages d’autres groupes, mais OpenClaw les ignore avant le routage de session. Ajoutez le JID du groupe à channels.whatsapp.groups, ou ajoutez groups["*"] pour autoriser tous les groupes tout en conservant l’autorisation des expéditeurs sous groupPolicy/groupAllowFrom.
Les Gateway OpenClaw nécessitent Node. Bun ne fournit pas l’API node:sqlite utilisée par le magasin d’état canonique, et doctor migre les anciens services Bun vers Node.

Invites système

WhatsApp prend en charge les invites système de type Telegram pour les groupes et les discussions directes via les tables groups et direct. Résolution pour les messages de groupe : la table groups effective est d’abord déterminée — si le compte définit sa propre clé groups, elle remplace entièrement la table racine groups (sans fusion profonde). La recherche de l’invite s’effectue ensuite sur cette unique table résultante :
  1. Invite propre au groupe (groups["<groupId>"].systemPrompt) : utilisée lorsque l’entrée du groupe existe et que sa clé systemPrompt est définie. Une chaîne vide ("") désactive le caractère générique et n’applique aucune invite.
  2. Invite générique des groupes (groups["*"].systemPrompt) : utilisée lorsque l’entrée du groupe concerné est absente ou existe sans clé systemPrompt.
La résolution des messages directs suit le même modèle pour la table direct et direct["*"].
dms reste le conteneur léger de remplacement de l’historique propre à chaque message direct (dms.<id>.historyLimit). Les remplacements d’invite se trouvent sous direct.
Ce comportement où le compte remplace la racine pour la résolution des invites est un simple remplacement superficiel : toute clé de compte groups/direct, y compris un objet vide explicite, remplace la table racine. Il diffère de la vérification de la liste d’autorisation d’appartenance aux groupes décrite ci-dessus, qui dispose d’un filet de sécurité pour les configurations à compte unique lorsqu’un groups: {} est accidentellement vide.
Différence avec Telegram : Telegram ignore la valeur racine groups pour chaque compte d’une configuration multicomptes (même pour les comptes qui ne possèdent aucun groups) afin d’empêcher un bot de recevoir des messages provenant de groupes auxquels il n’appartient pas. WhatsApp n’applique pas cette protection — les valeurs racines groups/direct sont héritées par tout compte sans remplacement propre, quel que soit le nombre de comptes. Dans une configuration WhatsApp multicomptes, définissez explicitement la table complète sous chaque compte si vous souhaitez des invites propres à chaque compte. Comportements importants :
  • channels.whatsapp.groups est à la fois une table de configuration propre à chaque groupe et la liste d’autorisation des groupes au niveau de la discussion. À la portée racine ou à celle du compte, groups["*"] signifie « tous les groupes sont autorisés » pour cette portée.
  • N’ajoutez un caractère générique systemPrompt que si vous souhaitez déjà autoriser tous les groupes pour cette portée. Pour limiter l’admissibilité à un ensemble fixe d’identifiants de groupe, répétez l’invite dans chaque entrée explicitement autorisée au lieu d’utiliser groups["*"].
  • L’admission des groupes et l’autorisation des expéditeurs sont deux vérifications distinctes. groups["*"] élargit l’ensemble des groupes qui atteignent le traitement des groupes ; il n’autorise pas tous les expéditeurs de ces groupes — cela reste contrôlé par groupPolicy/groupAllowFrom.
  • channels.whatsapp.direct n’a aucun effet secondaire équivalent pour les messages directs : direct["*"] fournit uniquement une configuration par défaut après qu’un message direct a déjà été admis par dmPolicy ainsi que par allowFrom ou les règles du magasin de liaisons.
Exemple :

Renvois vers la référence de configuration

Référence principale : Référence de configuration - WhatsApp

Pages connexes