Votre espace de travail API vit dans une interface graphique. Votre journée de travail se déroule dans un terminal. Chaque changement de contexte entre les deux coûte des secondes et de la concentration, et dans un pipeline CI ou une session d'agent IA, l'interface graphique n'est même pas une option. L'interface de ligne de commande (CLI) d'Apidog comble cette lacune : elle apporte l'ensemble de la plateforme Apidog, les tests, les points d'extrémité, les schémas, les environnements, les attentes de mock et la documentation, à l'invite de commande que vous avez déjà ouverte.
Une définition honnête avant toute chose. L'interface de ligne de commande (CLI) d'Apidog n'est pas un autre curl. Si vous voulez lancer une requête GET unique et examiner le JSON, curl et HTTPie le font déjà très bien, et le tour d'horizon des clients REST de terminal et TUI couvre le côté interactif. L'interface de ligne de commande (CLI) d'Apidog est un client pour votre espace de travail API lui-même : elle exécute les scénarios de test que vous avez construits, lit et met à jour le contrat API, et déplace les spécifications à l'intérieur et à l'extérieur du projet, le tout à partir de commandes qu'un script ou un agent peut appeler.
Ce que signifie "vit dans votre terminal" ici
Les outils HTTP de terminal gèrent une seule requête à la fois. L'interface de ligne de commande (CLI) d'Apidog opère au niveau du projet. Sa surface de commande s'étend sur plus de quarante groupes, et ils se regroupent en cinq tâches :
| Tâche | Commandes |
|---|---|
| Exécuter les tests | run, test-scenario, test-suite, test-case, test-data, test-report |
| Gérer le contrat | endpoint, schema, folder, common-parameter, response-component, security-scheme |
| Publier la documentation et les mocks | doc, docs-site, shared-doc, mock |
| Configurer et connecter | environment, variables, vault, database-connection, websocket, socketio |
| Opérer en équipe | branch, merge-request, runner, scheduled-task, audit-log, import, export |
Chaque commande prend en charge --help, la sortie est du JSON structuré, et la plupart des réponses incluent agentHints.nextSteps vous indiquant (ou à votre agent) ce qu'il faut exécuter ensuite. Ce dernier détail semble minime. Il change la façon dont l'outil est perçu : la CLI guide le flux de travail au lieu de supposer que vous l'avez mémorisé.
Installer en une seule commande
La CLI est distribuée sous forme de paquet npm (apidog-cli) et fonctionne sur macOS, Linux et Windows. Elle nécessite Node.js 16 ou une version ultérieure.
npm install -g apidog-cli
apidog --version
Connectez-vous ensuite avec un jeton d'accès API. Récupérez-le depuis l'application Apidog : cliquez sur votre avatar, ouvrez les Paramètres du compte et copiez le jeton sous Jeton d'accès API.
apidog login --with-token <YOUR_TOKEN>
Le jeton se trouve dans ~/.apidog/config.toml, alors gardez-le hors de vos dépôts et journaux ; en CI, passez-le par exécution avec --access-token à partir d'un secret à la place. Quatre drapeaux globaux couvrent la plupart des contextes : --project sélectionne le projet, --branch sélectionne la branche, --access-token annule la connexion enregistrée, et --api-base-url pointe la CLI vers un déploiement Apidog auto-hébergé. Le guide d'authentification Apidog CLI explique en détail les jetons pour la CI.
Exécutez les tests que vous avez construits visuellement
Voici le flux de travail autour duquel la CLI a été conçue. Vous créez un scénario de test dans l'éditeur visuel d'Apidog : requêtes chaînées, variables extraites d'une réponse et injectées dans la suivante, assertions sur le statut et le corps. Ensuite, vous l'exécutez partout où un shell existe.
# Copiez cette commande, IDs inclus, depuis l'onglet CI/CD du scénario
apidog run -t <scenario_id> -e <env_id> -r cli
La commande se termine avec le code 0 si toutes les assertions réussissent et un code non nul si quelque chose échoue, de sorte qu'un pipeline peut s'appuyer dessus sans aucune colle supplémentaire. Échangez -e pour pointer le même scénario vers des environnements de développement, de staging ou de production. Alimentez-le avec un fichier CSV ou JSON et il itérera le scénario sur chaque ligne, c'est ainsi que le test axé sur les données fonctionne sans dupliquer les étapes. Si vous partez de zéro, le tutoriel pas à pas sur l'API REST vous guide de l'installation à la première exécution réussie.
Les rapports sont disponibles en quatre formats : cli affiche les résultats étape par étape dans le terminal, tandis que html, json et junit sont enregistrés dans apidog-reports/ pour les tableaux de bord et les artefacts CI. Combinez-les librement, comme dans -r cli,junit. Le guide des rapports de test montre à quoi ressemble chaque format.
Pour les exécutions qui ne devraient pas dépendre de votre ordinateur portable, les commandes runner et scheduled-task gèrent les runners auto-hébergés et les exécutions programmées, la même machinerie derrière les tests API programmés dans Apidog.
Gérer le contrat API sans ouvrir l'application
C'est la partie qu'aucun autre outil de test de terminal n'offre. La même CLI qui exécute vos tests peut lire et écrire la définition de l'API elle-même :
apidog endpoint list --project <project_id>
apidog schema get <schema_id>
apidog environment list
apidog mock list
Les points d'extrémité, les schémas de données, les dossiers, les environnements, les variables, les schémas de sécurité et les composants réutilisables sont tous interrogeables et éditables. La commande mock gère les attentes de mock, les paires de requête-réponse fixes que votre serveur de mock renvoie. Les commandes doc et docs-site concernent la documentation publiée. Les points d'extrémité WebSocket et Socket.IO ont leurs propres groupes, et database-connection couvre les configurations de base de données que vos scénarios de test lisent.
L'importation et l'exportation supportent les formats importants : OpenAPI 3.x et Swagger 2.0 (la spécification sur laquelle la plupart des chaînes d'outils se standardisent), ainsi que les collections Postman. Cela fait de la CLI un pont dans les scripts de migration : tirez une spécification d'un système, poussez-la dans Apidog, et versionnez l'ensemble de l'échange.
apidog import openapi.json --project <project_id>
apidog export --format openapi
Conçu pour que les agents IA puissent le piloter
Les versions 2026 de la CLI s'appuient fortement sur une idée : un agent de codage IA devrait être capable d'opérer votre espace de travail API aussi sûrement qu'une personne. Quatre éléments permettent cela.
Premièrement, une sortie structurée. Chaque commande renvoie un JSON qu'un agent peut analyser, et agentHints.nextSteps lui indique ce qu'il doit faire après chaque résultat, y compris comment récupérer des erreurs.
Deuxièmement, un schéma d'entrée publié. apidog cli-schema list et apidog cli-schema get exposent la forme JSON exacte attendue par chaque commande d'écriture, et apidog cli-schema validate vérifie une charge utile avant que quoi que ce soit ne touche le projet. Le rituel d'écriture sécurisée est toujours le même : obtenir le schéma, générer le JSON, le valider, et seulement ensuite exécuter create ou update.
Troisièmement, une compétence empaquetée. La commande skill embarque les connaissances opérationnelles de la CLI sous une forme que les agents chargent directement, ce qui est l'histoire derrière pourquoi nous avons construit la compétence Apidog CLI. Selon nos propres mesures, les agents travaillant via le schéma CLI ont utilisé environ 30 % moins d'appels d'outils et 25 % moins de jetons que les agents devinant les charges utiles ; les chiffres sont détaillés dans cette analyse.
Quatrièmement, des portes d'autorisation. Par défaut, les écritures provenant de l'IA vers une branche sont bloquées jusqu'à ce qu'un humain active les Permissions d'édition IA externes (dans le client Apidog 2.8.32 ou ultérieur, sous Paramètres du projet, Paramètres des fonctionnalités, Paramètres des fonctionnalités IA). L'alternative est une branche IA : une branche isolée où un agent importe les ressources dont il a besoin, effectue ses modifications, et renvoie le résultat sous forme de demande de fusion pour examen. Les branches IA non utilisées s'auto-archivent après 24 heures, de sorte que les expériences ne s'accumulent pas. Votre contrat API reste révisable même lorsqu'un agent rédige le premier brouillon.
Ce que l'Apidog CLI n'est pas
Trois limites, énoncées clairement, car choisir des outils sur des informations honnêtes est préférable à la découverte des lacunes plus tard.
Ce n'est pas un client de requête interactif. Il n'y a pas de commande qui tape une requête POST ad hoc et affiche la réponse de manière esthétique ; curl, HTTPie et les clients TUI s'en chargent, et ils le font mieux.
Ce n'est pas open source. Le package est propriétaire, npm est le seul canal d'installation, et faire quoi que ce soit au-delà de --help nécessite un compte Apidog. Le niveau gratuit couvre l'ensemble du flux de travail décrit ici, mais si une licence auditable est une exigence stricte, un runner open source est la recommandation honnête.
Ce n'est pas autonome. La CLI est la branche terminale de la plateforme : les scénarios, les points d'extrémité et les environnements vivent dans votre projet Apidog, et non dans des fichiers locaux. C'est le compromis qui vous offre une source unique de vérité pour la conception, les tests, le mocking et la documentation.
Où il s'intègre dans la boîte à outils du terminal
Par rapport aux autres runners, la différence réside dans l'endroit où la création a lieu. Newman et la CLI Postman exécutent des collections créées dans Postman ; Hurl et Bruno exécutent des tests créés sous forme de fichiers texte ; la CLI Apidog exécute des scénarios créés dans un éditeur visuel qui contient également votre contrat, vos mocks et votre documentation. La comparaison Apidog CLI vs Newman va plus loin, et le domaine complet est classé dans le tour d'horizon des meilleurs outils de test d'API basés sur le terminal.
Une configuration fonctionnelle pour la plupart des équipes : gardez curl ou xh en mémoire musculaire pour les requêtes ponctuelles, et laissez apidog run prendre en charge les suites en CI. Le tutoriel GitHub Actions propose un pipeline prêt à copier-coller pour commencer.
FAQ
L'Apidog CLI est-il gratuit ? Oui. Le package s'installe gratuitement depuis npm, et le niveau gratuit d'Apidog couvre la création de scénarios et leur exécution via la CLI. Les forfaits payants ajoutent des fonctionnalités à l'échelle de l'équipe, pas un accès CLI de base.
Remplace-t-il curl ou HTTPie ? Non, et il n'essaie pas. Ces outils envoient des requêtes ad hoc ; l'Apidog CLI exécute des scénarios de test enregistrés et gère les ressources du projet. La plupart des terminaux finissent par avoir les deux.
Peut-il fonctionner entièrement sans interface graphique (headless) en CI ? Oui. Authentifiez-vous avec --access-token à partir d'un secret CI, exécutez apidog run avec l'ID de votre scénario, et contrôlez la construction en fonction du code de sortie. Aucune application de bureau n'est nécessaire sur le runner.
Quels formats peut-il importer et exporter ? OpenAPI 3.x, Swagger 2.0 et les collections Postman, dans les deux sens. Cela couvre les migrations entrantes et les intégrations sortantes.
Comment les agents IA l'utilisent-ils en toute sécurité ? Grâce au rituel schéma-valider-écrire et aux portes d'autorisation : cli-schema validate intercepte les charges utiles malformées avant qu'elles n'arrivent, et les branches IA maintiennent les modifications des agents isolées jusqu'à ce qu'un humain les fusionne. Voyez-le fonctionner au sein d'un agent dans comment utiliser l'Apidog CLI dans Claude Code.
Le terminal est l'endroit où vos tests s'exécutent déjà et où vos agents travaillent déjà. Y placer également le client API supprime le dernier changement de contexte. Téléchargez Apidog, installez la CLI depuis npm et exécutez un scénario de bout en bout ; la page Apidog CLI contient la référence complète des commandes lorsque vous êtes prêt à aller au-delà de run.