Explorer une définition d’API et créer du code de requête

Collez la définition, sélectionnez un endpoint et renseignez des paramètres d’exemple. Vérifiez le code avant de l’exécuter dans votre client API.

Fonctionne localement dans votre navigateur
Définition d'API

Collez un document OpenAPI 3.x ou Swagger 2.0 dans JSON ou YAML. Rien n'est téléchargé ou récupéré par cet outil.

Opérations disponibles
Analysez une définition pour parcourir ses points de terminaison.
Générateur de requêtes

Choisissez un point de terminaison ci-dessus pour créer ses champs de chemin, de requête, d'en-tête et de corps.

Select an endpoint to generate a cURL command.
Select an endpoint to generate Fetch code.

Explorez une spécification API sans l'envoyer nulle part

OpenAPI Explorer lit les JSON ou YAML locaux, fait apparaître les points de terminaison et les entrées requises et crée des extraits de requête que vous pouvez ajuster avant de les utiliser dans votre propre client API. Il n'envoie délibérément pas de requêtes, de jetons ou de spécifications à un autre service.

Comment construire une requête à partir d’une définition

Collez une définition OpenAPI 3.x ou Swagger 2.0 pour lister toutes les opérations déclarées, remplir les paramètres documentés et copier un extrait cURL ou Fetch pour le point d’accès choisi.

La définition, l’URL du serveur et le jeton Bearer restent dans le navigateur. Le document est analysé localement et cette page n’envoie aucune requête à votre API.

  1. Collez la définition dans l’éditeur, en JSON ou YAML, ou cliquez sur Load example pour partir d’un exemple.
  2. Cliquez sur Analyze definition. La liste des opérations affiche chaque méthode et son chemin ; si le document n’a pas de marqueur de version ou aucune opération sous paths, la ligne d’état le signale.
  3. Choisissez une opération pour construire son formulaire de paramètres à partir de la définition : champs de chemin, de requête et d’en-tête, plus un corps de requête lorsque la définition en décrit un.
  4. Remplissez les champs obligatoires. Tous les paramètres documentés doivent être présents avant de générer le code, et la ligne d’état nomme le premier qui manque encore.
  5. Cliquez sur Generate request code, puis sur Copy cURL ou Copy Fetch. Renseignez d’abord l’URL du serveur ou un jeton Bearer si le point d’accès en a besoin.

Ce que le générateur fait et ne fait pas

Quelles définitions sont acceptées

OpenAPI 3.x et Swagger 2.0 sont lus, en JSON ou YAML, et le marqueur de version détermine l’interprétation des serveurs, des paramètres et des corps de requête. Un document sans aucun des deux marqueurs est refusé, avec un message indiquant le champ racine manquant.

Les lignes d’opération proviennent de l’objet paths : une ligne par méthode, libellée avec le chemin et le résumé de l’opération, ou avec « No summary provided » lorsque la définition n’en fournit pas.

Les extraits générés sont un point de départ

KivTools rédige la requête à partir de la définition et ne l’exécute jamais. Cette page n’envoie rien à votre API : un jeton saisi sert uniquement à remplir le texte de l’extrait.

L’extrait reprend les paramètres et en-têtes documentés par la définition. Tout ce qu’elle ne décrit pas — nouvelles tentatives, signature, pagination, flux OAuth — doit être ajouté dans votre propre client.

Questions fréquentes

Cet outil appelle-t-il mon API ?

Non. Il lit la définition et rédige le code de la requête ; la requête n’est jamais exécutée ici, donc aucun trafic ne parvient à votre API depuis cette page.

Quels formats de définition sont pris en charge ?

OpenAPI 3.x et Swagger 2.0, en JSON ou YAML. Le marqueur de version à la racine du document détermine l’interprétation de chaque champ.

Outils récents :