Robot WeCom

Déployez votre propre instance de compte WeCom, connectez-vous en scannant le code avec l’application mobile WeCom, puis lisez le compte, les contacts, les conversations et les messages synchronisés localement via REST API ou MCP. L’instance correspond à un compte WeCom ordinaire, sans nécessiter de serveur privé ni de configuration de domaine d’e-mail d’entreprise. Actuellement en Alpha. La lecture du compte a terminé une validation sur des conversations réelles ; l’envoi de texte par le titulaire et la relecture des événements ont terminé une validation réelle ; les opérations sur les autres contacts, les groupes et la restauration de nouvelles instances doivent encore terminer la validation de l’environnement de déploiement. L’envoi de médias, les réponses avec citation, les véritables @, la gestion des membres de groupe et les accusés de réception ne sont pas encore ouverts. Veuillez vous référer à la valeur renvoyée par /api/capabilities de l’instance.

​

Déploiement et connexion

Activez le service dans la catégorie Deployment et choisissez une formule de durée d’instance. Après le déploiement, ouvrez la page de gestion et utilisez le compte WeCom concerné pour scanner le code ; si une confirmation sur téléphone ou d’autres étapes de connexion sont requises, ouvrez le bureau à distance et saisissez le mot de passe de bureau de cette instance. Les identifiants API et le mot de passe de bureau sont indépendants. Les données de connexion sont enregistrées sur le disque de l’instance ; la reconstruction du conteneur conserve le disque ; la suppression du disque supprimera les sessions locales. Chaque instance est facturée indépendamment et fonctionne selon la durée achetée. Les appels REST / MCP ne sont pas facturés séparément par message ; le prix réel est celui affiché sur la page de la formule. La référence par défaut actuelle est la formule de durée des robots WeChat ; avant l’ouverture finale, la tarification doit être confirmée en fonction des ressources d’exécution.

​

API et MCP

Utilisez l’adresse API de l’instance sur la page de gestion ; toutes les interfaces de compte doivent inclure Authorization: Bearer <token API de l’instance>. Ces chemins appartiennent à l’instance dédiée et ne sont pas une passerelle API partagée. L’adresse MCP est l’adresse de l’instance suivie de /mcp/, avec le même token Bearer. Le corps d’envoi contient target, type: "text" et text. target accepte un ID de conversation, un ID de contact, un ID d’utilisateur d’entreprise ou un nom complet unique ; privilégiez les ID ; lorsqu’un nom affiché ne permet toujours pas une identification unique, l’instance refusera l’opération et ne devinera pas l’objet. Pour un contact sans conversation locale, le client ouvrira d’abord une conversation, puis enverra après avoir vérifié l’ID réel de la conversation. L’en-tête de requête Idempotency-Key contient 8 à 128 lettres, chiffres ou _.:-. Les requêtes répétées pour la même opération doivent réutiliser la même clé et le même corps de requête. Remplacez target par le tableau targets pour envoyer en série à 1–50 cibles explicitement spécifiées. Les deux ne peuvent pas être fournis simultanément. Toutes les cibles terminent d’abord la résolution d’identité ; différents alias pointant vers le même objet seront refusés. Après l’échec d’une cible, les envois suivants s’arrêtent ; le résultat de la tâche enregistre pour chaque élément succeeded, failed, unknown ou not_attempted ; ne considérez pas un succès partiel comme un succès total. Ce processus doit également terminer une validation réelle auprès des contacts désignés dans l’environnement de déploiement. Les tâches peuvent être dans l’état queued, running, submitting, succeeded, failed, unknown ou cancelled. succeeded signifie qu’après soumission, le texte exact et l’ID de message serveur ont été trouvés dans l’enregistrement de la conversation correspondante ; delivered reste null et ne signifie pas que l’autre partie l’a reçu. unknown signifie que le résultat n’est pas clair ; vérifiez l’historique et ne répétez pas l’envoi avec une nouvelle clé. L’instance ne renvoie pas automatiquement les tâches interrompues. L’historique ne contient que le contenu déjà synchronisé par le client et ne peut pas garantir l’intégralité de l’historique. Les messages non textuels peuvent renvoyer le type unknown ; le téléchargement des pièces jointes n’est pas encore ouvert. Les événements conservent les 10 000 plus récents ; gap indique que le curseur a dépassé la fenêtre de conservation. La première connexion ne rejouera pas l’ancien historique comme de nouveaux messages. server_accepted et server_id dans l’historique des messages peuvent être utilisés pour vérifier si le serveur a accepté le message local ; lorsqu’il n’existe qu’un enregistrement local sans ID serveur, l’envoi ne peut pas être considéré comme réussi. Ces champs ne signifient pas que le destinataire a reçu ou lu le message. Les enregistrements d’événements conservent l’état au moment de leur génération ; pour consulter l’état de confirmation actuel, utilisez l’interface d’historique des messages.

​

Compte et identifiants

Connectez-vous uniquement à des comptes que vous êtes autorisé à utiliser. Configurez le token API dans des applications fiables ; il peut accéder aux données de compte de cette instance. Ne publiez pas les mots de passe, codes QR ou captures d’écran de conversation dans des lieux publics. Mettre l’instance en pause interrompra les événements en temps réel. Après la déconnexion du compte ou le retrait de l’appareil depuis le téléphone, vous devrez vous reconnecter. La saisie de texte actuelle ne prend en charge qu’une seule ligne ; les sauts de ligne seront explicitement refusés avant l’envoi. Lorsque le client exige une vérification de sécurité ou une nouvelle connexion, le titulaire du compte doit l’effectuer dans le bureau à distance ; l’instance ne contournera pas la vérification. Les tâches après une interruption de vérification peuvent renvoyer unknown ; consultez d’abord les enregistrements de messages, ne renvoyez pas avec une nouvelle clé d’idempotence. Lorsque des invites de vérification de sécurité, une déconnexion de compte ou des modifications sont détectées, la file d’automatisation sera mise en pause de manière persistante. Après avoir terminé la vérification sur téléphone, vous pouvez continuer les tâches non encore exécutées via « Reprendre après vérification » dans la console de l’instance ; les tâches déjà soumises mais dont le résultat est incertain ne seront pas renvoyées. Le travail à distance normal peut également déclencher la vérification de sécurité WeCom. La fenêtre indiquée officiellement selon laquelle aucun verrouillage ne se produit pendant 24 heures après la vérification ne signifie pas que la détection a été éliminée, ni que l’instance peut garantir un fonctionnement sans surveillance à long terme.