Request rate limits
Pace requests across your workspace and recover from short-term throttling.
Rate limits control how quickly requests arrive. They are separate from monthly included calls and prepaid balance and from resetting key-call or money caps.
Read your effective limit
Open Usage for your workspace's current request rate and increase-request status. For metered corpus and chemistry requests, rates are shared by the workspace across REST, MCP and test access; creating another key does not create a new workspace allowance.
There is a minute counter and a shorter burst counter. Their windows reset after inactivity rather than at a fixed wall-clock minute. Spread a batch over time; avoid launching every task at once.
Inspect response headers
Use curl -i with a small request to include headers:
curl --silent --show-error --include \
'https://api.cyberrxn.com/v1/chemistry/validate' \
-H "Authorization: Bearer $CYBERRXN_API_KEY" \
-H 'Content-Type: application/json' \
--data '{"reaction_smiles":"CCO>>CC=O","mode":"strict"}'This validation is a metered operation. When present, read these headers:
| Header | Meaning |
|---|---|
X-RateLimit-Limit | Effective workspace request limit for the 60-second counter |
X-RateLimit-Remaining | Requests remaining in that counter |
X-RateLimit-Reset | Unix timestamp in seconds for that counter's reset |
Retry-After | Minimum delay before retrying a throttled request |
X-Request-Id | Support identifier for this request |
The burst limit can reject a request while the minute counter still has space. Prefer Retry-After on a 429 over computing a delay from just the minute headers.
Recover from HTTP 429
- Inspect
code.request_rate_limitedmeans request pacing;key_limit_reachedandworkspace_limit_reachedmean usage policies. - For a retryable rate failure, wait at least the supplied
Retry-After/retry_after_seconds. - Retry within a bounded attempt and time budget. Reduce concurrent workers if throttling repeats.
- Do not retry a zero cap, expired policy, missing permission or exhausted credit as a pacing failure.
The Python and JavaScript SDKs already perform eligible retries, with up to two retries by default. Long delays are surfaced to the caller rather than blocking indefinitely. An additional application retry loop should account for those attempts. Structured errors.
Request a higher rate
A workspace owner or administrator can request an increase in Usage. Submitting a request does not immediately change the limit; review determines the outcome.
The rate-settings API requires a first-party app session. It is not an API-key endpoint. Batch jobs can read their normal request headers without using the app's administrative session.