Skip to main content

​
Best Practices for Efficient Resource Usage

In some business scenarios, an app feature can be implemented either by calling an Open API or by listening for event pushes. For example, to obtain change information about users added to a group chat, you can poll an Open API or listen for event pushes and trigger the corresponding action only when needed. Consider the following factors to make the most suitable choice.
  • Real-time requirements—If your app needs to obtain data or process events in real time, event subscription may be the better choice.
  • Data update frequency—If data updates frequently and consumes more resources, event subscription may be the better choice. If you only need to obtain data on a schedule or occasionally, calling an Open API may be the better choice.
  • Integration complexity—If the feature you are developing is complex and requires calling multiple Open APIs, development costs increase. Consider whether integrating event pushes can reduce development effort.
  • Volume of data retrieved—If a single retrieval returns a large amount of data, event pushes may be the better choice. Calling an Open API consumes network bandwidth and server resources. If your app calls Open APIs frequently, it may affect system performance and resource consumption, whereas event pushes can reduce resource consumption.

​
Best Practices for Optimizing Event Push Resources

The DingTalk Open Platform provides event pushes, which allow developers to receive real-time notifications when specific events occur. However, subscribing to too many events or processing too many message notifications can degrade app performance and increase resource consumption.
  • Subscribe to necessary events only—Identify the events your app truly needs, avoid subscribing to irrelevant event types, and reduce the number of subscribed events.
  • Deduplicate events in your business logic—In some cases, a business event callback may receive duplicate events. Developers should handle events with the same eventId idempotently.
  • Respond quickly—The DingTalk Open Platform push timeout is 2.5s (HTTP mode) / 3s (Stream mode). We recommend processing messages promptly and returning a correct response in real time to avoid a timeout being returned to the DingTalk Open Platform, thereby reducing the frequency of timeout retries.

​
Usage Control for Group Bot Webhooks

Two group Webhook bot scenarios are currently supported for usage control:

​
Procedure

  1. Go to the Developer Console > Resource Management, scroll to the Webhook & Stream Usage card, and click Usage Control.
  2. You can set group bot Webhook limits in the Usage Control dialog. Note When setting usage control, choose Global Limit or Targeted Limit based on your actual needs. For details about the two limit types, see the descriptions below.

​
Descriptions

  • [Global Limit]—Once set, all “internal bot Webhooks in group chats” and “group custom bot Webhooks” are uniformly limited, with usage limited per individual bot.
    • Scenario: Members frequently create group Webhook bots in chats on their own, consuming the organization’s Webhook quota, and you want to control this.
    • Solution: Set a global limit so that every Webhook bot created in a group chat can make at most 100 calls per month, resolving the lack of control.
  • [Targeted Limit]—Allows you to set dedicated limit rules for specific bots. Once set, these rules override the global limit configuration.
    • Scenario: After the global limit restricts other members’ bots, some group bots built by IT need to exceed the usage limit.
    • Solution: Set a targeted limit. Select the custom Webhook bots that IT built in group chats and set them to unlimited (or set a large quota).