Skip to main content
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.

​
Rate Limits

All API keys are subject to the following default limits:
WindowLimit
Per minute300 requests
Per second10 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:
HeaderDescription
X-RateLimit-LimitThe maximum number of requests allowed in the current window
X-RateLimit-RemainingThe number of requests you can still make before hitting the limit
X-RateLimit-ResetUnix 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.