Rate Limits
Rate limits protect the LUXPOS API and ensure fair access for all integrations. Limits are applied per API key.
Default limits
Standard tier
All API keys (default)
60req / min / key
Limits reset on a rolling 60-second window, not a fixed clock minute.
If your integration requires higher limits, contact [email protected] to discuss an enterprise allocation.
Rate-limit headers
Every API response includes the following headers so your code can monitor and respect the limits proactively:
RateLimit-LimitMaximum requests allowed in the current window (e.g. 60).
RateLimit-RemainingRequests remaining in the current window.
RateLimit-ResetUnix timestamp (seconds) at which the current window resets and the limit is restored.
Example response headers:
http
HTTP/2 200
RateLimit-Limit: 60
RateLimit-Remaining: 43
RateLimit-Reset: 1733742060Handling 429 responses
When you exceed the limit the API returns 429 Too Many Requests:
json
{
"statusCode": 429,
"message": "Too many requests. Please retry after the RateLimit-Reset timestamp.",
"error": "Too Many Requests"
}Implement exponential back-off with jitter to recover gracefully. A minimal Node.js example:
typescript
async function fetchWithRetry(url: string, token: string, retries = 3) {
for (let attempt = 0; attempt < retries; attempt++) {
const res = await fetch(url, {
headers: { Authorization: `Bearer ${token}` },
});
if (res.status !== 429) return res;
// Read the reset timestamp from the header
const reset = Number(res.headers.get("RateLimit-Reset") ?? 0);
const now = Math.floor(Date.now() / 1000);
const waitMs = Math.max((reset - now) * 1000, 1000); // at least 1 s
// Add jitter to avoid thundering herd
const jitter = Math.random() * 500;
await new Promise((r) => setTimeout(r, waitMs + jitter));
}
throw new Error("Rate limit exceeded after retries");
}Tip: Monitor
RateLimit-Remaining on every response and proactively slow down your request rate before hitting the limit. This avoids unnecessary 429s in busy integrations.