Des workflows d’API qui s’exécutent dans la doc — Arazzo compris.
Un scénario est une séquence de requêtes déclarative : créer un animal, passer une commande, vérifier la commande — les valeurs d’une réponse chaînées vers la requête suivante. Il est livré avec votre documentation et s’exécute chez le lecteur, dans la même console d’essai que le reste de la doc.
CAPTURE RÉELLE, AFFICHÉE À 1:1
Déclaratif, jamais scripté.
Construit par capture, chaîné au clic.
Personne n’écrit du JSON de scénario à la main. Envoyez une requête dans la console d’essai — ou reprenez-en une de l’historique — et ajoutez-la comme étape. Cliquez une clé de la réponse observée pour l’extraire : {{petId}} ← /id, c’est fait. Les assertions se posent depuis la réponse observée ou depuis le schéma déclaré, un clic chacune ; une étape à qui il manque une variable suggère l’extraction qui la fournirait.
Avant le premier envoi, un panneau de prérequis répond à « pourquoi ça va échouer » — environnement, variables et auth nécessaires, vérifiés d’avance.
Un rapport pour les machines, un tutoriel pour les humains.
Partagé sans surprise.
Arazzo dans les deux sens — et livré avec la doc.
Les scénarios parlent Arazzo, le format de workflows de l’OpenAPI Initiative — l’import accepte les documents 1.0 et 1.1, l’export écrit du 1.1.0. En août 2026, tous les autres exécuteurs Arazzo vivent en CLI ou en CI — aucun autre produit de documentation n’exécute Arazzo dans le navigateur.
Déclarés dans la config, les scénarios sont livrés avec la documentation elle-même : les lecteurs les trouvent dans la navigation, et pinned: true en met un en avant sur la page d’accueil — typiquement le flux d’auth qu’on veut sous la main en arrivant. Une entrée peut même être le fichier Arazzo que votre CI exécute déjà, déclaré tel quel. features.scenarios: false retire la fonctionnalité entière pour les installations qui n’en veulent pas.
{
"scenarios": [
{
"id": "onboarding",
"title": "Onboarding",
"url": "/scenarios/onboarding.json",
"pinned": true
},
{ "id": "payments", "url": "/workflows/payments.arazzo.yaml" }
]
}Un workflow, trois lecteurs.
Le même document se lit en tutoriel interactif, se publie en recette pour agents — et revient en job de pipeline. Un panneau « Automatiser ce scénario » sur chaque page de scénario génère un job CI prêt à committer, qui exécute le document Arazzo du scénario via un runner tiers : GitHub Actions ou GitLab CI, Redocly Respect ou l’Arazzo Runner de Jentic.
Les variables voyagent en noms, branchés sur le coffre à secrets de votre CI — l’extrait ne porte jamais une valeur. Et le panneau nomme les écarts de compatibilité avant la copie : un runner qui annonce une révision Arazzo plus ancienne, ou aucune, est dit en toutes lettres. Le produit énonce sa propre frontière : « Cette documentation reste une page statique — elle ne planifie rien et n’exécute rien à votre place. »
# .gitlab-ci.yml
# Définissez ces variables CI/CD masquées :
# AUTH_TOKEN
create-a-payment:
image: python:3.12
script:
- pip install arazzo-runner
- arazzo-runner execute-workflow arazzo/create-a-payment.arazzo.json
--workflow-id create-payment --inputs "{\"auth.token\": \"$AUTH_TOKEN\"}"Voyez-le dans la démo.