These API limits are set on a per account basis.
|GET Records*||600 requests per minute|
|POST/PATCH Records*||200 requests per minute|
|GET Workflows*||400 requests per minute|
|POST/PATCH Workflows*||40 requests per minute|
|PATCH/DELETE scim/v2/users*||50 requests per minute|
|scim/v2/groups*||600 requests per minute|
|Webhooks Endpoints||600 requests per minute|
|All other APIs||800 requests per minute|
If the rate limit is exceeded, the API responds with a 429 Too Many Requests status code. A basic technique for integrations to gracefully handle limiting is to watch for 429 status codes and build in a retry mechanism. The retry mechanism should follow an exponential backoff schedule to reduce request volume when necessary. We’d also recommend building some randomness into the backoff schedule to avoid a thundering herd effect.
If your site or app uses data from Ironclad on each page load, that data should be cached and loaded from that cache instead of being requested from the Ironclad APIs each time.
When possible, it is best practice to create workflows asynchronously for non-blocking performance. This document also has more information about how to launch workflows.
Ironclads' Webhooks allow users to receive updates to many types of events that happen in the Ironclad CLM environment. Webhooks do not count towards the API limits. More information about Ironclad's webhooks can be found here.
Some users prepare to launch an Ironclad CLM API integration by load testing the application in their demo environment. We generally discourage this practice because API limits are lower in test mode, so the load test is likely to hit limits that it wouldn’t hit in production.