C'est le navigateur qui bloque — voici les issues.

Les requêtes d’essai sont de simples fetch envoyés du navigateur du lecteur vers votre API. Rien ne transite par un serveur à nous — il n’y en a pas — ce qui veut aussi dire que rien ne peut contourner discrètement la same-origin policy du navigateur. Si la doc et l’API vivent sur des origines différentes, l’API doit autoriser l’origine de la doc via CORS, sans quoi le navigateur bloque l’appel avant même qu’il parte.

Quand un envoi échoue, ApiGlow ne hausse pas les épaules : l’échec est diagnostiqué dans l’interface — hors ligne, contenu mixte, CORS ou hôte injoignable, au conditionnel (« le plus probable ») parce que le navigateur cache les détails à la page.

Autoriser l’origine de la doc

La vraie correction est côté serveur : répondre au preflight avec un Access-Control-Allow-Origin nommant l’origine de la doc (ou * pour une API publique sans credentials), plus les méthodes et en-têtes que votre API utilise. Si la doc est servie depuis l’origine de l’API elle-même, il n’y a pas de requête cross-origin et rien à configurer.

Exposer les en-têtes qui valent d’être lus

Sans Access-Control-Expose-Headers côté API, le navigateur ne révèle qu’une courte liste d’en-têtes de réponse — rate limit, pagination et dépréciation restent invisibles même quand l’appel réussit, et ApiGlow le signale. Exposez-les et les diagnostics réseau retrouvent leur matière.

Il a un jumeau : Timing-Allow-Origin. Sans lui, une réponse cross-origin cache ses faits de transfert — les tailles lisent zéro, et les puces compression et cache ne s’affichent simplement pas. Deux en-têtes de réponse, une ligne chacun côté API, et le diagnostic réseau est complet.

Un proxy, si vous l’hébergez

tryIt.proxyUrl déclare un proxy CORS sous forme de gabarit — {{target}} est remplacé par l’URL cible encodée :

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

L’app ne fournit aucun proxy et n’en fait tourner aucun : c’est un crochet pour celui que vous hébergez et en qui vous avez confiance. Une fois configuré, il est proposé dans l’interface sur les échecs CORS.

L’auth par cookie de session

Pour une API authentifiée par un cookie de session httpOnly, le navigateur ne stocke ni n’envoie le cookie cross-origin par défaut. Posez tryIt.requestCredentials: "include", et respectez les contraintes serveur qui viennent avec : Access-Control-Allow-Credentials: true, un Access-Control-Allow-Origin explicite (pas *), et un cookie SameSite=None; Secure.

Le revers : "include" est incompatible avec Access-Control-Allow-Origin: * — le navigateur rejette le preflight même sans cookie à envoyer. Dans une installation multi-spec, posez-le sur l’entrée de spec concernée plutôt qu’à la racine.

OAuth2 ajoute deux exigences

Les flows dans le navigateur (Authorization Code + PKCE, client credentials) ont deux besoins côté enregistrement : le redirect_uri envoyé est l’URL de la page hôte sans son hash et doit être enregistré tel quel auprès du serveur d’autorisation, et le token endpoint doit autoriser l’origine de la doc en CORS, comme tout appel d’essai.

Ou éviter CORS tout court

openapi.spec — le schéma porté par la page — sort le téléchargement du schéma de l’équation, et une doc hébergée sur l’origine de l’API sort le reste : même origine, pas de preflight, et le défaut "same-origin" suffit.