Which plans support restricted origins?
Free keys are intended for open server-side access. Paid plans add configurable origin allowlists.
| Plan | Restricted origins per key |
|---|---|
| Free | Not configurable |
| Starter | Up to 5 |
| Pro | Up to 10 |
What does exact matching mean?
https://app.example.com and https://www.example.com are different origins. A development port such as http://localhost:3000 must also be listed explicitly.
Can origins be edited later?
Key restrictions are fixed for that credential. Revoke and recreate the key to change its origin list, then deploy the replacement safely.
How should exact browser origin restrictions be implemented?
List each intended scheme, hostname, and port when creating a paid-plan key. Production, preview, www, apex, and local development origins are distinct values and should be approved deliberately. Keep this responsibility close to the IPRout client so the behavior documented in CORS Origin Restrictions for API Keys remains consistent across web requests, workers, and scheduled jobs.
How should exact browser origin restrictions be verified?
Test one exact allowed Origin and several near misses, including a different scheme, subdomain, and port. A successful server-side cURL request does not prove that browser CORS configuration is correct. Automate the stable cases and reserve live checks for controlled environments so verification is repeatable without consuming unnecessary production allowance.
How should exact browser origin restrictions be operated?
Track which deployments depend on every listed origin because settings are fixed for the credential. Replace the key through a controlled rotation when the hosting topology changes. Write down the owner and expected behavior so an alert or product change can be handled without reconstructing the original integration decisions.
Where does exact browser origin restrictions stop?
CORS governs browser response access and rejected origins do not consume lookup usage. It cannot prevent a copied public key from being submitted by non-browser software, so confidential integrations belong server-side. 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 exact browser origin restrictions?
Review the deployed implementation of CORS Origin Restrictions for 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 exact browser origin restrictions be revisited?
Revisit exact browser origin restrictions 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.