API Limits
Table of Contents
Credit System
API calls in Vertical Solutions are associated with credits. The credits are deducted from your credit count, based on the type of the API call that you make. Credit deduction is based upon the intensiveness of the performance, and the memory usage of the operations involved in the API calls.
Each API call made will result in a reduction of 1 credit. However, for some APIs, credit reduction would be different. For example, for a "Convert Lead API", 5 credits will be reduced for a single API call. Refer to the table below for more details.
Maximum credit limit in a 24-hour window for Vertical Solutions
| Allowed Credits | Maximum Credits |
|---|---|
| 50,000 credits + (Number of User licenses x 1000) + Add-on credits | 1,000,000 credits |
The credit deduction for some of the API operations are listed below.
| API Call | Number of Credits Deducted |
|---|---|
| Get Users/Roles/Profiles | 1 |
| Get list of Modules | 1 |
| Get Field Meta Data | 1 |
| Get Module Meta Data | 1 |
| Get IDs of deleted records | 2 |
| Get records with cvid parameter | 3 |
| Convert Lead | 5 |
| Add/Remove Tags to Multiple records | 1 credit for every 50 records |
| Insert/Update/Upsert | 1 credit for every 10 records |
| Bulk Read Initialize | 50 |
| Bulk Write Initialize | 500 |
| All other APIs | 1 |
Note
- You can Insert/Update/Upsert a maximum of 100 records per API call, and Add/Remove Tags from a maximum of 500 records per API call. Therefore, the maximum number of credits that the system deducts for these API calls is 10.
- The API call limit has a rolling 24 hours window, from the start of the call.
How Integration Tasks Consume Increase API Credits?
The integration tasks used in our Deluge functions are a set of wrappers for each service's API to execute certain actions provisioned in the Deluge editor. You can call an integration task of a service by calling its name.
Example:
zoho.crm.createRecord(“Leads”, <Map>); invokes the Vertical Solutions's Create Records API in the background.
However, there was no way of identifying such API calls made to CRM through these integration tasks from Deluge functions written across Zoho Apps. A provision to identify the origin of these calls can help restrict the unwanted API calls.
To address these aspects and to keep our API servers checked against such hidden consumption, we have decided to include the integration tasks made through Deluge functions as part of the API credit consumption. For example, if you use the zoho.crm.searchRecords() integration task, it will consume the same number of credits as that of the Search Records API.
The Credits by Application section on the API Dashboard will give you the details of the number of integration tasks that an application has consumed in a certain period.
Concurrency limits
In addition to the above credit system, Vertical Solutions also uses a Concurrency system, to calculate API Limits based on the number of concurrent calls made per org per app in Vertical Solutions. These concurrency limits specify the maximum number of API calls that can be simultaneously active at a given point of time per org per app.
Since the API limits are based on the number of simultaneous active calls, there are no time-based API call restrictions in Vertical Solutions. You can make any number of API calls in a minute, provided the number of concurrent calls are within the specified limits. The concurrency limit for an org/app in vertical Solution is 20.
Sub-concurrency limits for various editions
Besides concurrency limits, Vertical Solutions also applies sub-concurrency to limit the number of concurrent calls for the following APIs:
- Get Records with cvid or sort_by parameters
- Convert Lead
- Insert, Update, or Upsert records (when the record count is greater than 10)
- Search records API invoked from a function
- Query API
Therefore, when an API request is sent from an org, two concurrency limits are applied—Concurrency and Sub-concurrency.
For example, consider that a Convert Lead API call is sent from an org. The concurrency limit the org is left with is 19 (out of 20), and the sub-concurrency limit for the Convert Lead request is 9 (out of 10). These limits are further calculated based on the type of subsequent requests.
Let's say the the Get Module Meta Data API request is sent from the org. Now, the concurrency limit becomes 18 (out of the remaining 19), and the sub-concurrency limit stays the same (9).
Now, in the same org, 15 records are updated through the Update records API. The concurrency limit, now, is 17 (out of the remaining 18), and the sub-concurrency limit for the same is 8 (out of the remaining 9).
After this, only 7 concurrent calls can be made from the org—Convert lead, insert/update (more than 10 records), search records from a function, or query API.
When the sub-concurrency limit for any of the two requests is reached, the system throws the TOO_MANY_REQUESTS error.
You can continue to make other requests from the org as they still fall under the primary concurrency limit.