What is happening?
In early February, 2021 - Zuora is introducing new tenant-level rate limits across our platform on all Zuora Billing API, UI and Authentication requests.
Why are new rate limits being introduced?
This new policy ensures tenant level equity of access across Zuora and prevents single tenants from overloading or monopolizing Zuora systems. The vast majority of customers will not be impacted by these new limits as they are set very high as a protection mechanism, and at a level necessary to ensure all customers have fair and equal access to Zuora Billing API, UI and Authentication resources.
What’s the difference between these new rate-limits and the existing Concurrency Rate Limits?
Concurrency rate limits are based on processing threads available to tenants of the Zuora Billing application, and the new limits are more of a high quota system which is designed to protect Zuora Systems from over consumption by a single source. Both systems will be used in parallel as our rate limiting systems.
Where can I find more information on this?
We have updated our concurrency and rate limiting documentation which can be found here
How will I know if I get limited by this new system?
Based on observation of our customer use-rates over the past several months, we believe very few customers will be impacted by this change. The most common scenario is likely to be against authentication type for customers not optimizing their authentication to Zuora. Requests over the stated limits will produce a very specific 429 HTTP response with additional information in the JSON response that details the overage values. See JSON output examples in Zuora Knowledge Center reference above.
What should I do if I’m impacted?
As outlined, we believe most customers will not be impacted by these new limits. However, below we have included some general recommendations of Zuora best practices when it comes to managing API and specifically authentication calls to Zuora.
- We strongly encourage customers to adopt best practice around re-using oAuth Tokens and zSession Authentication (SOAP login and REST /v1/connections) as designed until expired. oAuth token expiration is 1h and zSessions expiration is 20min to 8hrs depending on security settings. This ensures optimal use of Zuora Authentication resources
- All API integrations should consider using retry logic (ideally with back-off capability) for all Authentication APIs when 429 HTTP response is received to ensure customer-to-zuora business continuity with our API services.
- Zuora recommend against using embedded apiAccessKeyId/apiSecretAccessKey authentication for integrations running Zuora Billing APIs at scale as this can contribute to over-use of authentication resources.
If you have additional questions, please feel free to contact Zuora Support [email@example.com]
- rate limits