Table of Contents
Credit System
API calls in Zoho Recruit are associated with credits. The credits are deducted from your credit count, based on the type of API calls 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 "Get Records API", 3 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 various editions of Zoho Recruit
| Edition | Allowed Credits | Maximum Credits |
|---|---|---|
| Free Edition | 5000 credits | 5000 credits |
| Standard | 5,000 credits + (Number of User licenses x 250) + Add-on credits | 100,000 credits |
| Professional | 10,000 credits + (Number of User licenses x 500) + Add-on credits | 500,000 credits |
| Enterprise/Zoho One/People Plus | 15,000 credits + (Number of User licenses x 1000) + Add-on credits | 1,000,000 credits |
Here is a calculator to know the available credit limits based on your edition and the number of users.
With the purchase of 100 users for the Enterprise/ZohoOne edition, the available API Credits are 115,000
Note:
For example, in the Standard edition, if there are 10 user licenses in an organization, the available credits will be 7500 (i.e, 5000 + (10 x 250)). However, the maximum limit for this edition will still be 100,000 credits irrespective of the number of user licenses.
For all editions, factors such as concurrency and sub-concurrency are placed to protect the service from overload. This will impact the total number of API calls we process in the 24-hour rolling window.
The credit deduction for some of the API operations is 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 |
| Add/Remove Tags to Multiple records | 1 credit for every 50 records |
| Insert/Update | 1 credit for every 10 records |
| Bulk Read Initialize | 50 |
| Bulk Write Initialize | 500 |
| All other APIs | 1 |
Note
You can Insert/Update 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.
Concurrency limits for various editions of Zoho Recruit
In addition to the above credit system, Zoho Recruit also uses a Concurrency system, to calculate API Limits based on the number of concurrent calls made per user per app in Zoho Recruit. These concurrency limits specify the maximum number of API calls that can be simultaneously active at a given point of time for a user per app.
Since the API limits are based on the number of simultaneously active calls, there are no time-based API call restrictions in Zoho Recruit. You can make any number of API calls in a minute, provided the number of concurrent calls is within the specified limits.
| Edition | Concurrency Limits for a User/App |
|---|---|
| Free | 5 |
| Standard/Starter | 10 |
| Professional | 15 |
| Enterprise/Zoho One/People Plus | 20 |
Sub-concurrency limits for various editions
Besides concurrency limits, Zoho Recruit also applies sub-concurrency to limit the number of concurrent calls for the following APIs:
Get Records with cvid or sort_by parameters
Insert or Update records (when the record count is greater than 10)
Search records API invoked from a function
Therefore, when a user makes an API request, two concurrency limits are applied—Concurrency (edition-based) and Sub-concurrency (request-based).
For example, let's consider that a user in the Professional edition makes a Get Role Data API call. The concurrency limit the user is left with is 14 (out of 15), and the sub-concurrency limit for the Get RoleData request is 9 (out of 10). These limits are further calculated based on the type of subsequent requests.
Let's say the user calls the Get Module MetaData API. Now, the concurrency limit becomes 13 (out of the remaining 14), and the sub-concurrency limit stays the same (9).
Now, the user updates 15 records through the Update records API. The concurrency limit, now, is 12 (out of the remaining 13), and the sub-concurrency limit for the same is 8 (out of the remaining 9).
After this, the user can make only 7 concurrent calls-— 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 an error.
The user can, however, continue to make other requests as they still fall under the primary concurrency limit.
