/api/capabilities.
Развертывание и вход
В категории Deployment подключите сервис и выберите пакет длительности экземпляра. После развертывания откройте страницу управления и отсканируйте QR-код корпоративного WeChat с аккаунта владельца; если требуется подтверждение на телефоне или другие шаги входа, откройте удалённый рабочий стол и введите пароль рабочего стола этого экземпляра. Учётные данные API и пароль рабочего стола независимы. Данные входа сохраняются на диске экземпляра, при пересоздании контейнера диск сохраняется; удаление диска удалит локальную сессию. Каждый экземпляр оплачивается отдельно и работает в течение приобретённого срока. Вызовы REST / MCP не тарифицируются отдельно за сообщения, фактическая цена определяется страницей пакета. В настоящее время по умолчанию используется тариф по длительности для бота WeChat в качестве ориентира; перед окончательным открытием необходимо подтвердить ценообразование с учётом используемых ресурсов.API и MCP
Используйте адрес API экземпляра на странице управления, все интерфейсы аккаунта передаютAuthorization: Bearer <API token экземпляра>. Эти пути относятся к выделенному экземпляру, а не к общему шлюзу 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, отправку нельзя считать успешной. Эти поля не означают, что получатель получил или прочитал сообщение. Записи событий сохраняют состояние на момент создания, для запроса текущего состояния подтверждения следует использовать интерфейс истории сообщений.