/api/capabilities.
Distribution och inloggning
Aktivera tjänsten i kategorin Deployment och välj ett instanspaket med tidsperiod. Efter distributionen öppnar du administrationssidan och skannar QR-koden med WeCom för själva kontot; om mobilbekräftelse eller andra inloggningssteg krävs öppnar du fjärrskrivbordet och anger skrivbordslösenordet för den instansen. API-autentiseringsuppgifter och skrivbordslösenord är separata. Inloggningsdata sparas på instansdisken; om behållaren återskapas bevaras disken; om disken tas bort raderas den lokala sessionen. Varje instans debiteras separat och körs under den köpta tidsperioden. REST-/MCP-anrop debiteras inte separat per meddelande, och det faktiska priset gäller enligt paketsidan. För närvarande används som standard tidsperiodspaket för WeChat-robotar som referens, och prissättningen behöver slutligt bekräftas utifrån körresurserna innan offentlig lansering.API och MCP
Använd instansens API-adress på administrationssidan och inkluderaAuthorization: Bearer <instansens API-token> i alla kontoanrop. Dessa sökvägar tillhör den dedikerade instansen och är inte en delad API-gateway. MCP-adressen är instansadressen med /mcp/ tillagd och använder samma Bearer-token.
Sändningskroppen innehåller
target, type: "text" och text. target accepterar konversations-ID, kontakt-ID, företagsanvändar-ID eller ett unikt fullständigt namn; använd ID i första hand; om visningsnamnet fortfarande inte kan identifiera ett mål unikt avvisar instansen åtgärden och gissar inte objektet. För kontakter utan lokal konversation öppnas först konversationen via klienten, och meddelandet skickas efter att det faktiska konversations-ID:t har kontrollerats. Begärandehuvudet Idempotency-Key består av 8–128 bokstäver, siffror eller _.:-. Upprepade begäranden för samma åtgärd måste återanvända samma nyckel och samma begärandekropp.
Genom att ersätta target med arrayen targets kan du skicka seriellt till 1–50 uttryckligen angivna mål. Båda kan inte anges samtidigt. Alla mål slutför identitetsupplösning först, och olika alias som pekar på samma objekt avvisas. Efter att ett mål misslyckas stoppas efterföljande sändningar, och uppgiftsresultatet registrerar per objekt succeeded, failed, unknown eller not_attempted; behandla inte partiell framgång som fullständig framgång. Detta flöde behöver även slutföra verklig acceptanstestning av angivna kontakter i distributionsmiljön.
Uppgifter kan vara i tillstånden queued, running, submitting, succeeded, failed, unknown eller cancelled. succeeded betyder att exakt text och servermeddelande-ID hittades i motsvarande konversationspost efter inskickning, delivered är fortfarande null och betyder inte att motparten har mottagit det. unknown betyder att resultatet är oklart; kontrollera historiken och upprepa inte sändningen med en ny nyckel. Instansen skickar inte automatiskt om avbrutna uppgifter.
Historiken innehåller endast innehåll som klienten redan har synkroniserat och kan inte garantera fullständig historik. Icke-textmeddelanden kan returnera typen unknown, och nedladdning av bilagor är ännu inte tillgänglig. Händelser behåller de senaste 10 000 posterna, och gap betyder att markören redan har överskridit bevarandefönstret. Den första anslutningen spelar inte upp gammal historik som nya meddelanden.
server_accepted och server_id i meddelandehistoriken kan användas för att kontrollera om servern har accepterat det lokala meddelandet; om endast en lokal post visas utan server-ID kan sändningen inte anses lyckad. Dessa fält betyder inte att mottagaren har tagit emot eller läst meddelandet. Händelseposter bevarar statusen vid tidpunkten då de skapades; använd meddelandehistorikens gränssnitt för att fråga aktuell bekräftelsestatus.