Skip to main content
The ROOTKey API enforces rate limits on a per-API-key basis to ensure platform stability and fair resource allocation across all clients. Limits vary by subscription plan and apply equally to sandbox and production environments.

How Rate Limiting Works

Rate limits are applied on a sliding window basis. When a limit is exceeded, the API returns:
with a Retry-After header indicating the number of seconds to wait before retrying.

Plan Limits

For specific throughput limits per plan, visit the pricing pages: Enterprise plans include custom rate limit configurations. If your workload requires throughput beyond standard plan limits, contact [email protected] to discuss a custom arrangement.

Protocol Throughput Considerations

Rate limits are enforced at the API layer. Actual throughput for operations that write to the blockchain (RKP-1) is additionally constrained by Polygon block times. For high-throughput workloads, RKP-2 or RKP-3 are recommended. RKP-1 is bounded by blockchain block times in addition to API rate limits.

Handling Rate Limits in Your Integration

Implement retry logic with exponential backoff for all 429 responses:
Recommendations:
  • Always inspect the Retry-After header - use it instead of a fixed backoff value
  • Add jitter to your backoff to avoid thundering herd behaviour when multiple clients hit the limit simultaneously
  • Monitor X-RateLimit-Remaining to detect when you are approaching the limit and proactively slow down
  • For high-volume batch operations, distribute requests over time rather than sending in bursts

Development Environment Rate Limits

The development environment (dev-api.rootkey.ai) applies the same rate limits as production. This allows you to test rate-limit handling during development - you will encounter 429 responses under the same conditions as in production.

Increasing Limits

If your workload consistently approaches plan limits:
  1. Upgrade your plan - view plans
  2. Contact enterprise sales - for custom throughput arrangements at [email protected]
  3. Optimise your integration - review whether your call pattern can be batched or deferred to reduce peak request volume