Two limits, different jobs
Requests per minute limits how quickly an account starts work. Concurrency limits how many requests can be active together. Your API keys, workspace requests and collection workers share those account limits. Creating more keys does not add capacity.
A separate shared limit protects each destination. A larger plan does not make a source’s robots.txt rules or destination restrictions disappear. Read your current account limits in Billing rather than assuming every key has its own allowance.
Respond to the status
For 429, honor Retry-After when it is present and reduce the number of simultaneous requests. Use bounded exponential backoff with jitter instead of an immediate retry loop. For 402, check the credit balance; waiting alone will not add credits.
For 401, check the Bearer header and whether the key expired or was revoked. For a source or validation error, read the error body and fix the input or choose a permitted source. Retrying a source refusal with a different key is not a solution.
A network timeout is not proof of failure
If your application loses a response, the server may have completed the request. Check Activity before starting a new synchronous request; a second success is a second charge. Keep the returned request ID whenever you receive it.
The seven synchronous APIs support an optional Idempotency-Key header. Supply a unique key before the first attempt, then reuse it with unchanged inputs for a network retry within 24 hours. A retained response is replayed without a second acquisition charge. After expiry the key may execute again. Collection submissions use their separate client_id field. Set a retry count and total deadline in your client; the API reference explains pending, failed and unavailable replay outcomes.