Rate Limits

The Slim.io API applies per-tenant rate limits to protect platform stability and prevent abuse. Specific thresholds are tailored to each deployment based on customer workload, data volume, and sensitivity of the operation. Exact values are not published; your account team can share the limits configured for your tenant.

Rate-limit behaviour is endpoint-specific. Read-heavy endpoints are sized more permissively than write, administrative, and data-reveal endpoints. Build clients to react to 429 + Retry-After rather than relying on fixed thresholds.

429 Too Many Requests

When a request exceeds the limit configured for your tenant, the API returns HTTP 429 Too Many Requests. Response bodies vary by endpoint but always include a human-readable error message. Where applicable, a Retry-After response header tells the client how long to wait before retrying.


HTTP/1.1 429 Too Many Requests
Retry-After: 6
Content-Type: application/json
 
{
  "error": "Rate limit exceeded. Please retry later."
}

Response Headers

Certain endpoints return rate-limit telemetry in response headers so clients can self-throttle before hitting the ceiling:

Header	Meaning
`X-RateLimit-Limit`	Ceiling for the current window
`X-RateLimit-Remaining`	Requests left in the current window
`X-RateLimit-Reset`	Unix timestamp when the window resets
`Retry-After`	Seconds to wait before the next request

Header emission is endpoint-specific. Treat the absence of Retry-After on a 429 response as an instruction to back off with exponential delay.

Handling Rate Limits

Retry Strategy

Honour Retry-After when present; fall back to exponential backoff (capped) when it is not.


import time
import requests
 
def api_call_with_retry(url, headers, max_retries=5):
    for attempt in range(max_retries):
        resp = requests.get(url, headers=headers)
        if resp.status_code == 429:
            retry_after = int(resp.headers.get("Retry-After", 2 ** attempt))
            time.sleep(min(retry_after, 60))
            continue
        return resp
    raise RuntimeError("Rate limit not recovered after retries")

Best Practices

Honour Retry-After when the header is present; fall back to exponential backoff with jitter otherwise.
Cache list and detail responses locally to reduce polling volume.
Subscribe to webhooks for scan completion, drift, and findings events instead of polling.
Use batch endpoints where available — a single batch call is always cheaper against rate limits than many individual calls.
Stagger bulk work across time. Avoid tight loops that fire hundreds of requests in the same second during migrations or backfills.
Separate service-account API keys for different workloads (CI, ETL, interactive UI). Isolation makes throttling predictable and incidents easier to diagnose.

Adjusting Limits

Slim.io deployments are sized per customer. If your workload hits a limit during normal operation — for example a large migration, a governance backfill, or a CI/CD validation burst — contact your account team. Limits can be tuned for sustained traffic, and a temporary ceiling can be arranged for one-off migration windows.