How many active keys can I use?
The active-key allowance depends on the current plan.
| Plan | Active keys |
|---|---|
| Free | 1 |
| Starter | 2 |
| Pro | 10 |
How should keys be divided?
Use one key per trust boundary where the plan allows it.
- Separate production from staging
- Separate web applications from background jobs
- Use descriptive names so usage is attributable
Do keys have separate monthly quotas?
No. Active keys share the account's monthly plan allowance, even when an individual Pro key has a lower cap.
How should workload credential separation be implemented?
Assign keys by trust boundary, such as production, staging, a worker, or an independent website. Separate credentials let one workload rotate or be revoked without changing every integration. Keep this responsibility close to the IPRout client so the behavior documented in Multiple Active Keys by Plan remains consistent across web requests, workers, and scheduled jobs.
How should workload credential separation be verified?
Send one known lookup through each deployment and confirm that /usage attributes activity to the intended key. Check that no environment silently falls back to a shared legacy credential. Automate the stable cases and reserve live checks for controlled environments so verification is repeatable without consuming unnecessary production allowance.
How should workload credential separation be operated?
Keep one active slot available when overlap is needed for zero-downtime rotation. Review key names and last activity so slots are not consumed by duplicates or retired services. Write down the owner and expected behavior so an alert or product change can be handled without reconstructing the original integration decisions.
Where does workload credential separation stop?
Active keys do not receive independent plan quotas. They share account capacity, and only Pro can place a configurable lower cap on an individual credential. 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 workload credential separation?
Review the deployed implementation of Multiple Active Keys by Plan, 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 workload credential separation be revisited?
Revisit workload credential separation 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.