Rate limits
Limits scale with the organization's plan, per key and per organization.
A request is a weighted unit - see How requests are counted below. The per-organization ceilings apply across every key the organization holds, so ten keys do not mean ten times the budget.
| Plan | Per minute, per key | Per minute, per organization | Per day, per organization | Writes per day, per organization |
|---|---|---|---|---|
Free trial | 10 | 20 | 500 (total for the trial) | 0 (test keys cannot write) |
Individual | 30 | 60 | 10,000 | 2,000 |
Pro | 100 | 200 | 50,000 | 20,000 |
Business | 300 | 600 | 250,000 | 100,000 |
Enterprise | 600 | 1,200 | 1,000,000 | unlimited |
The per-day column is a database-protection ceiling and is separate from the monthly request pool under Plans and pricing: a Business organization can spend its 500,000 pool requests over a month but never more than 250,000 of them in one day.
Heavy requests - POST /v1/ai/ask and a commission report rendered as PNG - also share a per-key sub-window of 20% of the per-minute limit in weighted units, never below 10 (one AI question a minute on every plan): free trial 10, Individual 10, Pro 20, Business 60, Enterprise 120. That keeps one expensive loop from starving the cheap calls next to it. Lists are never in that window; a larger page simply weighs more.
Headers
Every response carries the current state of every window:
- X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset - the per-minute window for this key (reset is epoch seconds).
- X-RateLimit-Limit-Org - the per-minute ceiling for the whole organization.
- X-RateLimit-Limit-Day, X-RateLimit-Remaining-Day, X-RateLimit-Reset-Day - the per-day window for the organization.
- X-Write-Quota-Limit, X-Write-Quota-Remaining, X-Write-Quota-Reset - on writes (POST, PATCH, PUT, DELETE): the organization's daily write quota. Reads never count against it.
- X-Api-Requests-Used, X-Api-Requests-Included - the organization's request pool for the current billing period (see Plans and pricing).
When you exceed a window you get 429 rate_limit_error with a Retry-After header (seconds). Back off and retry after the window resets. GET /v1/usage returns every window and the pool in one call.
How requests are counted
Every request is weighted so that expensive calls pay for what they cost. Weights apply to the rate-limit windows and to the request pool alike, and a request that fails with a 5xx is never counted.
| Request | Weight |
|---|---|
Read, create, update or delete a single record | 1 |
A list | 1 + 1 per 25 records requested (limit 25 = 2, 50 = 3, 100 = 5) |
POST /v1/ai/ask | 10 (the AI answer itself is 10 Genaya AI credits, like a question in the app - a separate meter) |
A commission report as PNG (format=png) | 5 |
/ping, /account, /usage | 1 |
A request refused by a limit (429) or by the usage gate (402) is not counted either. A retry that replays a stored Idempotency-Key response is a normal request: it passes the limiter and counts its full weight, so a retry loop still spends the pool.
Through the MCP connector (POST /v1/mcp) the JSON-RPC request itself counts 1 on the rate-limit windows only - it is never billed to the pool - and every tools/call inside it counts the weight of the REST request it makes, on the windows and on the pool, exactly as a direct call would. A tool call refused by a limit or by the write quota returns the standard error envelope as the tool's error text; a 402 or 429 on the outer POST /v1/mcp itself comes back as the REST error envelope, not as a JSON-RPC error. A JSON-RPC batch may carry at most 20 messages. The member connector at https://api.genaya.com/mcp has its own per-connection and per-organization windows (see MCP); when an API key with Allow MCP is the bearer there, each finished call counts 1 on this pool and on this key's windows too - a developer tool reading through /mcp and through /v1 draws from one pool.