Rate Limits

Per-minute limits, monthly quotas, and how to back off correctly.

Every account with API access has four limits, set individually by Stynar when access is granted — there's no fixed public tier table, since limits aren't based on plan. Check Get accountfor your account's actual numbers; never hardcode these, they can change.

Rate limits

How frequently requests can be made.

Field	Type	Required	Description
requestsPerMinute	number	Optional	Sustained per-key rate, enforced with a rolling one-minute window.
burstPerSecond	number	Optional	Short per-key burst ceiling — protects against a tight retry loop even if you're under the per-minute limit.

Quotas

How much API usage is available within a billing/account period.

Field	Type	Required	Description
monthlyRequests	number	Optional	Total requests/month, shared across all of your API keys. Resets at the start of each calendar month.
maxApiKeys	number	Optional	Maximum number of simultaneously-active keys. Revoke an old one before creating a new one past this limit.

Response headers

Every successful response carries your current standing against the per-minute limit, so you can back off before you hit it:

Headers on every response

X-RateLimit-Limit: <per-minute limit>
X-RateLimit-Remaining: <remaining in current minute>

When you're rate limited

A limit exceeded returns 429 Too Many Requests, with an additional header telling you how long to wait:

Headers on a 429

Retry-After: <seconds>
X-RateLimit-Limit: <per-minute limit>
X-RateLimit-Remaining: 0

429 response body

{
  "error": {
    "code": "RATE_LIMIT_EXCEEDED",
    "message": "API rate limit exceeded",
    "request_id": "req_..."
  }
}

Two different 429s

RATE_LIMIT_EXCEEDED means you hit the per-minute or per-second ceiling — wait out Retry-After and retry. QUOTA_EXCEEDEDmeans your monthly quota is exhausted for the rest of the calendar month — retrying immediately won't help; contact Stynar if you need it raised.

Respect Retry-After instead of guessing a backoff

Retrying before Retry-After elapses just burns another request against the same limit. Use it directly as your sleep duration rather than a fixed or exponential backoff of your own.