Rate Limits

Throughput limits guard the shared API; billing is enforced separately via API credits.

A request may return 429 (rate limit) or 402 insufficient_api_credits (credits). Treat them differently: wait and retry vs top up credits.

Numeric plan tiers below are examples only. What matters for production is what your Dashboard / account shows plus the X-RateLimit-* headers on live responses (X-RateLimit-Reset is authoritative for window timing).

Example tiers (non-binding)

Plan (example)	HTTP volume (idea)	Concurrent sessions (idea)
Test / Starter	tens–hundreds RPM	small integer
Pro	higher RPM	larger
Enterprise	Custom — set in contract	Custom

For exact quotas, negotiate with Kallglot or read your provisioning email / portal—not this table.

Response headers

Responses may include throughput and billing hints:

HTTP/1.1 200 OK
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 118
X-RateLimit-Reset: 1711454460
X-API-Credits-Remaining: 412
X-API-Credits-Used: 588

Header	How to use it
`X-RateLimit-Remaining`	Slow down proactively when low
`X-RateLimit-Reset`	Sleep until Unix time if you blew the window
`X-API-Credits-*`	Drive dashboards / alerts

Too many requests (`429`)

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "You have exceeded the rate limit. Please retry after 30 seconds.",
    "type": "rate_limit_error"
  }
}

Honor Retry-After (seconds). Back off exponentially if you burst repeatedly.

async function fetchWithBackoff(url, init, attempts = 4) {
  for (let i = 0; i < attempts; i++) {
    const response = await fetch(url, init);
    if (response.status !== 429) {
      return response;
    }
    const retryAfterSec = Number(response.headers.get('Retry-After') || '30');
    await new Promise(resolve => setTimeout(resolve, retryAfterSec * 1000));
  }
  throw new Error('Rate limited after retries');
}

Out of credits (`402`)

{
  "error": {
    "code": "insufficient_api_credits",
    "message": "API credits exhausted. Purchase more credits to continue.",
    "type": "permission_error"
  }
}

No amount of backoff fixes this—increase quota in the Developer Portal or contact support.

Integration habits

Do	Why
Cache `GET /v1/sessions/{id}` per id for a short TTL	Fewer redundant reads
Prefer webhooks for lifecycle vs tight polling loops	Saves HTTP budget
Keep one slow consumer queue for `POST …/analysis`	Analysis is heavier than ordinary CRUD
Re-create sessions sparingly after drops	Creation endpoints are often the hottest

There is no GET /v1/sessions list API — retain session ids (sess_…) from POST /v1/sessions, redirects, or webhooks.

Need higher limits?

Self-serve upgrades (when available): Settings → Billing
Custom quotas / enterprise: sales@kallglot.com

​Rate Limits

​Example tiers (non-binding)

​Response headers

​Too many requests (429)

​Out of credits (402)

​Integration habits

​Need higher limits?

Rate Limits

Example tiers (non-binding)

Response headers

Too many requests (`429`)

Out of credits (`402`)

Integration habits

Need higher limits?