Fix CORS errors without touching the API
You can't add CORS headers to an API you don't own. Send the request through ProxifyEdge and get the response back with the headers your browser needs, from localhost today and your production domain tomorrow.
Access to fetch at 'https://api.example.com/v1/items' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
HTTP/2 200
access-control-allow-origin: http://localhost:5173
x-proxify-ratelimit-remaining: 9999
The API works in curl. The browser refuses it.
Browsers stop a page from reading a response from another origin unless that server sends an Access-Control-Allow-Origin header. Many third-party APIs never send it, because they were built to be called from servers.
The usual fixes all cost time: a backend route that forwards the request, a dev-server proxy that disappears when you deploy, or a browser extension that only works on your own machine.
How ProxifyEdge helps
Configured from the dashboard, enforced on every request.
-
Test keys for development
A test key answers any origin, so it works from localhost, preview deployments and online editors while you build.
-
Live keys locked to your site
Switch to a live key and list your production origins. Pages on any other site are refused.
-
Upstream tokens stay server-side
Store an API token in the secrets vault and reference it as {{secret.NAME}}. It is inserted into the outbound request and never reaches the browser.
-
Limits you can read
Proxied responses carry X-Proxify-RateLimit-Limit, -Remaining and -Reset, so your app knows where it stands before it is cut off.
-
Record and replay
Record real responses into a cassette, then replay them for offline work and deterministic tests.
-
Private addresses refused
The SSRF guard refuses internal and private network targets, so the proxy cannot be pointed at your own infrastructure.
How it fits your workflow
-
Create an account
You get an API key straight away. Copy it: it is shown once.
-
Develop with a test key
Switch the key to test while you work from localhost and preview URLs.
-
Prefix the URL
Send requests to /proxy?url=… with your key in the X-API-Key header.
-
Go live
Switch the key to live and list the origins your production site is served from.
Example
Swap one URL, keep your fetch call
- Encode the target URL so its own query string survives the trip.
- Status codes and headers come from the upstream API; ProxifyEdge adds the CORS headers.
- Use a test key while developing and a live key, locked to your origins, in production.
const PROXY = 'https://api.proxifyedge.com/proxy';
export async function getItems() {
const target = 'https://api.example.com/v1/items';
const res = await fetch(`${PROXY}?url=${encodeURIComponent(target)}`, {
headers: { 'X-API-Key': import.meta.env.PUBLIC_PROXIFY_KEY },
});
if (!res.ok) throw new Error(`Upstream returned ${res.status}`);
return res.json();
}Questions
Something else? Get in touch or read the docs.
Is it safe to ship an API key in my frontend?
A live key only answers the origins you list, so other websites cannot use it from their pages. Anyone can still copy a public key and call ProxifyEdge from a script, which is why every key has quotas and rate limits, and why signed URLs exist for requests that need more control. Keep upstream credentials in the secrets vault, never in your code.
Do I need to change my backend or the API I am calling?
No. ProxifyEdge sits between the browser and the API. The only change is the URL your frontend requests.
Which HTTP methods and bodies are supported?
GET, POST, PUT, PATCH and DELETE, with request bodies and headers forwarded to the upstream API. Headers meant for ProxifyEdge itself, such as X-API-Key, are not passed on.
What happens when I reach my quota?
Further requests are refused with an error that says which limit was reached, until the quota resets. The X-Proxify-RateLimit headers on every proxied response tell you how close you are.
