/api/capabilities.
Deployment and Login
Enable the service under the Deployment category and select an instance duration plan. After deployment, open the management page and use the account owner’s WeCom to scan and log in; if mobile confirmation or other login steps are required, open the remote desktop and enter the desktop password of that instance. API credentials and desktop passwords are independent. Login data is saved on the instance disk; rebuilding the container retains the disk; deleting the disk deletes the local session. Each instance is billed independently and runs according to the purchased duration. REST / MCP calls are not additionally billed per message; actual pricing is subject to the plan page. The current default reference is the duration plan for WeChat bots; pricing confirmation still needs to be completed based on runtime resources before final availability.API and MCP
Use the instance API address in the management page, and carryAuthorization: Bearer <instance API token> for all account interfaces. These paths belong to dedicated instances, not a shared API gateway. The MCP address is the instance address plus /mcp/, using the same Bearer token.
The sending body contains
target, type: "text", and text. target accepts a conversation ID, contact ID, enterprise user ID, or unique full name; IDs are preferred; when display names still cannot uniquely identify an object, the instance will reject the operation and will not guess the target. Contacts without local conversations will first have a conversation opened through the client, and the message will be sent after verifying the actual conversation ID. The request header Idempotency-Key consists of 8–128 letters, numbers, or _.:-. Repeated requests for the same operation must reuse the same key and the same request body.
Replacing target with a targets array can send serially to 1–50 explicitly specified targets. The two cannot be provided at the same time. All targets complete identity resolution first, and different aliases pointing to the same object will be rejected. Subsequent sending stops after one target fails, and task results record succeeded, failed, unknown, or not_attempted item by item; do not treat partial success as complete success. This process also needs to complete real acceptance for specified contacts in the deployment environment.
Tasks may be in queued, running, submitting, succeeded, failed, unknown, or cancelled states. succeeded means that, after submission, the exact text and server message ID were found in the corresponding conversation record; delivered remains null and does not mean the other party has received it. unknown means the result is unclear; please check the history record and do not resend with a new key. The instance will not automatically retry interrupted tasks.
History only includes content already synchronized by the client and cannot guarantee the complete history. Non-text messages may return an unknown type, and attachment downloads are not yet available. Events retain the most recent 10,000 entries; gap means the cursor has exceeded the retention window. The first connection will not replay old history as new messages.
server_accepted and server_id in message history can be used to verify whether the server has accepted a local message; when only a local record appears without a server ID, sending cannot be considered successful. These fields do not mean the recipient has received or read it. Event records retain the status at the time of generation; use the message history interface to query the current confirmation status.