Rate Limits

Ironclad CLM Limits

These API limits are set on a per account basis.

Handling limiting gracefully

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.

Tips to avoid hitting API limits

Cache data for repeat calls

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.

Use Async APIs and Webhooks

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.

Load testing

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.

Other limits

Notwithstanding the limits specified in this document, the system might still limit requests if it detects an unusual spike in requests from all sources for the account, including internal product requests. For example, in a denial of service attack. Please see our API Terms of Use for more information.