API Testing: How to Send a Token and Fix CORS Errors

Symptom: the request won't go through or returns nothing

You fill the URL and params in an API tester, hit send, and either the browser console turns red (CORS) or you get 401/403/405. Troubleshoot in order of easiest first.

1. Sending a Token: how to set the Authorization header

Most authenticated endpoints rely on a token in the request header. In the API Tester on ToolVault:

1. Switch to the "Headers" area;
2. Add Key = Authorization, Value = Bearer <your-token> (note the space after Bearer);
3. For API-key mode, it's usually Key = X-API-Key, Value = <key>.

Note: many 401s are not a wrong token but a missing Bearer prefix or a stray newline. Send the header verbatim via the tool, then compare with what the backend expects.

2. CORS errors: whose problem is it

CORS (Cross-Origin Resource Sharing) is a browser security policy, unrelated to the data the server returns. It looks like:

Access to fetch at 'https://api.xxx.com' from origin 'https://wcytcn.com'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header

Key point: a front-end tool cannot "bypass" CORS — it's a protocol-level restriction. The real fix is always backend config or a same-origin proxy.

The 90-second devtools sequence that settles it

When a request fails, resist the urge to change code. Open DevTools → Network and read three fields, in this order:

1. Status column: (failed) with a CORS console error means the browser blocked it — but note whether the request reached the server (the "preflight" row tells you). 401/403 means it arrived and was refused: that's an auth problem wearing a CORS costume
2. Response headers on the preflight OPTIONS row: Access-Control-Allow-Origin, -Headers, -Methods — the exact miss is visible here. No OPTIONS row at all? The request wasn't cross-origin (or the browser cached a preflight — check "Disable cache" and retry)
3. Request headers on the actual row: is Authorization present? A "simple request" that got upgraded to preflight (because of the auth header) plus a server that ignores OPTIONS is the single most common compound failure

Three fields, ninety seconds, and you know which side owns the fix.

Where the token lives: header, query, or cookie

The preflight tradeoff is real but cheap (see the preflight tax section below); the log-leakage tradeoff is not cheap. Default to the header.

3. Other frequent errors

How to locate step by step

Open the API Tester:

1. Enter the URL, try GET to confirm connectivity;
2. Add Headers (auth) and Body (JSON), switch method;
3. Read "status code" and "response headers", compare with the table above;
4. To reproduce in code, use curl-to-code to generate it.

Check status meanings anytime via HTTP Status Codes.

FAQ

Why does Postman work but the browser throws CORS?

Postman doesn't enforce the browser's same-origin policy — it just sends. The browser does the CORS check for you, so the difference is the browser, not the API.

Can the tool bypass CORS for me?

No, and it shouldn't. CORS protects users. The correct fix is backend whitelisting or proxying through your own server.

401 vs 403 — what's the difference?

401 = no/invalid credential (unauthenticated); 403 = valid credential but no permission (authenticated, denied). Fix 401 (token correct) before worrying about 403.

Provided by ToolVault. Related tools: HTTP Status Codes, curl-to-code, HTTP Method Cheatsheet. Visit the home page for more developer tools.

The preflight tax and how to shrink it

Every non-simple request (custom headers like Authorization, JSON bodies, non-GET methods other than POST) triggers an OPTIONS preflight — a full round-trip before the real request. At scale this doubles latency for API-first frontends. Three reductions: Access-Control-Max-Age: 86400 lets browsers cache the preflight (per-URL, Chrome caps at 2 hours but Firefox honors 24); serving preflights from the CDN edge instead of your origin; and keeping public GET endpoints "simple" (no custom headers, standard content types) so they skip preflight entirely. If your monitoring shows OPTIONS volume rivaling GET, the preflight tax is already material.

A three-line curl judgment that replaces guessing

CORS confusion often masks a plain server error. Test without the browser first: curl -i -X OPTIONS https://api.example.com/endpoint -H "Origin: https://yourapp.com" -H "Access-Control-Request-Method: POST" — the response must carry Access-Control-Allow-Origin. Then the real request with curl -i and the browser-like headers. If curl succeeds where the browser fails, it is CORS; if curl fails too, fix the server (or your token) before touching CORS headers. Browser DevTools' network panel labels preflights explicitly — filter by OPTIONS to see the actual failing hop instead of the misleading red on the real request.

Credentials mode: the asterisk that forbids

Access-Control-Allow-Origin: * is illegal together with credentials — when the frontend sets credentials: 'include' (cookies, some auth headers), the server must echo the exact origin plus Access-Control-Allow-Credentials: true. A wildcard-with-credentials response is rejected by the browser outright, and the error message rarely mentions credentials. This single rule explains a large share of "works in incognito, fails logged-in" reports.

Implementer's note

One detail from building the same-origin proxy echo: browser fetch hides certain response headers (Set-Cookie and friends), so to show users the server's bare headers the proxy must explicitly forward a whitelist and mark what browser policy swallowed — "seeing the raw server response" takes one more engineering layer in the browser than you would expect.