API workflows that run inside the docs — Arazzo included.

Nobody hand-writes scenario JSON. Send a request in the try-it console — or pick one from history — and add it as a step. Click a key of the observed response to extract it: {{petId}} ← /id, done. Assertions come from the observed response or from the declared schema, one click each; a step missing a variable suggests the extraction that would provide it.

Before the first send, a prerequisites panel answers “why will this fail” — the environment, variables and auth the scenario needs, checked upfront.

Scenarios speak Arazzo, the OpenAPI Initiative’s workflow format — imports accept 1.0 and 1.1 documents, exports write 1.1.0. As of August 2026, every other Arazzo runner lives in a CLI or a CI pipeline — no other documentation product executes Arazzo in the browser.

Declared in the config, scenarios ship with the documentation itself: readers find them in the nav, and pinned: true features one on the home page — typically the auth flow you want at hand on arrival. An entry can even be the Arazzo file your CI already runs, declared as it stands. features.scenarios: false removes the entire feature for installs that don’t want it.

The same document renders as an interactive tutorial, publishes as an agent recipe — and comes back as a pipeline job. An “Automate this scenario” panel on every scenario page generates a ready-to-commit CI job that runs the scenario’s Arazzo document through a third-party runner: GitHub Actions or GitLab CI, Redocly Respect or Jentic’s Arazzo Runner.

Variables travel as names wired to your CI’s secret store — the snippet carries no value, ever. And the panel names compatibility gaps before you copy anything: a runner that claims an older Arazzo revision, or none at all, is said so in plain words. The product states its own boundary: “This documentation stays a static page — it schedules nothing and runs nothing on your behalf.”