Le client d’API vit dans la doc.

Une console, pas un bouton « Try it out ».

Chaque opération affiche un formulaire construit depuis son propre schéma : paramètres de chemin, de requête, d’en-tête et de cookie avec leur sérialisation réelle — style, explode, deepObject, allowReserved — et un éditeur de corps qui connaît le type de média. Un oneOf discriminé obtient un sélecteur de variante, pas une zone JSON brute.

La requête est un vrai fetch depuis le navigateur du lecteur vers votre API. Rien n’est relayé, puisqu’il n’y a ici aucun serveur pour le faire.

Quand un appel échoue, la panne est nommée plutôt que devinée : hors ligne, contenu mixte, bloqué par CORS, ou simplement injoignable. Les en-têtes de réponse sont relus comme du renseignement — quotas, Retry-After, Deprecation et Sunset, pagination Link, identifiants de corrélation.

Ce sont les environnements qui portent les secrets.

Un environnement porte une URL de base, des variables et des en-têtes par défaut, et se colore pour que personne n’envoie du trafic de recette en production par mégarde. {{var}} est interpolé juste avant le départ de la requête — et si une variable manque, l’envoi est bloqué au lieu d’expédier le littéral.

Les valeurs sensibles sont masquées dans l’interface et expurgées de tous les exports. Les flux OAuth2 se déroulent dans le navigateur avec PKCE ; quand la page hôte détient déjà une session, elle peut fournir un jeton au lecteur sans qu’ApiGlow n’en stocke jamais un.

Un environnement entier se transmet à un collègue par un simple lien de configuration, construit de zéro sans avoir à le créer localement. Les déploiements verrouillés posent environmentsLocked et les lecteurs reçoivent les environnements que vous avez livrés, tels quels.

{
  "environments": [
    {
      "name": "Production",
      "url": "https://api.example.com",
      "variables": { "token": { "value": "", "sensitive": true } }
    }
  ]
}

Dix langages d’extrait — et le sens inverse aussi.

Chaque requête produit un extrait copiable en cURL, fetch, Node, Python, PHP, Ruby, Java, C#, Go ou HTTPie — régénéré à la volée quand le formulaire change, si bien que l’extrait est toujours l’appel que vous avez sous les yeux.

Le sens que les outils oublient, c’est celui du retour. Collez une commande cURL, déposez une collection Postman v2.1 ou un fichier HAR, et vous atterrissez dans une console pré-remplie où méthode, en-têtes et corps ont été reconnus. Les requêtes s’exportent en cURL, Postman, Markdown ou HAR, secrets expurgés par défaut.

L’historique appartient au lecteur, et il y reste.

Chaque appel est conservé dans l’IndexedDB du lecteur — filtrable, rejouable, borné pour ne pas croître sans limite. Une page d’opération montre ses appels récents ; la vue d’ensemble montre ce qui sert le plus.

Rien ne quitte le navigateur. Il n’y a pas de compte à créer, et aucun serveur où l’envoyer.

Un workflow est un document, pas un script.

Un scénario est une suite déclarative de requêtes. Capturez-la depuis la console, chaînez une valeur en cliquant dessus dans une réponse, livrez-la avec votre documentation. Là où l’industrie répond « chaîner des requêtes » par du JavaScript, ApiGlow répond « cliquez la réponse » — ce qui explique aussi qu’il n’y ait aucune surface de script à auditer.

Deux façons de l’exécuter : « tout lancer » produit un rapport étape par étape, et le mode pas à pas exécute chaque requête dans la vraie console, transformant un scénario écrit en tutoriel interactif. Les étapes portent des délais, continueOnFailure, quatre opérateurs d’assertion et des extractions JSONPath.

Les scénarios s’importent et s’exportent en Arazzo 1.1, le format de workflow de l’OpenAPI Initiative — et s’exportent encore en job GitHub Actions ou GitLab CI qui fait passer le même document dans un exécuteur tiers, les secrets transmis par nom, jamais par valeur.

{ "features": { "tryIt": false, "scenarios": false } }