Skip to main content

Rate Limiting

Clemta APIs implement rate limiting to ensure fair usage and system stability. This page explains how rate limiting works across all our APIs.

Rate Limit Types

Clemta APIs employ different rate limiting strategies depending on the endpoint:
  1. API Key-based Rate Limiting: Applied to most endpoints
  2. Resource-based Rate Limiting: Applied to specific resources (e.g., per company ID)

Rate Limit Headers

All API responses include headers that provide information about rate limits:

Common Headers

string
Displays your API key’s rate limit (e.g., “100 requests per minute”)
integer
Number of requests remaining in the current time window
integer
Maximum number of requests allowed per minute
integer
Unix timestamp when the rate limit resets
string
Indicates which rate limit type is being applied (“api_key” or “resource”)
When a rate limit is exceeded, you’ll also receive:
integer
Seconds to wait before making another request (typically 60 seconds)

Rate Limit Errors

When a rate limit is exceeded, the API will respond with:
  • HTTP Status Code: 429 Too Many Requests
  • Error Code: RATE_LIMIT_EXCEEDED
  • Error Message: “Rate limit exceeded”

Best Practices

1

Implement exponential backoff

Use a retry strategy with exponential backoff when you receive 429.
2

Monitor your usage

Track X-RateLimit-Remaining and slow down before hitting limits.
3

Use conditional requests

Use If-Modified-Since for GET endpoints.
4

Use pagination

Paginate list endpoints to reduce load.

1. Implement Exponential Backoff

exponential_backoff.go

2. Monitor Rate Limit Headers

monitor_headers.go

3. Use Conditional Requests

conditional_requests.go

Example Rate Limit Headers

Successful Request

Rate Limited Request