1. Use your own API key
Create an account and replace YOUR_API_KEY with your CORSPROXY key. Use URLSearchParams to encode the target URL, including its own query parameters. CORSPROXY and upstream API credentials have different roles.
2. Register the published app domain
Register the website making the browser request, rather than the remote API, image, or feed host. Check the dashboard’s normalized domain preview. On shared hosting, a custom domain can give your project a more specific registered scope.
A successful playground test confirms the target request path; it does not confirm that your deployed app’s origin is registered.
3. Check content types, features, and traffic
Free browser requests work on deployed domains within their limits. Raw images and PDFs need Hobby or higher; image transformations have separate plan allowances. Production is required for JSON conversion, extraction, explicit caching controls, and server-side requests.
Estimate monthly requests and bandwidth using actual response sizes. Monitor usage in the dashboard and choose a plan with enough room for your application.
4. Handle HTTP failures and cancellation
Check response.ok before parsing data. Set a bounded request timeout, abort work your app no longer needs, and show an actionable message. A 401, 403, or 429 can come from CORSPROXY policy or the upstream provider; inspect the response before choosing a recovery step.
5. Keep upstream secrets on your backend
Browser code exposes tokens it sends. Use your backend for private provider credentials, and choose Production if that backend sends requests through CORSPROXY. Registering an app domain does not hide an upstream secret.
6. Test the deployed site
Open your published app using its intended key. Test a successful response, a failed upstream request, and the account’s usage reporting. Test any redirects, downloads, or WebSocket integrations separately from browser fetch.