Open WeCom Development Knowledge Base

Problem

WeCom development involves many APIs and layered credential systems. Common failures are not basic HTTP mistakes, but treating access_token as freely refreshable, missing the 20-second WelcomeCode expiry, confusing follow_user with follow_info, or using self-built app credentials in an ISV flow. AI-generated code can also invent parameters or miss frequency, callback, and idempotency constraints.

How It Works

This skill organizes WeCom capabilities into an entry-level navigator and multiple sub-skill documents. When a request is received, it first identifies whether the scenario is a self-built enterprise app, an ISV delegated-development app, or a third-party marketplace app, then locates the relevant sub-skill, such as contacts, messages, CRM, approvals, WeChat Customer Service, JS-SDK, or ISV credentials. Before generating code, it reads the matching .md document and follows its API definitions, response shapes, rate limits, and Gotcha Guide. The workflow also treats wecom-core or wecom-isv-core as prerequisite context and requires handling access_token caching, errcode=-1 retries, 42001/40014 token refresh, HTTP timeouts, environment-based secrets, and log redaction.

Boundaries

It fits server-side WeCom integrations, CRM workflows, office apps, customer service systems, ISV and third-party app development, especially when the goal is to reduce API hallucination and cover edge cases. It does not replace official documentation or act as a runtime SDK; production security, auditing, and environment-specific behavior should still be validated against official sources and live systems.