DingTalk Office Automation Assistant

Problem Being Solved

DingTalk office automation often fails less because an API is unavailable and more because teams mix up entry points for work notices, group bots, approvals, and attendance. This skill is aimed at that confusion: sending work notices from an internal app, pushing alerts through a group-bot webhook, creating or querying approval instances, fetching attendance records, and tracing failures such as a wrong appkey, an unpublished app, or missing API permission.

How It Works

• Clarify the target first: separate work notices, group bots, approvals, and attendance so the wrong credential is not used on the wrong endpoint.
• Check credentials: self-built apps usually need appkey, appsecret, and agentId; group bots usually need only the webhook token; approvals and attendance depend on the relevant app permissions.
• Fetch and cache the token: use gettoken to obtain access_token; the source notes a roughly 7200-second validity window, which makes local caching practical.
• Call the matching OpenAPI: work notices use asyncsend_v2, group bots use robot/send, and approval or attendance flows use their respective topapi endpoints, then inspect error codes when calls fail.

Boundaries

It is best treated as an integration guide and calling skeleton, not as a service that holds credentials or calls real APIs on the user's behalf. AppSecret, bot tokens, and attendance or approval data containing employee information should be handled under enterprise compliance rules. Group pushes should respect DingTalk rate limits and anti-spam policies. Final behavior should follow the latest DingTalk Open Platform documentation and actual app authorization.