Why use more than one active key?
Separate credentials reduce the impact of routine changes and security incidents. A production service does not need to share the same secret as staging, a background worker, or an experimental integration. When one workload is retired or exposed, its key can be revoked without forcing unrelated applications to update. Named keys also make per-key usage understandable in the account usage response.
How many keys can each plan activate?
Free allows 1 active API key, Starter allows 2, and Pro allows 5. The allowance is designed for application and environment separation, not for creating additional monthly quotas. Every request still contributes to the account's shared plan total: 10,000 on Free, 100,000 on Starter, and 1,000,000 on Pro under the current public plans.
How should two Starter keys be allocated?
A common Starter setup uses one key for production and one for staging or a secondary service. Because Starter caps are fixed by the plan, both keys draw from the same 100,000-request account allowance without a configurable key-specific threshold. Each key can be created with up to 5 exact CORS origins when browser access is intended. Choose boundaries that make revocation and attribution useful.
What does Pro add to multi-key operation?
Pro provides 5 active slots and lets each new key choose a request cap from 100 to 1,000,000. A cap can contain one integration before it consumes all shared capacity, while up to 10 exact CORS origins can constrain browser use. Cap and origin settings are fixed for that credential; recreate and rotate the key when those controls need to change.
Do requests change when keys are separated?
No. Each service sends its assigned secret through the normal Authorization or X-API-Key header and calls the same endpoints. The request below is suitable for testing a newly created key. Confirm it succeeds from the intended environment before removing an older credential during rotation.
curl --fail-with-body --max-time 10 \
-H "Authorization: Bearer $IPROUT_API_KEY" \
https://api.iprout.com/ip/8.8.8.8How should active keys be governed?
Use names that expose purpose without exposing the secret, record the service owner outside the key value, and review last use and consumption. Avoid creating duplicate keys with ambiguous names. Monitor the shared account total and each key through GET /usage. Revoke retired keys promptly so the active-key limit remains available for zero-downtime rotation and future workloads.
Which IPRout plan fits this workload?
Use the 7-Day Developer Key for a short evaluation with 1,000 requests. Free supports ongoing low-volume use with 10,000 monthly requests and 1 active key. Starter adds 100,000 requests, 2 active keys, and up to 5 exact CORS origins per key. Pro provides 1,000,000 requests, 5 active keys, up to 10 origins per key, and a configurable 100 to 1,000,000 request cap when each key is created. All active account keys consume one shared monthly allowance.
| Plan | Monthly requests | Active keys |
|---|---|---|
| Free | 10,000 | 1 |
| Starter | 100,000 | 2 |
| Pro | 1,000,000 | 5 |
What are the key benefits?
This feature uses the same authenticated HTTPS interface and predictable JSON conventions as the rest of IPRout. That keeps the integration small while letting teams separate product logic from the details of IP intelligence and API key controls.
- Starter: 2 active keys
- Pro: 5 active keys
- Shared monthly plan quota
How do I get started?
Generate a 7-Day Developer Key for evaluation or create an account key for an ongoing integration. Begin with the documented request, add status-aware error handling and a finite timeout, then connect only the response fields your product needs. Review usage before launch, keep the secret in trusted infrastructure, and follow the linked documentation for feature-specific configuration.