Which plans have configurable caps?
The cap option differs from the number of active keys.
| Plan | Per-key behavior |
|---|---|
| Free | Fixed by plan |
| Starter | Fixed at plan limit |
| Pro | Choose 100 to 1,000,000 |
What happens when a key reaches its cap?
That key receives HTTP 429 even if the account still has unused monthly capacity. Other active keys can continue while shared capacity remains.
Can an existing cap be changed?
No. Revoke and recreate the key with the new cap. Roll out the replacement before revoking the old credential to avoid downtime.
How should Pro key consumption caps be implemented?
Choose a cap from expected normal and peak volume for the individual workload, leaving enough shared account headroom for higher-priority keys. Configure the value when creating the Pro key. Keep this responsibility close to the IPRout client so the behavior documented in Per-Key Request Caps remains consistent across web requests, workers, and scheduled jobs.
How should Pro key consumption caps be verified?
Use /usage fixtures to verify behavior as the key approaches and reaches its boundary. The application should recognize 429 without assuming the whole account is exhausted. Automate the stable cases and reserve live checks for controlled environments so verification is repeatable without consuming unnecessary production allowance.
How should Pro key consumption caps be operated?
Alert on both percentage and absolute capacity where practical. Revisit caps after traffic changes, but rotate to a replacement credential because an existing key's cap is immutable. Write down the owner and expected behavior so an alert or product change can be handled without reconstructing the original integration decisions.
Where does Pro key consumption caps stop?
A key cap limits consumption; it neither reserves that amount nor adds it to the plan. Other keys can use shared requests first, and account exhaustion stops all keys regardless of their configured caps. Treat that limit as part of the feature contract and direct callers to the related guide when they need a different guarantee or control.
What belongs in the release review for Pro key consumption caps?
Review the deployed implementation of Per-Key Request Caps, not only a local sample. Confirm the intended endpoint, credential source, timeout, response model, and fallback from the environment that will carry real traffic. Use the verification cases above as release evidence, inspect generated browser assets and logs for secret exposure, and make sure dashboards identify the workload without storing raw credentials or unnecessary IP data. Record the configuration owner and rollback action before enabling the feature broadly.
When should Pro key consumption caps be revisited?
Revisit Pro key consumption caps when traffic volume, plan capacity, application ownership, deployment regions, browser origins, data retention, or the product consequence of a lookup changes. Compare the current implementation with the documented operating boundary rather than assuming the original decision still fits. Update tests and internal runbooks together, then verify the public API contract and related IPRout guides before rolling the change across every service that shares the client or account.
External references
Continue with the standards and official documentation most relevant to this guide.