钉钉发展了这么多年,接口架构经历了从旧版(RPC架构)到新版(POP架构/v1.0)的演进。
算上目前还能跑的,钉钉官方一共有 3 个 最主要的获取 Access Token 接口(2个常规企业内部应用,1个针对第三方服务商)。
看这一篇就够了!
🔑 1. 旧版企业内部应用获取 Token 接口(目前最兼容老接口)
这就是你刚才成功跑通的那个接口。虽然它是旧版的,但它是目前去叩老版通讯录 RPC 接口(比如 getbyunionid)最稳的门神 。
接口地址 :GET https://oapi.dingtalk.com/gettoken
请求参数 :appkey 和 appsecret(就是你拿到的 clientid 和 clientsecret)
- 完整
curl示例:
bash
curl --location --request GET 'https://oapi.dingtalk.com/gettoken?appkey=你的AppKey&appsecret=你的AppSecret'
返回格式 :
json
{
"errcode": 0,
"access_token": "00efb3cb0cd8368...",
"errmsg": "ok",
"expires_in": 7200
}
🔑 2. 新版(v1.0)企业内部应用获取 Token 接口(推荐用于新版API)
这是钉钉目前大力推广的新版统一授权接口,采用了标准的 POST 形式。如果你后续要全线使用新版待办(/v1.0/todo)或新版人事接口,建议用这个获取 。
接口地址 :POST https://api.dingtalk.com/v1.0/oauth2/accessToken
- 请求头 (Header) :
Content-Type: application/json - 完整
curl示例:
bash
curl --location --request POST 'https://api.dingtalk.com/v1.0/oauth2/accessToken' \
--header 'Content-Type: application/json' \
--data-raw '{
"appKey": "你的AppKey",
"appSecret": "你的AppSecret"
}'
返回格式 :
json
{
"accessToken": "6bxxxxxx_xxxx_xxxx_xxxx_xxxxxxxxxxxx",
"expireIn": 7200
}
🔑 3. 第三方企业应用(服务商应用)获取 Token 接口
如果你开发的不是自己企业内部用的应用,而是要上架到钉钉应用市场、卖给全天下企业用的第三方应用(ISV) ,你就不能用上面两个了。你必须用这个接口来获取第三方应用的凭证(suite_access_token)。
- 接口地址 :
POST https://api.dingtalk.com/v1.0/oauth2/suiteAccessToken - 请求头 (Header) :
Content-Type: application/json - 完整
curl示例:
bash
curl --location --request POST 'https://api.dingtalk.com/v1.0/oauth2/suiteAccessToken' \
--header 'Content-Type: application/json' \
--data-raw '{
"suiteKey": "你的SuiteKey",
"suiteSecret": "你的SuiteSecret",
"suiteTicket": "钉钉回调推送给你的Ticket"
}'
- 返回格式:
json
{
"suiteAccessToken": "7cxxxxxx_xxxx_xxxx_xxxx_xxxxxxxxxxxx",
"expireIn": 7200
}
💡 大佬总结的避坑指南
- 企业自建开发 :闭眼在 接口 1 和 接口 2 里面选。
新老Token别混用 :钉钉虽然在做兼容,但有时候用 接口2(新) 拿到的长 Token 去调用旧版的 topapi 接口(比如查 unionid),容易触发莫名的 40035 参数不合法 。所以调老接口用旧 Token,调新接口用新 Token 。
过期缓存 :所有的 Token 有效期都是 7200秒(2小时) 。老哥记得在自己的后台做一下 Redis 缓存,千万别每发一条待办就去现调一次获取 Token 接口,频繁调用会被钉钉网关直接限流(触发高频调用报错) 。