What problem does multi-site API key management solve?
Using one master credential across several websites creates a shared failure and maintenance boundary. A traffic loop, unexpected campaign, or exposed browser key on one site can consume account capacity or force every integration to rotate at once. IPRout lets paid accounts assign named active keys to separate websites and environments, then inspect usage and revoke one credential without changing unrelated deployments.
How should keys be divided across websites?
Assign one key to each meaningful website or trust boundary while active-key capacity permits. Starter supports 2 active keys and Pro supports 5. Name each key after its workload, such as store-production or client-portal, and keep production separate from staging when possible. All keys still consume the account's shared monthly allowance, so creating another key improves isolation and attribution rather than creating another quota.
How do Pro per-key caps isolate traffic?
Pro can assign a new key a monthly cap from 100 to 1,000,000 requests. If a secondary website reaches its lower key cap, that credential receives HTTP 429 while other keys can continue if the shared account allowance remains. This prevents one capped workload from consuming more than its assigned boundary. The cap does not reserve capacity for another site, and Starter keys use the fixed plan-level limit.
How do allowed origins protect browser integrations?
Starter and Pro keys can be created with exact allowed browser origins: up to 5 per Starter key and 10 per Pro key. IPRout rejects a browser request when its Origin does not match the key configuration, and an origin-rejected lookup does not consume usage. Scheme, hostname, and port must match. This reduces unauthorized browser use, but CORS is not secret storage and does not replace server-side authentication.
What happens when one website changes?
Create a replacement key with the intended origins and Pro cap, deploy it only to that website, confirm a successful lookup, and revoke the old credential. Other sites continue using their own keys without code or configuration changes. The same workflow supports selling, retiring, or rebuilding a site. Keep an active-key slot available when zero-downtime rotation is important because origin lists and caps are fixed at creation.
How should a multi-site account be monitored?
Use GET /usage to compare account totals with per-key consumption, last activity, and remaining capacity. Alert before either a critical key or the shared account reaches zero, investigate unexpected growth, and avoid automatic retries after HTTP 429. Record an operational owner for every website outside the secret itself. IPRout currently provides application key controls; it does not claim team invitations or role-based access management.
curl --fail-with-body --max-time 10 \
-H "Authorization: Bearer $IPROUT_API_KEY" \
https://api.iprout.com/usageWhich 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.
- One named key per website
- Pro caps isolate workload consumption
- Exact allowed origins for browser requests
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.