## Overview
Before an internal enterprise app calls any DingTalk server API, it must exchange its AppKey/AppSecret for an access_token via gettoken. The request is a GET with appkey and appsecret in the query string (both found on the app detail page of the DingTalk developer console). On success the API returns the token plus expires_in (7200 seconds); business calls then append access_token to the URL query.
### Steps
1. Create an internal app in the DingTalk open platform and note AppKey/AppSecret.
2. Grant the API permissions the integration needs (approval, contact read, ...) and configure the server egress IP whitelist.
3. Cache the token locally and refresh before expiry; re-fetching per call is wasteful and risks throttling.
### Response
Success: {"errcode":0,"errmsg":"ok","access_token":"xxxx","expires_in":7200}. A non-zero errcode comes with an errmsg to troubleshoot.
### New-generation gateway
DingTalk's newer APIs (api.dingtalk.com) obtain tokens via POST /v1.0/oauth2/accessToken (JSON body appKey/appSecret) and authenticate with the x-acs-dingtalk-access-token header, while legacy endpoints such as approval remain on the oapi domain. The Qeasy connector supports both gateways and picks by API version.
### Security
Treat AppSecret as a high-sensitivity credential: store it in the iPaaS secret vault, rotate periodically, and reset it in the console if leaked.
### Token stewardship
Keep one token cache per appkey in the integration runtime; if several workers refresh independently they race and overwrite each other's cached value. The token endpoint itself also has a per-app daily quota — excessive refreshes surface as throttling errors that look like credential problems but are not, so alert on refresh frequency, not just failures.