How do I send a Bearer token?
Bearer authentication works consistently across HTTP clients and is the recommended form.
curl -H "Authorization: Bearer YOUR_API_KEY" https://api.iprout.com/ipCan I use X-API-Key?
Yes. Use the alternative header when it better fits your gateway or HTTP client.
curl -H "X-API-Key: YOUR_API_KEY" https://api.iprout.com/ipHow should keys be stored?
Read keys from a secret manager or server environment. Rotate a key immediately if it appears in source control, logs, screenshots, or frontend bundles.
- Use separate named keys for separate services
- Apply CORS restrictions to browser-facing integrations
- Revoke old keys after rotation
How should API key authentication be implemented?
Choose one supported header convention for the client and inject its value from a server-side secret store. Centralizing header creation makes redaction, rotation, and auditing consistent across lookup and usage calls. Keep this responsibility close to the IPRout client so the behavior documented in API Key Authentication remains consistent across web requests, workers, and scheduled jobs.
How should API key authentication be verified?
Exercise a valid key, a missing header, and a deliberately invalid key. The latter two must produce a controlled 401 path and must not be retried as if they were temporary network failures. Automate the stable cases and reserve live checks for controlled environments so verification is repeatable without consuming unnecessary production allowance.
How should API key authentication be operated?
Associate each credential with an application owner and deployment purpose outside the secret value. Monitor last use and monthly consumption so abandoned or unexpectedly active credentials are visible during review. Write down the owner and expected behavior so an alert or product change can be handled without reconstructing the original integration decisions.
Where does API key authentication stop?
CORS can restrict browser origins on paid keys, but it does not make a key embedded in JavaScript confidential. Server-side storage remains the appropriate boundary for credentials that must stay secret. 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 API key authentication?
Review the deployed implementation of API Key Authentication, 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 API key authentication be revisited?
Revisit API key authentication 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.