This is a browser client, and that defines its rules
Because every request originates from the Fetch API inside your tab, it lives under the same restrictions as the JavaScript on any website you visit. That’s a feature for testing your own front-end’s perspective — “will my SPA actually be allowed to call this endpoint?” — and a hard limit when probing third-party APIs that never intended to be hit from a browser.
| You can | You can’t |
|---|---|
| Call your own CORS-enabled APIs | Bypass the same-origin policy |
| Set Authorization, custom headers | Set forbidden headers (Host, Origin, Referer, Cookie) |
| Inspect status, headers, body | Read a response the server didn’t CORS-permit |
| Test JSON, form, and text bodies | Skip the preflight on a non-simple request |
The CORS preflight, demystified
When a request isn’t “simple” (see the FAQ), the browser quietly sends an OPTIONS request first, advertising the method and headers it intends to use via Access-Control-Request-Method and Access-Control-Request-Headers. The server must answer with matching Access-Control-Allow-Methods / Access-Control-Allow-Headers and an Access-Control-Allow-Origin that includes your origin. Only then does the real request go out. If the preflight is rejected — or the server doesn’t handle OPTIONS at all — you get TypeError: Failed to fetch and never see a status code, because the actual request was never sent. That confusing “no response” failure is almost always a failed preflight.
Auth schemes, at a glance
The builder lets you set the Authorization header by hand; knowing the shape of each scheme saves a round trip:
- Bearer token —
Authorization: Bearer eyJ…. The mind-the-gap classic: the literal wordBearer, one space, then the token. A missing space is the most common 401 on a token you know is valid. - Basic auth —
Authorization: Basic base64(user:pass). Base64, not encryption — only meaningful over HTTPS. - API key — often a custom header like
X-API-Key: …rather thanAuthorization; check the provider’s docs for the exact header name.
When to stop fighting the browser
If an endpoint genuinely won’t return CORS headers for a browser origin, that’s the signal to move the call server-side. A tiny backend proxy — or a serverless function — makes the request from a context with no same-origin policy, attaches the secret server-side (keeping it out of client code entirely), and returns the result to your front-end with your own permissive CORS headers. This pattern is not a workaround so much as the correct architecture: third-party secrets don’t belong in browser-reachable JavaScript in the first place.