Rate Limits

The Slim.io API enforces per-tenant rate limits to ensure fair usage and platform stability. Rate limits apply to all authenticated API requests.

Default Limits

These limits are approximate and may be adjusted. Burst refers to the maximum number of concurrent requests allowed. Requests beyond the burst limit are queued, not rejected, up to the per-minute limit.

Rate Limit Enforcement

Rate limiting is enforced server-side on a per-tenant basis. The API does not expose rate limit counters in response headers.

429 Too Many Requests

When you exceed the rate limit, the API returns an HTTP 429 Too Many Requests response:

{
  "status": "error",
  "error": {
    "code": "RATE_LIMIT_EXCEEDED",
    "message": "Rate limit exceeded. Please retry later."
  }
}

Handling Rate Limits

Retry Strategy

Implement exponential backoff when you receive a 429 response:

import time
import requests
 
def api_call_with_retry(url, headers, max_retries=3):
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers)
 
        if response.status_code == 429:
            wait = min(2 ** attempt, 30)
            time.sleep(wait)
            continue
 
        return response
 
    raise Exception("Rate limit exceeded after max retries")

Endpoint-Specific Limits

Some endpoints have additional limits beyond the general rate limit:

Increasing Limits

If your use case requires higher rate limits:

1. Starter/Professional tiers — Upgrade to a higher tier for increased limits
2. Enterprise tier — Contact your account manager to configure custom limits
3. Temporary increases — Contact support to request temporary limit increases for migration or backfill operations

Best Practices

1. Cache responses — Cache list and detail responses locally to reduce API calls
2. Use webhooks — For scan completion and drift events, use webhook notifications instead of polling
3. Batch operations — Where possible, use batch endpoints to reduce request count
4. Implement backoff — Use exponential backoff on 429 responses to avoid cascading failures
5. Stagger requests — Distribute API calls over time instead of sending bursts