These are the limits for consumers of Clickwrap REST and Activity APIs. Requests will be provided a quota per identifier and future API calls that exceed are blocked during the defined timeframe. The rate limit quota will be reset to the maximum after the specified time has passed. The timer will start after the first request that reduces the quota below the specified maximum amount. Site owners and admins are emailed if a limit is reached.
Clickwrap Rate Limits
There are two categories for each service:
- Authenticated requests: Requests that can be associated with a site/account.
- Unauthenticated requests: Requests that cannot be associated with a site/account.
- The most common scenario of Unauthenticated requests are requests that are missing a Site Access ID or API token. This allows us to easily differentiate and act upon possible malicious activity or improper implementations.
The following are the rate limits:
Service | Request Type | Limit | Limited by Identifier |
---|---|---|---|
REST API | Authenticated requests | 2000 maximum per 1 minute | API Token |
Unauthenticated requests | 60 maximum per 1 minute | IP Address | |
Activity API | Authenticated requests | 10000 maximum per 5 minute | Site Access ID |
Unauthenticated requests | 60 maximum per 1 minute | IP Address |
Handling limiting gracefully
When a rate limit is exceeded, a 429 error will be thrown, the request will not be processed, and you will need to resend the request again once the rate limit quota has been reset. Checking and handling the a 429 response is the basic way to gracefully handle a rate limit occurrence. The response header will also contain a Retry-After
response header that will specify the number of seconds until the rate limit quota is reset and can be retried. Below is a sample of the 429 error that the response would contain:
{
"error": {
"message": "Request limit has been reached for the current rate limit period.",
"status": 429,
"name": "RateLimitExceededError",
"code": "rate_limit_exceeded",
"url": "/v1.1/sites",
"context": {
"user": {
"id": "1",
"email": "[email protected]"
}
}
}
}
Tips To Avoid Hitting Rate 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.
Proactively respond
Using the response header information that we provide, to actively adjust and avoid being rate limited. We provide the following informational headers:
X-Ratelimit-Limit
: indicates the total quota that is allowed in the current time window. (If rate limit changes in the future, this will also update)X-RateLimit-Reset
: indicates the exact epoch time that the current window of quota will reset.X-Ratelimit-Remaining
: indicates the remaining quota available for the current time window.
Load testing
Conducting load tests against the API or other components of the Ironclad system must be coordinated with your Ironclad representative. If your company, or department requires load testing of the Ironclad Clickwrap API either prior to implementing or after your implementation is live, please reach out to your Ironclad representative or Ironclad Support ahead of time.