/api/capabilities da instância.
Implantação e login
Ative o serviço na categoria Deployment e selecione um plano de duração da instância. Após a implantação, abra a página de gerenciamento e use o WeCom da própria conta para escanear o código; se for necessária confirmação no celular ou outras etapas de login, abra a área de trabalho remota e insira a senha de desktop dessa instância. As credenciais da API e a senha de desktop são independentes. As informações de login são salvas no disco da instância; recriar o contêiner preserva o disco; excluir o disco excluirá a sessão local. Cada instância é cobrada separadamente e opera pela duração adquirida. Chamadas REST / MCP não são cobradas separadamente por mensagem; o preço real está sujeito à página do plano. Atualmente, o padrão de referência é o plano de duração do robô do WeChat; antes da disponibilidade final, é necessário confirmar a precificação com base nos recursos de operação.API e MCP
Use o endereço da API da instância na página de gerenciamento; todas as interfaces da conta devem incluirAuthorization: Bearer <token da API da instância>. Esses caminhos pertencem à instância exclusiva e não são um gateway de API compartilhado. O endereço MCP é o endereço da instância acrescido de /mcp/, usando o mesmo token Bearer.
O corpo do envio contém
target, type: "text" e text. target aceita ID de conversa, ID de contato, ID de usuário corporativo ou nome completo único; priorize IDs; quando o nome exibido ainda não puder identificar de forma única, a instância recusará a operação e não tentará adivinhar o objeto. Para contatos sem conversa local, a conversa será primeiro aberta pelo cliente, e o envio será realizado após verificar o ID real da conversa. O cabeçalho Idempotency-Key possui de 8 a 128 caracteres de letras, números ou _.:-. Solicitações repetidas para a mesma operação devem reutilizar a mesma chave e o mesmo corpo de solicitação.
Substitua target por um array targets para enviar em série a 1–50 destinos explicitamente especificados. Os dois não podem ser fornecidos ao mesmo tempo. Todos os destinos concluem primeiro a resolução de identidade; aliases diferentes que apontem para o mesmo objeto serão rejeitados. Após a falha de um destino, os envios subsequentes serão interrompidos, e o resultado da tarefa registrará para cada item succeeded, failed, unknown ou not_attempted; não trate sucesso parcial como sucesso total. Esse processo ainda precisa concluir a aceitação real dos contatos especificados no ambiente de implantação.
As tarefas podem estar em queued, running, submitting, succeeded, failed, unknown ou cancelled. succeeded indica que, após o envio, foram encontrados o texto exato e o ID de mensagem do servidor no registro da conversa correspondente; delivered continua sendo null, o que não significa que a outra parte recebeu. unknown indica que o resultado não está claro; verifique o histórico e não envie novamente com uma nova chave. A instância não reenviará automaticamente tarefas interrompidas.
O histórico contém apenas o conteúdo já sincronizado pelo cliente e não pode garantir todo o histórico. Mensagens não textuais podem retornar o tipo unknown, e o download de anexos ainda não está disponível. Os eventos retêm as 10.000 entradas mais recentes; gap indica que o cursor ultrapassou a janela de retenção. A primeira conexão não reproduzirá o histórico antigo como novas mensagens.
server_accepted e server_id no histórico de mensagens podem ser usados para verificar se o servidor aceitou a mensagem local; quando houver apenas um registro local sem ID do servidor, o envio não pode ser considerado bem-sucedido. Esses campos não indicam que o destinatário recebeu ou leu. Os registros de eventos preservam o estado no momento da geração; para consultar o estado de confirmação atual, use a interface de histórico de mensagens.