IPRout

Shared Quotas Across API Keys

Multiple API keys improve isolation and attribution, but they do not multiply plan capacity. Every successful lookup made by an account's keys contributes to the same monthly request total. Per-key usage and caps help control individual workloads inside that shared allowance. Review both levels before increasing traffic.

Last updated September 12, 2026

How is account usage calculated?

The account total is the combined usage of its active keys during the current month.

Why use separate keys then?

Separate keys let you revoke one workload, apply different origins, attribute consumption, and on Pro contain a workload with its own cap.

How do I monitor shared capacity?

Use GET /usage and alert on both remaining_requests at the account level and remaining_requests for individual keys. Review both values before increasing production traffic.

How should shared account allowance be implemented?

Model capacity at two levels: the account's monthly total and each credential's consumption or cap. Admission and fallback decisions should inspect the boundary relevant to the calling key. Keep this responsibility close to the IPRout client so the behavior documented in Shared Quotas Across API Keys remains consistent across web requests, workers, and scheduled jobs.

How should shared account allowance be verified?

Test one scenario where a key reaches its Pro cap while the account has room and another where the account reaches zero while a key appears below its cap. Automate the stable cases and reserve live checks for controlled environments so verification is repeatable without consuming unnecessary production allowance.

How should shared account allowance be operated?

Forecast the combined volume of every website, service, environment, and scheduled task. Named keys make attribution possible, while account-level alerts protect against aggregate exhaustion. Write down the owner and expected behavior so an alert or product change can be handled without reconstructing the original integration decisions.

Where does shared account allowance stop?

Unused cap on one key is not a private reserve, and adding keys does not create capacity. The shared quota remains the final monthly ceiling for all successful lookups. 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 shared account allowance?

Review the deployed implementation of Shared Quotas Across API Keys, 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 shared account allowance be revisited?

Revisit shared account allowance 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.

Continue building with IPRout

Test the API, browse runnable examples, or return to the documentation directory.

Get Developer KeyCode ExamplesAll Docs