What are the current public plan limits?
These values apply to the Free, Starter, and Pro plans shown on the pricing page.
| Plan | Requests/month | Active keys |
|---|---|---|
| Free | 10,000 | 1 |
| Starter | 100,000 | 2 |
| Pro | 1,000,000 | 10 |
Do key caps increase the quota?
No. A key cap is a guardrail inside the shared plan allowance, not an additional pool of requests.
How should plan capacity selection be implemented?
Estimate monthly lookups from real product events, expected growth, retries, nonproduction traffic, and seasonal peaks. Select a plan with operational headroom rather than sizing exactly to an average month. Keep this responsibility close to the IPRout client so the behavior documented in API Quotas and Plan Limits remains consistent across web requests, workers, and scheduled jobs.
How should plan capacity selection be verified?
Compare the pricing source of truth with the dashboard and /usage response after plan changes. Confirm active-key slots, origin allowances, and cap controls separately from request volume. Automate the stable cases and reserve live checks for controlled environments so verification is repeatable without consuming unnecessary production allowance.
How should plan capacity selection be operated?
Set warning thresholds well before remaining requests reach zero and assign someone to act on them. Review capacity after launches, traffic acquisition, new integrations, or changes to caching behavior. Write down the owner and expected behavior so an alert or product change can be handled without reconstructing the original integration decisions.
Where does plan capacity selection stop?
Additional active keys improve separation and attribution but do not multiply requests. Pro key caps are internal guardrails inside the account total, not independently purchased or reserved pools. 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 plan capacity selection?
Review the deployed implementation of API Quotas and Plan Limits, 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 plan capacity selection be revisited?
Revisit plan capacity selection 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.