/api/capabilities instancji.
Wdrożenie i logowanie
Aktywuj usługę w kategorii Deployment i wybierz pakiet czasu trwania instancji. Po wdrożeniu otwórz stronę zarządzania i użyj WeCom właściciela konta do zeskanowania kodu; jeśli wymagane jest potwierdzenie na telefonie lub inne kroki logowania, otwórz pulpit zdalny i wprowadź hasło pulpitu tej instancji. Dane uwierzytelniające API i hasło pulpitu są niezależne. Dane logowania są przechowywane na dysku instancji, a ponowne utworzenie kontenera zachowuje dysk; usunięcie dysku usunie lokalną sesję. Każda instancja jest rozliczana niezależnie i działa przez zakupiony czas. Wywołania REST / MCP nie są dodatkowo rozliczane za wiadomość, a rzeczywista cena zależy od strony pakietu. Obecnie domyślnie odwołuje się do pakietu czasu trwania robota WeChat, a przed ostatecznym udostępnieniem należy potwierdzić wycenę w połączeniu z zasobami operacyjnymi.API i MCP
Użyj adresu API instancji na stronie zarządzania, wszystkie interfejsy konta przekazująAuthorization: Bearer <token API instancji>. Te ścieżki należą do dedykowanej instancji, a nie do współdzielonej bramy API. Adres MCP to adres instancji z dodanym /mcp/, używający tego samego tokenu Bearer.
Treść wysyłania zawiera
target, type: "text" oraz text. target akceptuje ID konwersacji, ID kontaktu, ID użytkownika firmowego lub unikalną pełną nazwę; preferowane jest używanie ID; gdy wyświetlana nazwa nadal nie może jednoznacznie wskazać obiektu, instancja odrzuci operację i nie będzie zgadywać obiektu. Kontakt bez lokalnej konwersacji najpierw otworzy konwersację przez klienta, a następnie wyśle wiadomość po sprawdzeniu rzeczywistego ID konwersacji. Nagłówek żądania Idempotency-Key składa się z 8–128 liter, cyfr lub _.:-. Powtórzone żądania tej samej operacji muszą ponownie używać tego samego klucza i tej samej treści żądania.
Zastąpienie target tablicą targets pozwala wysyłać seryjnie do 1–50 jednoznacznie określonych celów. Nie można podawać obu jednocześnie. Wszystkie cele najpierw kończą rozpoznanie tożsamości, a różne aliasy wskazujące ten sam obiekt zostaną odrzucone. Po niepowodzeniu jednego celu kolejne wysyłanie zostaje zatrzymane, a wynik zadania rejestruje dla każdego elementu succeeded, failed, unknown lub not_attempted; nie należy traktować częściowego sukcesu jako pełnego sukcesu. Ten proces nadal wymaga prawdziwego odbioru określonych kontaktów w środowisku wdrożeniowym.
Zadania mogą znajdować się w stanie queued, running, submitting, succeeded, failed, unknown lub cancelled. succeeded oznacza, że po przesłaniu w rekordzie odpowiedniej konwersacji znaleziono dokładny tekst i ID wiadomości serwera, delivered nadal ma wartość null i nie oznacza, że druga strona ją otrzymała. unknown oznacza, że wynik jest niejednoznaczny, sprawdź historię i nie powtarzaj wysyłania z nowym kluczem. Instancja nie ponawia automatycznie przerwanych zadań.
Historia zawiera tylko treści, które klient już zsynchronizował, i nie może gwarantować pełnej historii. Wiadomości nietekstowe mogą zwracać typ unknown, a pobieranie załączników nie jest jeszcze dostępne. Zdarzenia zachowują ostatnie 10 000 wpisów, gap oznacza, że kursor przekroczył okno retencji. Pierwsze połączenie nie odtworzy starej historii jako nowych wiadomości.
server_accepted i server_id w historii wiadomości mogą służyć do sprawdzenia, czy serwer zaakceptował lokalną wiadomość; jeśli istnieje tylko lokalny rekord bez ID serwera, nie można uznać wysyłania za udane. Te pola nie oznaczają, że odbiorca otrzymał lub przeczytał wiadomość. Rekordy zdarzeń zachowują stan w chwili wygenerowania, aby sprawdzić bieżący stan potwierdzenia, należy użyć interfejsu historii wiadomości.