Rate Limits

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:

ServiceRequest TypeLimitLimited by Identifier
REST APIAuthenticated requests2000 maximum per 1 minuteAPI Token
Unauthenticated requests60 maximum per 1 minuteIP Address
Activity APIAuthenticated requests10000 maximum per 5 minuteSite Access ID
Unauthenticated requests60 maximum per 1 minuteIP 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.