# Service API Call Instructions
This document describes how to invoke the Service Account API.
# Get AppID and AppSecret
WeChat The developer platform has support for managing Service Account basic information, development information, and binding and authorization relationships.
The operation path is: "WeChat developer platform - scan code login - my business - Service Account," click to enter the service number management page
Where developers can directly modify the configuration of AppSecret, API IP whitelist information, JS interface security domain name and message push
# AppSecret Management
Supports activation, reset, freezing, and defrosting operations; The freezing and defrosting operation takes 10 minutes before it can take effect.
If there is no use of AppSecret for a long time, developers can use the administrator account to log into the public platform, and freeze the AppSeceret in the "Settings and Development - Basic Configuration" to improve the security of the account.
After the AppSecret freeze, developers cannot use AppSecret to obtain Access tokens (interface returns error code 40243), which does not affect the normal use of the basic functions of the account, does not impact the call of the backend interface through third party authorization, and does not influence cloud development to call the backend Interface.
Developers can log in to the public platform at any time using the administrator account and unfreeze AppSecret in "Settings and Development - Basic Configuration."
If the secret is frozen, calling getAccessToken will get 40243 error
"WeChat cloud hosting" has the ability to call WeChat open service interface without authentication, free of keys, and no information is exposed throughout the process.Developers do not need to maintain access_token because the legality determination of interface requests is fully implemented by WeChat cloud hosting, which is linked to WeChat, by going to the cloud hosting document .(If you use a cloud-hosted cloud call, you don't need to generate the Access Token process afterwards, and you don't need to configure the IP whitelisting)
# IP whitelisting
That is, an IP in the whitelist can only call the fetch interface to call the credentials interface or the secured version interface to call a credentials interface, otherwise a 61004 error will be prompted
# Generate Access Token
Refer to for the interface invocation credentials Interface or for the stable interface invocation credentials Enter theAppID
andAppSecret
that were obtained in the previous step to obtain Access Tokens. Both can be obtained normally. Use the stable version interface.
The acquired AccessToken can be used in calls to the service API .
Here are some notes:
- access_token The validity period is currently 2 hours and needs to be refreshed regularly. Repeated acquisition will cause the last access_token to be invalid.Recommendations Service Account Developers use a control server to retrieve and refresh access tokens uniformly. Access tokens used by other business logic servers come from this control server and should not be refreshed separately, otherwise it is easy to create conflicts, resulting in access token coverage and affecting the business;
- The current validity of access_token is communicated by returning expires_in, which is currently within 7200 seconds.The controller needs to refresh the new access_token in advance according to this valid time. During the refresh process, the control server can continue to output the old access token externally, at this time the public platform backend will ensure that both the new and old access tokens are available within 5 minutes, which ensures a smooth transition for third party business;
- The effective time of access_token may be adjusted in the future, so the central control server not only needs internal timing active refresh,You also need to provide an interface to passively refresh access_token so that the business server can trigger the refresh process of access_token if the API call learns that access_token has timed out.
- access_token is the globally unique interface invocation credential of Service Account. Access_token is used by the service number to invoke each interface.Developers need to preserve it properly.
- The access_token storage must retain at least 512 characters.
Here is a simple access_token storage and usage scenario:
- The controller calls the WeChat api at regular intervals (1 hour recommended), refreshes access_token, and stores the new access_token;
- The server gets access_token from mysql (or other storage) every time it calls the WeChat api, and can be cached in memory for a period of time (1 minute recommended);
For calls that may be at risk, enter the risk call confirmation process when the developer obtains the access_token call, and the user administrator needs to confirm it before it can be successfully obtained.The process is as follows:
- The developer made the call over an IP - > Platform returns an error code[89503]At the same time, the template message is sent to Service Account administrator - > service number administrator to confirm that the IP can be called - > the developer uses the IP to initiate the call again - > the call is successful.
- If Service Account administrators reject the IP call for the first time, the user will not be able to initiate a call again using the IP within 1 hour. If the service number administrator rejects the IP call several times, the IP may not be allowed to initiate the call for a long time.The platform recommends that the developer actively communicate with the administrator to confirm the call requirement before initiating the call, or request the administrator to open the IP whitelisting function and add the IP to the IP whitelisting list.
Service Account When calling each interface, the correct result is generally obtained, and the specific result can be seen in the explaination of the corresponding interface;When an error is returned, you can query the cause of the error based on the return code. The explanation of the return code is generally described in the documentation of the individual interfaces. If there is no specific description, you can refer directly to global return code
# Interface domain names
Developers can choose the best access domain name (with lower latency and higher stability) based on their server deployment.
In addition, other access domains can be used for disaster tolerance purposes, and consider choosing alternate domains for access when network links fail. Ask the developer to use the domain name for the API interface request, do not use IP for access.If you need to open a network policy, developers can get the server IP address interface WeChat from to get the latest IP information on a regular basis.
- Generic domain name (api.weixin.qq.com), using which will access the nearest access point designated by the official;
- Universal remote disaster recovery domain name (api2.weixin.qq.com), when the above domain name is not accessible, you can change to access this domain name;
- Shanghai domain name (sh.api.weixin.qq.com), using which will access access points in Shanghai;
- Shenzhen domain name (sz.api.weixin.qq.com), the use of which will access access points in Shenzhen;
- Hong Kong domain name (hk.api.weixin.qq.com). Using this domain name will access access points in Hong Kong.
# Interface frequency limit
Service Account The invocation interface is not unlimited.In order to prevent a WeChat server load exception from being caused by a service number's program errors, by default, each service number cannot call the interface beyond a certain limit, as specified in the interface limitation instructions
# Problem sweep
If you have problems calling the interface, refer to the Interface Alarm and Troubleshooting Guidelines
You can also post questions on WeChat Open Community