/api/capabilities.
Розгортання та вхід
У категорії Deployment відкрийте сервіс і виберіть тариф тривалості екземпляра. Після розгортання відкрийте сторінку керування та відскануйте QR-код корпоративного WeChat обліковим записом власника; якщо потрібне підтвердження на телефоні або інші кроки входу, відкрийте віддалений робочий стіл і введіть пароль робочого столу цього екземпляра. Облікові дані API та пароль робочого столу є незалежними. Дані входу зберігаються на диску екземпляра; при перебудові контейнера диск зберігається; видалення диска видалить локальний сеанс. Кожен екземпляр оплачується окремо та працює відповідно до придбаної тривалості. Виклики REST / MCP не оплачуються окремо за повідомлення, фактична ціна визначається сторінкою тарифу. Наразі за замовчуванням використовується довідковий тариф тривалості для WeChat-бота, перед остаточним відкриттям необхідно підтвердити ціноутворення з урахуванням ресурсів виконання.API та MCP
Використовуйте API-адресу екземпляра зі сторінки керування, усі інтерфейси облікового запису передаютьAuthorization: Bearer <токен API екземпляра>. Ці шляхи належать спеціальному екземпляру, а не спільному API-шлюзу. Адреса MCP — це адреса екземпляра з додаванням /mcp/, використовується той самий Bearer token.
Тіло надсилання містить
target, type: "text" і text. target приймає ID чату, ID контакту, ID користувача підприємства або унікальне повне ім’я; переважно використовувати ID; якщо відображуване ім’я все ще не може однозначно визначити об’єкт, екземпляр відхилить операцію і не буде вгадувати об’єкт. Контакти без локального чату спочатку відкриють чат через клієнт і після перевірки фактичного ID чату виконають надсилання. Заголовок запиту Idempotency-Key містить 8–128 символів: літери, цифри або _.:-. Повторні запити однієї операції повинні використовувати той самий ключ і те саме тіло запиту.
Заміна target на масив targets дозволяє послідовне надсилання 1–50 чітко визначеним цілям. Обидва параметри не можна надавати одночасно. Усі цілі спочатку проходять ідентифікаційний аналіз, різні псевдоніми, що вказують на один об’єкт, будуть відхилені. Якщо одна з цілей не вдається, подальше надсилання припиняється, результати завдання записуються окремо як succeeded, failed, unknown або not_attempted; не вважайте частковий успіх повним успіхом. Цей процес також має пройти реальну перевірку в середовищі розгортання для визначених контактів.
Завдання можуть перебувати у стані queued, running, submitting, succeeded, failed, unknown або cancelled. succeeded означає, що після надсилання було знайдено точний текст у відповідному чаті та ID повідомлення сервера, delivered все ще має значення null і не означає, що інша сторона отримала повідомлення. unknown означає, що результат невизначений, перевірте історію записів і не надсилайте повторно з новим ключем. Екземпляр не буде автоматично повторно надсилати перервані завдання.
Історія містить лише вміст, який уже синхронізував клієнт, і не може гарантувати повну історію. Нетекстові повідомлення можуть повертатися з типом unknown, завантаження вкладень ще не відкрите. Події зберігають останні 10 000 записів, gap означає, що курсор перевищив вікно збереження. Під час першого підключення стара історія не буде повторно відтворюватися як нові повідомлення.
server_accepted і server_id в історії повідомлень можна використовувати для перевірки, чи прийняв сервер локальне повідомлення; якщо є лише локальний запис без ID сервера, не можна вважати надсилання успішним. Ці поля не означають, що одержувач отримав або прочитав повідомлення. Записи подій зберігають стан на момент створення, для запиту поточного підтвердженого стану слід використовувати інтерфейс історії повідомлень.