The browser blocks it — here is the way through.

Try-it requests are plain fetch calls from the reader’s browser to your API. Nothing passes through a server of ours — there isn’t one — which also means nothing can quietly work around the browser’s same-origin policy. If the docs and the API live on different origins, the API must allow the docs’ origin via CORS, or the browser blocks the call before it leaves.

When a send fails, ApiGlow does not shrug: the failure is diagnosed in the UI — offline, mixed content, CORS, or an unreachable host, phrased as “most likely” because the browser hides the details from the page.

Allow the docs’ origin

The clean fix is server-side: answer the preflight with Access-Control-Allow-Origin naming the docs’ origin (or * for a public API without credentials), plus the methods and headers your API uses. If the docs are served from the API’s own origin, there is no cross-origin request and nothing to configure.

Expose the headers worth reading

Without Access-Control-Expose-Headers on the API side, the browser reveals only a short safelist of response headers — rate-limit, pagination and deprecation headers stay invisible even when the call succeeds, and ApiGlow flags it. Expose them and the network insights get their material back.

It has a sibling: Timing-Allow-Origin. Without it, a cross-origin response hides its transfer facts — sizes read zero, and the compression and cache chips simply don’t render. Two response headers, one line each on the API, and the insights strip is whole.

A proxy, if you host one

tryIt.proxyUrl declares a CORS proxy as a template — {{target}} is replaced by the encoded target URL:

{ "tryIt": { "proxyUrl": "https://proxy.example.com/?url={{target}}" } }

The app ships no proxy and runs none: this is a hook for one you host and trust. When configured, it is suggested in the UI on CORS failures.

Session-cookie auth

For an API authenticated by an httpOnly session cookie, the browser neither stores nor sends the cookie cross-origin by default. Set tryIt.requestCredentials: "include", and meet the server-side constraints that come with it: Access-Control-Allow-Credentials: true, an explicit Access-Control-Allow-Origin (not *), and a SameSite=None; Secure cookie.

The flip side: "include" is incompatible with Access-Control-Allow-Origin: * — the browser rejects the preflight even with no cookie to send. In a multi-spec installation, set it on the spec entry that needs it rather than at the root.

OAuth2 adds two requirements

The in-browser flows (Authorization Code + PKCE, client credentials) have two registration-side needs: the redirect_uri sent is the host page’s URL without its hash and must be registered as-is with the authorization server, and the token endpoint must allow the docs’ origin in CORS like any other try-it call.

Or avoid CORS entirely

openapi.spec — the schema carried by the page — removes the schema fetch from the equation, and docs hosted on the API’s own origin remove the rest: same origin, no preflight, and the "same-origin" default just works.