How should a multi-website key map be designed?
List each production site, nonproduction environment, expected monthly volume, browser origin, and operational owner before creating credentials. Give each important trust boundary a descriptive key. Starter commonly separates production from staging or a second site; Pro can divide up to 5 active keys among client sites, products, workers, or environments. Do not encode the secret in the key name or reuse one browser key across unrelated customers.
How should capacity be allocated?
Estimate normal and peak traffic for every website, then leave shared account headroom for critical services. On Pro, create lower caps for staging, secondary sites, or bounded client workloads. A key that reaches its cap receives HTTP 429 while other keys can continue only while shared capacity remains. Caps contain consumption; they do not reserve requests or create separate billing pools.
How should browser origins be configured?
Enter each exact scheme, hostname, and port that should make direct browser requests. Preview domains and localhost ports require their own entries. IPRout does not count a lookup rejected by its origin check against usage, but the key remains visible to browser users. Prefer a server-side integration for confidential credentials and use origin restrictions as an additional browser boundary.
How is one site changed without disrupting the others?
Create a replacement key with the new immutable origins and cap, deploy it to the selected website, test from its real environment, and confirm activity in GET /usage. Revoke the previous key only after the replacement works. Because every other website has its own credential, their deployments do not need to change during this rotation or retirement.
Which credential boundaries should be used?
Assign a descriptive key to each important application or environment when the plan allows it. Free supports 1 active key, Starter 2, and Pro 5. Separate credentials improve attribution, independent revocation, and rotation, but all requests continue to consume one shared monthly account allowance. IPRout documents application key controls; it does not currently claim member invitations, team roles, or role-based key permissions.
How should a secret be protected?
Store the value in a server-side environment or secret manager, never in source control, public browser code, screenshots, query strings, or broadly readable logs. Redact authentication headers at application, proxy, and observability layers. Treat accidental disclosure as compromise: review activity, create a correctly restricted replacement, deploy and verify it, then revoke the exposed credential rather than assuming obscurity will protect it.
How should problems be diagnosed step by step?
Reduce the integration to one authenticated cURL request from trusted infrastructure, using GET /ip/8.8.8.8 as the known explicit fixture. Record the HTTP status, content type, elapsed time, and safely redacted body. If that succeeds, compare the application URL, headers, proxy behavior, timeout, and JSON model. If it fails, separate authentication, validation, capacity, transport, and server categories before changing code. Check GET /usage after 429, compare exact browser Origin values after CORS failure, and confirm the deployed environment received the intended secret. Do not rotate, retry, or increase limits blindly; preserve enough controlled evidence to identify the boundary that actually failed.
How should this behavior be tested?
Create unit fixtures for successful lookup or usage data, nullable optional fields, unknown additive properties, and every relevant error status. Mock timeouts and malformed intermediary responses so the client never mistakes an HTML proxy page for valid JSON. Run a small integration test with a designated nonproduction key and 8.8.8.8, inject the secret through CI, and keep live calls out of ordinary unit-test loops.
What privacy and accuracy boundaries apply?
IP intelligence is approximate network context. It does not prove identity, residence, billing country, precise device position, or individual ownership of a network organization. Retain only the source and derived fields required for the product purpose, restrict access, define deletion, and let users correct meaningful defaults. Security, financial, legal, or physical-location decisions require additional verified evidence and appropriate professional review.
Which plan and usage limits apply?
The 7-Day Developer Key provides 1,000 evaluation requests. Free includes 10,000 monthly requests and 1 active key. Starter includes 100,000 requests, 2 active keys, and up to 5 exact CORS origins per key. Pro includes 1,000,000 requests, 5 active keys, up to 10 origins per key, and a configurable 100 to 1,000,000 cap at key creation. Active keys share the account allowance.
| Plan | Monthly requests | Active keys |
|---|---|---|
| Free | 10,000 | 1 |
| Starter | 100,000 | 2 |
| Pro | 1,000,000 | 5 |
What should happen before release?
Confirm the endpoint and response model, validate URL construction, keep the secret outside source, set timeout and status-aware retry behavior, and test the real deployment environment. Add monitoring for latency, errors, shared usage, and per-key consumption. Document the owner, purpose, expected volume, fallback, retention, and rotation procedure. Review the implementation again whenever traffic, hosting origins, plan limits, or product decisions materially change.
External references
Continue with the standards and official documentation most relevant to this guide.