Documentation Index
Fetch the complete documentation index at: /llms.txt
Use this file to discover all available pages before exploring further.
DingTalk pushes subscribed callback events to your app, such as Contacts changes and App authorization changes. Developers can synchronize data in real time to better integrate their business systems.
| RDS Push | HTTP Push |
|---|---|
| Supports the synchronization protocol, ensuring that data is reliably written to the developer’s RDS. If the developer’s RDS fails, the data is permanently stored in DingTalk. | Does not support the synchronization protocol. Data loss may occur when the network is abnormal or the developer’s service fails. |
| Pushes the final state of the business data, so developers can use the data pushed by DingTalk Cloud directly. This also reduces the number of calls developers make to the DingTalk Open Platform, avoiding throttling limits. | Pushes the business ID. After receiving the push, developers still need to call DingTalk Open Platform APIs to query the final state of the data, which is prone to throttling limits. |
| Pushes data at different rates based on the RDS specifications and capabilities of the developer receiving the push. | Push can create instantaneous peaks in HTTP requests, which may increase the load on the developer’s server and cause it to crash. |
| The pushed data is in plaintext, requiring no signature verification or encryption/decryption logic. | The pushed data is in ciphertext, requiring developers to verify signatures and perform encryption/decryption on their own, and to implement signature verification and encryption/decryption logic in different programming languages. |
| The data channel is an internal network channel with no traffic costs, high security level, and high efficiency. | The data channel is a public network channel with traffic costs, a low security level, and low efficiency. |
| Development Stage | RDS Push | HTTP Push |
|---|---|---|
| Create an app/suite | Developers need to set up an RDS instance for receiving pushes (during the development stage, any MySQL instance with a public IP can be used). | Developers need to prepare a program with a public address to verify pushes. (For official launch, the program must be deployed on DingTalk Cloud.) |
| Organization authorizes and activates the app/suite | Developers need to implement functionality that polls and reads the pushed database table to obtain the authorization information of the organizations that have activated the app. The process is short and issues are easy to troubleshoot. | Developers need to implement the following four functions: 1) Receive the temporary authorization code push, 2) Exchange the temporary authorization code for a permanent authorization code, 3) Activate the app, and 4) Obtain the authorization information of the organizations that have activated the app. The process is long and issues are hard to troubleshoot. |
| Monitor real-time data changes of organizations | Developers need to select the data to monitor on the app/suite details page, then poll and read the database table that receives the pushes. A single action, simple to perform. | Developers need to register a monitoring address for each organization. After receiving a push, they must query the DingTalk Open Platform again to obtain the final data. This requires multiple API calls and makes API debugging complex. |
Was this page helpful?
Developer Guide