API Rate Limiting Most 429 responses from legitimate API requests are due to time limits, not rate limits. See API Time Limiting, which also compares the three different reasons a request can be refused and what each one means for your integration. The response headers will tell you which one you are encountering. The limits on this page are counts of calls to particular endpoints rather than a measure of how much processing you have used, so hitting one does not mean you are anywhere near your API time limit — the two are separate, and neither is affected by the other. However a few APIs also have rate limits. Rate-limiting serves two purposes: 1.SecurityLimits things like Login, UpdatePassword, etc. to prevent brute force attacks by unauthenticated hackers. Programmatic use may be limited if used improperly.2.Abusive use of costly functionalityVarious AI features impose per-user limits here to limit very expensive backend service use to a reasonable level. These requests were never intended for programmatic use anyway. Limits are partitioned by API or functionality, so sometimes APIs will share limit partitions and sometimes they will have their own partition. For cases where the caller has already authenticated, the rate limiting is done based on the authenticated user account invoking the API. For unauthenticated access (for APIs like VerifyUserEmail, RedeemCommandToken, and several undocumented functions), the rate limiting is done based on the calling IP address. In the case of authentication calls where the user isn't authenticated, but a specific user was specified, the rate limiting may be done on the calling IP address, the specified user account, or both. For example, Login has both an overall limit to prevent account harvesting and brute force account compromise, as well as per-target-account limiting to protect any specific account from brute force password guessing. For security reasons, and because they're subject to immediate change in response to security and availability issues, the specific APIs that are rate-limited and their limits are not documented here. However, if you encounter Rate Limiting, you will know the current limit because it's in the response headers. The following headers will be included in the response for calls that are affected by rate limiting: HeaderDescriptionX-RateLimitThe number of calls to this endpoint per 5-minute time period that are allowed.X-RateLimit-RemainingThe number of calls to this endpoint that are remaining for this 5-minute time period.X-RateLimit-ResetThe number of seconds until the rate limit window ends and more requests to the endpoint are allowed.Retry-AfterThis is a standard HTTP response header indicating how many seconds the caller should wait before attempting the request again. This value will be accurate for the first limited response, but for subsequent limited responses, the server has no way of knowing how much time the previously-rejected requests will consume when they are retried, so it is a guess by the server on when this request might be able to run, assuming that the caller will re-execute previously-rejected requests before this one, and assuming that they consume the default charge of 100ms. If those calls actually use more than the default charge, this number will be too low. If those calls use less than the default charge, this number will be too high. When the limit threshold is reached, all subsequent requests to that API within the time window will be rejected in the following way: 429 Too Many Requests ... Retry-After: 8 X-RateLimit-Limit: 50 X-RateLimit-Remaining: 0 X-RateLimit-Reset: 284 ... The Retry-After time indicated in the response indicates the approximate time (in seconds) when the request could be processed if no other requests are successfully processed between now and then. The correct client behavior is to pause sending all requests for that API and wait for at least the indicated time period before retrying. Again, be careful not to confuse rate limiting and its responses for time limiting and its responses. Both use 429 Too Many Requests and Retry-After header, but the other headers differ and they will have different messages. See API Time Limiting. See Http Response Status Codes for basic error retry guidance and algorithms.