Skip to main content

​
Triggering Conditions

To prevent abnormal YiDA server load caused by application errors, each YiDA Server API endpoint has a different default rate limit based on its complexity (for details, send the API document link to technical support). Exceeding the limit on any dimension may trigger a rate limit. Common response error codes: failure.operation.requestTooFast and failure.operation.tooManyVisitors.
  • Single-app QPS rate limit: For each app, calls to a given endpoint that exceed the maximum frequency trigger a rate limit.
  • Single-organization QPS rate limit: For each organization, calls to a given endpoint that exceed the maximum frequency trigger a rate limit.
  • Global QPS rate limit per endpoint: Because of YiDA endpoint security protection policies, the call count per second is capped. When all YiDA organization apps together call an endpoint more times per second than its per-second limit, a response error is triggered.
Solutions
  • General: Since the QPS rate limit window is 1 second, when you hit a rate limit error, sleep for 1 second in your program, then Continue execution.
  • Off-peak strategy: For programs that call YiDA APIs on a schedule, avoid peak times on the hour. For example, schedule execution at 10 minutes past the hour.

​
FAQ

A: No, they are not double-charged. Details are as follows:YiDA-related business API calls fall into 2 usage scenarios:
  1. YiDA acts as a SaaS app and calls DingTalk endpoints through productized features (that is, YiDA official connectors, such as fetching DingTalk attendance data). These calls are not subject to the policy limits.
  2. The customer builds an internal app on the DingTalk Open Platform and directly calls the content in the [YiDA endpoint list] from their own external system (for example, the customer’s own system calls the YiDA openAPI endpoints to sync app data built in YiDA to the customer’s own system). These calls follow the unified policy of the DingTalk Open Platform.
A: No, they do not consume the DingTalk Open Platform call count, because YiDA-related business API calls are not subject to the policy limits.
  1. Scenario 1: YiDA acts as a SaaS app and calls DingTalk endpoints through productized features (that is, YiDA official connectors, such as fetching DingTalk attendance data). These calls are not subject to the policy limits.
A: The QPS limits published by the DingTalk Open Platform distinguish between internal apps and third-party enterprise apps. YiDA, as a third-party enterprise app, is also subject to QPS limits. For each DingTalk endpoint that YiDA itself calls, the maximum frequency is 40 calls/second. For details, see rate limit.
A: Since YiDA-related business API calls are not subject to the policy limits, regardless of which DingTalk edition a YiDA customer purchases, the QPS standard is a maximum frequency of 40 calls/second.
  1. Scenario 1: YiDA acts as a SaaS app and calls DingTalk endpoints through productized features (that is, YiDA official connectors, such as fetching DingTalk attendance data). These calls are not subject to the policy limits.
A: Except for the Dedicated edition, customers cannot currently expand capacity individually.