Rate limits
Two limits apply: how many requests a key can send per minute, and how many analyses your organization can have waiting. This page explains both and how to react when you hit one.
Requests per key
Each API key can send 120 requests per minute by default. Grihafy can adjust this for your organization. Every response includes the current state:
| Header | Meaning |
|---|---|
RateLimit-Limit | Requests allowed in the current window. |
RateLimit-Remaining | Requests left in the window. |
RateLimit-Reset | Seconds until the window resets. |
Retry-After | Only on a 429 or 503. Seconds to wait before you retry. |
Past the limit the API returns 429 rate_limited. Rejected requests still count, so wait for Retry-After instead of retrying immediately. Prefer webhooks to polling, or check each analysis every 5 to 10 seconds.
Unfinished analyses in your organization
Analyses take time, so accepted work waits in line. By default an organization can have up to 100 analyses that are not finished yet, and one is processed at a time. Submissions beyond that are refused until space frees up.
| Response | Meaning | What to do |
|---|---|---|
429 queue_full | Your organization already has the maximum number of unfinished analyses. | Wait for Retry-After, then send the same request again with the same Idempotency-Key. |
503 service_unavailable | Analyses cannot be processed right now. | Wait for Retry-After and retry the same request. |
Because one analysis runs at a time by default, a large batch finishes gradually. Submit what you need, keep each analysis ID, and collect results by webhook or by checking each analysis. Contact us if you need higher limits.
Retry with a delay
On 429 and 503, wait the number of seconds in Retry-After. On 500, retry after a short delay and increase it on each attempt. Always reuse the same Idempotency-Key when you retry a submission; see Idempotency.
No response-time or availability guarantee is published yet, so build your integration to wait and retry.