Skip to main content
Stellen Sie eine Instanz Ihres eigenen WeCom-Kontos bereit, melden Sie sich durch Scannen mit WeCom auf dem Mobiltelefon an und lesen Sie Konto, Kontakte, Unterhaltungen und lokal synchronisierte Nachrichten über REST API oder MCP. Die Instanz entspricht einem normalen WeCom-Konto und erfordert weder einen privaten Server noch eine Konfiguration einer Unternehmens-E-Mail-Domain. Derzeit Alpha. Das Auslesen des Kontos hat die Validierung echter Unterhaltungen abgeschlossen; das Senden eigener Texte und das Zurücklesen von Ereignissen haben die echte Abnahme abgeschlossen; andere Kontakte, Gruppenoperationen und die Wiederherstellung neuer Instanzen müssen noch einer Abnahme der Bereitstellungsumgebung unterzogen werden. Das Senden von Medien, Antworten mit Zitaten, echtes @, Gruppenmitgliederverwaltung und Zustellbestätigungen sind noch nicht verfügbar. Maßgeblich ist der Rückgabewert von /api/capabilities der Instanz.

Bereitstellung und Anmeldung

Aktivieren Sie den Dienst in der Kategorie Deployment und wählen Sie ein Laufzeitpaket für die Instanz. Öffnen Sie nach der Bereitstellung die Verwaltungsseite und scannen Sie mit WeCom des Kontoinhabers; falls eine Bestätigung auf dem Mobiltelefon oder andere Anmeldeschritte erforderlich sind, öffnen Sie den Remote-Desktop und geben Sie das Desktop-Passwort dieser Instanz ein. API-Anmeldedaten und Desktop-Passwort sind unabhängig. Die Anmeldedaten werden auf dem Instanzdatenträger gespeichert; beim Neuerstellen des Containers bleibt der Datenträger erhalten; beim Löschen des Datenträgers wird die lokale Sitzung gelöscht. Jede Instanz wird separat abgerechnet und läuft entsprechend der bereits gekauften Laufzeit. REST-/MCP-Aufrufe werden nicht zusätzlich pro Nachricht berechnet, der tatsächliche Preis richtet sich nach der Paketseite. Derzeit wird standardmäßig auf die Laufzeitpakete des WeChat-Roboters verwiesen; vor der endgültigen Freigabe muss die Preisgestaltung zusammen mit den Betriebsressourcen bestätigt werden.

API und MCP

Verwenden Sie die Instanz-API-Adresse auf der Verwaltungsseite; alle Kontoschnittstellen führen Authorization: Bearer <Instanz-API-Token> mit. Diese Pfade gehören zu einer dedizierten Instanz und sind kein gemeinsames API-Gateway. Die MCP-Adresse ist die Instanzadresse mit angehängtem /mcp/ und verwendet dasselbe Bearer-Token. Der Sendetext enthält target, type: "text" und text. target akzeptiert Unterhaltungs-ID, Kontakt-ID, Unternehmensbenutzer-ID oder einen eindeutigen vollständigen Namen; IDs werden bevorzugt verwendet; falls der Anzeigename weiterhin keine eindeutige Zuordnung ermöglicht, lehnt die Instanz die Operation ab und errät kein Objekt. Kontakte ohne lokale Unterhaltung öffnen zunächst über den Client eine Unterhaltung und senden erst nach Abgleich der tatsächlichen Unterhaltungs-ID. Der Anforderungsheader Idempotency-Key besteht aus 8–128 Buchstaben, Ziffern oder _.:-. Wiederholte Anfragen für dieselbe Operation müssen denselben Schlüssel und denselben Anforderungstext wiederverwenden. Durch Ersetzen von target durch das Array targets kann seriell an 1–50 eindeutig angegebene Ziele gesendet werden. Beide können nicht gleichzeitig bereitgestellt werden. Alle Ziele schließen zunächst die Identitätsauflösung ab; unterschiedliche Aliase, die auf dasselbe Objekt zeigen, werden abgelehnt. Nach dem Fehlschlagen eines Ziels werden nachfolgende Sendungen gestoppt, und das Aufgabenergebnis zeichnet für jedes Element succeeded, failed, unknown oder not_attempted auf; behandeln Sie einen Teilerfolg nicht als vollständigen Erfolg. Dieser Ablauf muss in der Bereitstellungsumgebung noch mit angegebenen Kontakten echt abgenommen werden. Aufgaben können sich in queued, running, submitting, succeeded, failed, unknown oder cancelled befinden. succeeded bedeutet, dass nach dem Absenden in den entsprechenden Unterhaltungsaufzeichnungen der exakte Text und die Servernachrichten-ID gefunden wurden; delivered ist weiterhin null und bedeutet nicht, dass die andere Seite ihn erhalten hat. unknown bedeutet, dass das Ergebnis unklar ist; prüfen Sie den Verlauf und senden Sie nicht mit einem neuen Schlüssel erneut. Die Instanz sendet unterbrochene Aufgaben nicht automatisch erneut. Der Verlauf enthält nur Inhalte, die der Client bereits synchronisiert hat, und kann nicht den gesamten Verlauf garantieren. Nicht-Textnachrichten können als Typ unknown zurückgegeben werden, der Anhang-Download ist noch nicht verfügbar. Ereignisse bewahren die letzten 10.000 Einträge auf, gap bedeutet, dass der Cursor das Aufbewahrungsfenster überschritten hat. Die erste Verbindung spielt alten Verlauf nicht als neue Nachrichten erneut ab. server_accepted und server_id im Nachrichtenverlauf können verwendet werden, um zu überprüfen, ob der Server lokale Nachrichten akzeptiert hat; wenn nur ein lokaler Eintrag ohne Server-ID erscheint, kann der Versand nicht als erfolgreich angesehen werden. Diese Felder bedeuten nicht, dass der Empfänger die Nachricht erhalten oder gelesen hat. Ereignisaufzeichnungen bewahren den Status zum Zeitpunkt der Erzeugung auf; verwenden Sie zur Abfrage des aktuellen Bestätigungsstatus die Nachrichtenverlaufschnittstelle.

Konto und Anmeldedaten

Melden Sie sich nur bei Konten an, zu deren Bedienung Sie berechtigt sind. Konfigurieren Sie das API-Token in vertrauenswürdigen Anwendungen; es kann auf die Kontodaten dieser Instanz zugreifen. Veröffentlichen Sie keine Passwörter, QR-Codes oder Chat-Screenshots an öffentlichen Orten. Das Pausieren der Instanz unterbricht Echtzeitereignisse. Nach einer Kontoabmeldung oder dem Entfernen des Geräts auf dem Mobiltelefon ist eine erneute Anmeldung erforderlich. Die aktuelle Texteingabe unterstützt nur eine Zeile; Zeilenumbrüche werden vor dem Senden ausdrücklich abgelehnt. Wenn der Client eine Sicherheitsverifizierung oder erneute Anmeldung verlangt, sollte der Kontoinhaber diese im Remote-Desktop abschließen; die Instanz umgeht keine Verifizierung. Aufgaben nach einer Unterbrechung der Verifizierung können unknown zurückgeben; fragen Sie zuerst die Nachrichtenaufzeichnungen ab und senden Sie nicht mit einem neuen Idempotenzschlüssel erneut. Wenn Sicherheitsverifizierungsaufforderungen, Kontoabmeldung oder Änderungen erkannt werden, wird die Automatisierungswarteschlange dauerhaft pausiert. Nach Abschluss der Mobiltelefonverifizierung können noch nicht ausgeführte Aufgaben über „Nach Verifizierung fortsetzen“ in der Instanzkonsole weitergeführt werden; bereits übermittelte Aufgaben mit unklarem Ergebnis werden nicht erneut gesendet. Auch normale Remote-Arbeit kann eine WeCom-Sicherheitsverifizierung auslösen. Das offiziell beschriebene 24-Stunden-Fenster nach der Verifizierung ohne erneute Sperrung bedeutet nicht, dass die Erkennung bereits aufgehoben wurde, und bedeutet auch nicht, dass die Instanz einen langfristig unbeaufsichtigten Betrieb garantieren kann.