Rate Limits

To ensure fair usage, the API enforces rate limits on all requests.

Requests	Rate
All API requests	150 requests per second
Sample reads — samples/{sample_id}, sample-kit/{sample_id}, sample-parentage/{sample_id}	100 requests per second
Kit orders — POST sample-kit/, POST sample-kit-form/	30 requests per second
Array data uploads — POST array-data-upload/, POST array-data-upload-form/	30 requests per second
Upload credentials — POST uploads-url/, POST uploads-post-data/	30 requests per second
Genomic variant queries — sample-genomic-variants/{sample_id}	5 requests per second

The endpoint limits apply on top of the overall one, so whichever is tighter is the limit you will reach first. Uploading a file does not count against these limits — only the request that asks Gencove for the upload credentials does.

Limits apply per API key owner

All API keys belonging to the same user share a single budget, so issuing extra keys does not raise your throughput. If your integration runs across several machines or containers, they draw on the same allowance no matter which IP addresses they call from.

Rate limit exceeded

When you exceed a rate limit, the API returns a 429 Too Many Requests response with a Retry-After header indicating how many seconds to wait before retrying:

HTTP 429 Too Many Requests
Retry-After: 1

{
  "detail": "Request was throttled. Expected available in 1 second."
}

Best practices

• Honor Retry-After. Wait the number of seconds the header specifies before sending the request again. Retrying immediately will simply be rejected again.
• Back off exponentially if a retry is also throttled, and add a small random jitter so that parallel workers do not all retry on the same tick.
• Cap your concurrency. Firing an unbounded number of parallel requests is the most common way to hit a limit; a fixed-size worker pool keeps you comfortably beneath it.
• Spread out bulk work. When processing a large batch of samples, pace the requests rather than issuing them as fast as your client allows.