Your plan sets how much you can process; the request rate limit sets how fast you can call the API. They behave differently, and confusing them is the commonest source of "why is my integration slow" questions.

Your plan's monthly allowance

Each plan includes Revoye Cloud, Revoye Desk or both, with a monthly token allowance for each channel — or unlimited use. The allowance renews on your subscription date, not on the first of the month.

The tokens in a request and in its response count toward the channel that processed it, when the request succeeds. A request that fails is not counted.
A request that would not fit in what is left is refused up front with 429 QUOTA_EXCEEDED. details carries channel, limit, used and resets_at.
With channel: "auto" on a plan with both channels, Revoye uses the other channel when one is used up, and only refuses when both are.
Your usage is in the dashboard, and in quota on GET /v1/status, so your own code can see how close it is.

Revoye Cloud: requests at the same time

Your plan sets how many of your requests Revoye Cloud processes at the same time. Anything beyond that waits in your queue, highest priority first, and starts as soon as an earlier request finishes. This is not an error and needs no retry — it shows up as a higher queue_ms.

Revoye Desk: your device and your hourly limits

Revoye Desk processes requests while it is online on one of your devices. How many devices you can connect is set by your plan. When none is online, requests wait in your queue, or move to Revoye Cloud on a plan with both.

In the dashboard you can also set hourly limits for Revoye Desk — overall, and per model. When one is reached, Revoye Desk takes no more requests it covers until the hour allows it; the requests wait in your queue rather than failing. GET /v1/status reports rate_limit_per_hour and used_this_hour per model. When an hourly limit is the reason a request ends, its error code is 503 PROVIDER_RATE_LIMITED.

Request rate limits on the API

API calls per minute, per API key. Exceeding them returns 429 RATE_LIMITED with a Retry-After header. Honour the header.

	Limit	Covers
Writes	600 / minute	`POST /v1/completions`, `POST /v1/chat/completions`, `DELETE /v1/completions/{id}`
Reads	1 200 / minute	`GET /v1/completions/{id}`, `GET /v1/status`, `GET /v1/models`

Per key rather than per account, so one integration in a retry loop cannot take the production key beside it down with it. Rotate a key and the replacement starts with a fresh budget.

A request with an invalid or revoked key is refused with 401 UNAUTHORIZED. After 30 of those from one address in 15 minutes, further requests from that address get 429 RATE_LIMITED until the window passes — fix the key rather than retrying.

This limit is about call rate, not work volume. It is hard to hit by sending real requests, and easy to hit by polling GET /v1/status or GET /v1/completions/{id} in a tight loop. If you are seeing 429 RATE_LIMITED, look at your polling before you look at your requests.

Diagnosing a slow integration

Symptom	Cause	Fix
`queue_ms` high, `queue.depth` climbing	More requests than your plan processes at once	Spread the batch out, use webhooks, or move to a larger plan
`queue.oldest_queued_at` far in the past, `channels.desk.available: false`	Revoye Desk is offline	Start it on your device; or use webhooks so it does not matter
Frequent `PROVIDER_RATE_LIMITED`	An hourly limit is binding	Let Revoye choose the model, or raise a limit you set, deliberately
Frequent `429 RATE_LIMITED`	You are polling	Poll less; use webhooks
`429 QUOTA_EXCEEDED`	The month's allowance is used up	Wait for `resets_at`, or change plan
`attempts > 1` on most requests	Attempts are timing out	Raise `timeout_ms` for long requests

Other limits


`prompt`	100 000 characters
`messages` on `/v1/chat/completions`	256 messages, each ≤ 100 000 characters, flattening to ≤ 100 000 characters
Request body	1 MiB
Queued requests per account	1 000
Per-attempt timeout	5 000–600 000 ms (default 180 000)
Whole-request deadline	10 000–3 600 000 ms (default 900 000)
`metadata`	4 KiB

The public API has no list endpoints. Keep your own index: store each job id alongside your record when you submit, and query your own database rather than trying to enumerate requests through Revoye.

Rate limits and capacity