WeChat small program getAccessToken

May 19, 2021 WeChat Mini Program Development Document

auth.getAccessToken

This interface should be called on the server side, as detailed in the Service Side API.

Gets the credentials (or information) of the program's globally unique access_token. The vast majority of background interfaces need to be called using access_token, and developers need to keep them properly.

The request address

GET https://api.weixin.qq.com/cgi-bin/token?grant_type=client_credential&appid=APPID&secret=APPSECRET

Request parameters

Property	Type	Required	Description
grant_type	string	Is	Fill in client_credential
appid	string	Is	The unique credentials of the applet, the AppID, are available on the WeChat Public Platform - Settings - Development Settings page. (Need to have become a developer, and the account has no abnormal status)
secret	string	Is	The program's unique credential key, AppSecret, is obtained in the same way as the appid

Returns a value

Object

The returned JSON packet

Property	Type	Description
access_token	string	The credentials obtained
expires_in	number	Voucher valid time, in seconds. It is currently a value of 7200 seconds.
errcode	number	Error code
errmsg	string	Error message

Errcode's legitimate value

value	illustrate	Minimum version
-1	The system is busy, please developers will try again later.
0	Request success
40001	Appsecret error or AppSecret does not belong to this applet, ask the developer to confirm the correctness of AppSecret
40002	Make sure the GRANT_TYPE field value is Client_credential
40013	If you are not legal, please ask the developer to check the correctness of the AppID, avoid exception character, pay attention to the case

Returns a data example

Normal return

{"access_token":"ACCESS_TOKEN","expires_in":7200}

Return when the error is wrong

{"errcode":40013,"errmsg":"invalid appid"}

access_token and updates of the system

access_token store at least 512 characters of space;
access_token is currently valid for 2 hours and needs to be refreshed on a timed period, and repeated acquisition will invalidate the last access_token acquired;
It is recommended that developers use the central control server unified acquisition and refresh access_token, other business logic servers used by the access_token are from the central control server, should not be refreshed separately, otherwise it is easy to cause conflicts, resulting in access_token coverage and affect the business;
access_token validity is communicated by the returned expires_in, which is currently within 7200 seconds, and the central server needs to refresh in advance based on this valid time. In the refresh process, the central control server can continue to export the old access_token, at this time the public platform background will ensure that within 5 minutes, the old and new access_token are available, which ensures a smooth transition of third-party business;
The effective time of access_token may be adjusted in the future, so the central server not only needs to be actively refreshed internally, but also needs to provide an interface for passively refreshing access_token, which allows the business server to trigger the access_token refresh process if the API call learns that access_token has timed out.