How should API keys be organized?
Give each credential a name that identifies its environment and workload, such as production-web, staging-api, or reporting-worker. This makes usage and last activity understandable without exposing the secret. Where the plan supports multiple active keys, separate trust boundaries rather than sharing one credential across every service. IPRout currently manages keys for applications and environments; it does not claim team invitations or role-based permissions.
What is the lifecycle of a key?
Create a key for one purpose, copy the secret into a server-side secret manager when shown, configure supported origin and cap controls, deploy it, and monitor its activity. Rotate before a planned retirement and revoke immediately after exposure or unauthorized use. A credential that is no longer attached to a live service should not remain active merely because its request count is zero.
How do plan limits affect key strategy?
Free supports 1 active key, Starter supports 2, and Pro supports 5. These are simultaneous active-key limits, not separate request pools. Starter keys can use up to 5 exact CORS origins and use the fixed plan cap. Pro keys can use up to 10 exact origins and choose a cap from 100 to 1,000,000 at creation. All keys share the account's monthly allowance.
What should never happen to a secret?
Do not commit it, paste it into a public issue, include it in screenshots, place it in a query string, or ship it in an unrestricted browser bundle. Redact Authorization and X-API-Key headers from application and gateway logs. If a secret leaves its intended storage boundary, treat it as compromised, review usage, create a replacement, and revoke the exposed key.
How do managed keys call the API?
Every active key uses the same lookup endpoints and authentication contract. The caller can send the secret as a Bearer token or through X-API-Key. The example below reads a key from the environment and performs a known explicit lookup. Key creation, restriction, regeneration, and revocation remain dashboard operations rather than public lookup endpoints.
curl --fail-with-body --max-time 10 \
-H "Authorization: Bearer $IPROUT_API_KEY" \
https://api.iprout.com/ip/8.8.8.8How should key reviews be performed?
Review active key names, owners, purpose, last use, CORS origins, caps, and per-key consumption on a regular schedule. Investigate a dormant credential before removal, then revoke it when no live dependency remains. Use /usage for request attribution and account capacity. Document who owns each application operationally even though the product does not currently provide team-role management.
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.
- Named credentials by workload
- Independent revocation
- Usage attribution per key
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.