Shared Account Quotas

What does a shared quota mean?

All active API keys on one account consume the same monthly plan allowance. Free includes 10,000 requests, Starter 100,000, and Pro 1,000,000 under the public plans. Creating another active key improves credential isolation and attribution but does not create a second pool. The account's total_requests is therefore the combined successful lookup usage produced by its keys during the current month.

Why combine shared capacity with separate keys?

The shared allowance keeps account capacity predictable, while separate keys let operators identify workloads, revoke one service, configure paid-plan origins, and on Pro set a lower workload cap. This separates security boundaries without fragmenting billing. A staging integration can have its own credential and still be visible in the same account usage summary as production, making accidental consumption easier to spot.

How do per-key caps fit inside the quota?

A Pro cap is a guardrail within shared capacity. If a key capped at 20,000 reaches that number, it receives HTTP 429 even if the account still has requests available. Other keys can continue until their own caps or the account total is reached. Starter key caps are fixed by the plan, so monitoring and application separation provide visibility without a configurable threshold.

How should capacity be allocated?

Estimate expected volume by workload, reserve room for critical production traffic, and set Pro caps where an integration should not consume the entire account. Do not assume unused cap on one key is reserved capacity; all successful requests affect the common total. Alert before thresholds are reached and review growth after releases, marketing events, client retry changes, or new background processing.

How do I inspect shared and key usage?

Call GET /usage from trusted server infrastructure. Compare top-level remaining_requests with each key's remaining_requests and requests_this_month. A key can show no remaining capacity while the account still has room, or the account can be exhausted before a high-cap key reaches its own ceiling. The same response supports both diagnoses.

curl --fail-with-body --max-time 10 \
  -H "Authorization: Bearer $IPROUT_API_KEY" \
  https://api.iprout.com/usage

What happens near exhaustion?

Avoid aggressive retries after HTTP 429 because they do not restore capacity. Degrade optional enrichment gracefully, investigate unexpected usage, and change plans or key strategy deliberately. Keep traffic monitoring independent of the API response where possible so operators receive an alert even when requests are failing. Review key names and last activity to find loops, abandoned integrations, or unauthorized consumption.

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.

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 allowance per account
• Per-key attribution
• Pro caps contain individual workloads

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.