> ## Documentation Index > Fetch the complete documentation index at: https://docs.acedata.cloud/llms.txt > Use this file to discover all available pages before exploring further. # Robô do WeCom > Platform API guide - Ace Data Cloud Implante sua própria instância de conta do WeCom, use o WeCom no celular para fazer login por código QR e leia contas, contatos, conversas e mensagens sincronizadas localmente por REST API ou MCP. A instância corresponde a uma conta comum do WeCom, sem necessidade de servidor privatizado ou configuração de domínio de e-mail corporativo. Atualmente está em Alpha. A leitura da conta concluiu a validação em conversas reais; o envio de texto pelo próprio usuário e a leitura de retorno de eventos concluíram a aceitação real; as operações com outros contatos, grupos e a recuperação de novas instâncias ainda precisam concluir a aceitação no ambiente de implantação. Envio de mídia, resposta com citação, @ real, gerenciamento de membros de grupo e confirmação de entrega ainda não estão disponíveis. Consulte o valor retornado por `/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 incluir `Authorization: Bearer `. 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. | Interface | Função | | - | - | | `GET /api/status`、`GET /api/auth/status` | Se a conta está pronta e a lista de capacidades | | `GET /api/auth/qr` | PNG Base64 do código QR de login atual | | `GET /api/account` | Conta atual | | `GET /api/contacts?kind=all` | Colegas internos e contatos externos; é possível especificar internal / external | | `GET /api/conversations` | Conversas locais, preservando o ID original da conversa | | `GET /api/messages` | Mensagens sincronizadas localmente; parâmetros conversation\_id, after\_rowid e limit | | `POST /api/search` | Pesquisa de contatos, conversas e texto local | | `POST /api/messages` | Tarefa assíncrona de envio de texto; é obrigatório fornecer Idempotency-Key | | `POST /api/messages/send` | A mesma entrada de envio, com suporte para um ou vários destinos | | `GET /api/groups/{conversation_id}` | Informações e membros de grupos sincronizados localmente | | `GET /api/tasks` | Tarefas recentes e resultados de cada destino | | `GET /api/tasks/{id}` | Consultar o resultado do envio | | `POST /api/tasks/{id}/cancel` | Cancelar tarefas que ainda não foram iniciadas | | `POST /api/runtime/pause`、`POST /api/runtime/resume` | Pausar a automação; retomar após validação pelo próprio usuário | | `GET /api/diagnostics`、`GET /api/diagnostics/screenshot` | Estado da instância e tela atual; ambos exigem autenticação | | `GET /api/events?after=0` | Eventos de mensagem com cursor recuperável | | `WS /ws` | Fluxo de eventos de mensagem, autenticação 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. ## Conta e credenciais Faça login apenas em contas que você tenha autorização para operar. Configure o token da API em aplicações confiáveis; ele pode acessar os dados da conta dessa instância. Não publique senhas, códigos QR ou capturas de tela de conversas em locais públicos. Pausar a instância interromperá os eventos em tempo real. Após sair da conta ou remover o dispositivo no celular, será necessário fazer login novamente. A entrada de texto atual suporta apenas uma única linha; quebras de linha serão explicitamente recusadas antes do envio. Quando o cliente exigir verificação de segurança ou novo login, o próprio titular da conta deverá concluí-los na área de trabalho remota; a instância não contornará a verificação. Tarefas após uma interrupção de verificação podem retornar unknown; consulte primeiro os registros de mensagens e não reenvie com uma nova chave de idempotência. Ao detectar um aviso de verificação de segurança, saída ou alteração da conta, a fila de automação será pausada de forma persistente. Após concluir a verificação no celular, é possível continuar as tarefas ainda não executadas por meio de “Retomar após verificação” no console da instância; tarefas já enviadas, mas com resultado incerto, não serão reenviadas. O trabalho remoto normal também pode acionar a verificação de segurança do WeCom. A janela de 24 horas sem novo bloqueio após a verificação, informada oficialmente, não significa que a detecção foi eliminada, nem significa que a instância pode garantir operação não supervisionada de longo prazo. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.