Rate Limits

Thiqwave enforces rate limits to ensure fair usage and platform stability for all partners. Limits are applied per API key using a rolling window — the window resets continuously rather than at a fixed clock boundary, so your allowance is always calculated against the last 60 seconds and the last 60 minutes respectively.

All API keys are subject to the following default limits:

Window	Limit
Per minute	300 requests
Per second	10 requests

Both limits apply independently. If you exhaust either allowance, subsequent requests are rejected until the window recovers. If your integration requires higher limits, contact your Thiqwave account manager.

Rate Limit Headers

Every API response includes headers that tell you your current rate limit status:

Header	Description
`X-RateLimit-Limit`	The maximum number of requests allowed in the current window
`X-RateLimit-Remaining`	The number of requests you can still make before hitting the limit
`X-RateLimit-Reset`	Unix timestamp (UTC) at which the current window resets

Use these headers proactively in your integration to throttle outgoing requests before you hit the limit.

HTTP/1.1 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 42
X-RateLimit-Reset: 1744149600

Handling 429 Responses

When you exceed a rate limit, the API returns a 429 Too Many Requests response with a Retry-After header:

HTTP/1.1 429 Too Many Requests
Retry-After: 14
Content-Type: application/json

{
  "error": "Too Many Requests",
  "message": "Rate limit exceeded. Please wait before retrying.",
  "code": "RATE_LIMIT_EXCEEDED"
}

The Retry-After value is the number of seconds you must wait before the API will accept requests from your key again. Your integration must respect this value — sending requests before the window resets will continue to receive 429 responses and will not accelerate the reset.

Best Practices

Use exponential backoff. When you receive a 429, wait the duration specified in Retry-After, then retry. If the retry also fails, double the wait time on each subsequent attempt up to a reasonable maximum (e.g. 60 seconds).

async function requestWithBackoff(fn, maxRetries = 5) {
  let delay = 1000;
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      return await fn();
    } catch (err) {
      if (err.status === 429 && attempt < maxRetries - 1) {
        const retryAfter = err.headers?.["retry-after"];
        const waitMs = retryAfter ? parseInt(retryAfter) * 1000 : delay;
        await new Promise((resolve) => setTimeout(resolve, waitMs));
        delay *= 2;
      } else {
        throw err;
      }
    }
  }
}

Batch requests where possible. Some Thiqwave endpoints support bulk operations. Where available, use bulk endpoints instead of looping over individual requests — this reduces the total number of API calls you need to make. Monitor X-RateLimit-Remaining proactively. If X-RateLimit-Remaining drops to a low value, slow down your request rate before you hit zero. This avoids disruption to your integration. Use separate API keys per environment. Staging and production traffic each consume rate limit allowances independently. Using separate keys per environment prevents test traffic from exhausting your production quota.

Getting Started

Core Concepts

Guides

Reference

Rate Limits

Rate Limits

Rate Limit Headers

Handling 429 Responses

Best Practices

​Rate Limits

​Rate Limit Headers

​Handling 429 Responses

​Best Practices

Rate Limits

Rate Limit Headers

Handling 429 Responses

Best Practices