What’s New in Arazzo 1.1? The Latest OpenAPI Workflow Spec Release

With version 1.1.0, the OpenAPI Initiative has extended Arazzo for the first time since the 1.0.1 patch. Arazzo describes multi-step API workflows, the order in which several API calls add up to one business flow. The new release widens what the spec can express in three places, with AsyncAPI support, with workflows calling other workflows, and with data extraction from responses.

What Arazzo is in the first place, and how it relates to OpenAPI, is covered in What is Arazzo. This article focuses on the 1.1.0 additions and on what they change in real projects.

The version history at a glance

Arazzo follows semantic versioning. The first public release, 1.0.0, shipped in May 2024. Roughly a year later, the 1.0.1 patch sharpened some wording and cleared up minor ambiguities. Version 1.1.0 is the first release to introduce new fields.

For day-to-day use, the digit after the dot is what counts. A minor release adds capabilities without removing any. If you maintain a 1.0 file today, you keep using it as is and adopt the new fields exactly where they earn their place.

The fact that the first functional addition arrives a year and a half after the initial release also says something about the specification itself. Arazzo grows slowly, in small, backward-compatible steps. For teams building on it, that calm cadence is an advantage, because existing workflows need no rework with every release.

What the AsyncAPI support enables

The most visible addition concerns AsyncAPI. Until now, Arazzo only accepted OpenAPI and other Arazzo documents in its sourceDescriptions field. Every source therefore described synchronous request-response calls. Version 1.1.0 additionally allows AsyncAPI descriptions as sources.

The background is the spread of event-driven architectures. Many systems communicate over synchronous REST calls and, at the same time, over message brokers, webhooks, and event streams. AsyncAPI has established itself as the description language for exactly that asynchronous side. By accepting those descriptions as sources, Arazzo connects a workflow to both worlds.

A workflow can now contain steps that send or receive messages. A sending step fires an event, a receiving step waits for an incoming message. Both kinds support correlation identifiers, which match a response to its original request, and timeouts for the case where an expected message stays out.

The step waits for an incoming message, checks via successCriteria whether it reports the expected state, and publishes selected values from the message as outputs. To the rest of the workflow, a step like this behaves like any other. It delivers outputs that later steps consume. The only difference is that the output comes from a message instead of the response to a synchronous call.

The reverse case, a sending step, is just as useful. A workflow can fire an event at a defined point, a notification to a downstream system, say, and then continue. That captures the outgoing side of a process, which tended to stay invisible in a purely REST-shaped view.

Look at real business processes and it becomes clear why this matters. Few flows are synchronous from end to end. Almost always, some step waits on an event, a payment confirmation, a provisioning result, an approval from a downstream system. That part was exactly what Arazzo 1.0 could not express, so it drifted into footnotes and separate documents. Which makes 1.1 more than a routine feature update. The release shifts the boundary of what Arazzo can describe. A language for REST chains becomes a language for mixed flows that bring synchronous calls and events together in one workflow.

Calling other workflows from a step

The second addition concerns the structure of larger flows. In Arazzo 1.1.0, a step can call another workflow and pass inputs to it via parameters. The results of the called workflow then become available as outputs and can feed the steps that follow.

The example calls the standalone workflow creditRatingCheck from a parent flow and hands in the partner ID from an earlier step. The result is available afterward as rating. Larger processes grow out of smaller, clearly bounded building blocks this way. A complete end-to-end example, with chaining in its place, is part of the guide Arazzo in practice.

The payoff shows up wherever the same logic appears in several places. At a B2B marketplace, the onboarding workflow had grown past twenty steps over time. The credit check inside it showed up in three other flows as well, copied each time. With chained workflows, the check moved into a workflow of its own, called from all four places. A later change to the check logic was made in one place instead of four.

Reuse raises one question that did not exist before. A shared workflow needs a stable interface of inputs and outputs, because several callers rely on it. A change to that interface affects every calling workflow, much like a change to a shared API. Chaining pays off most for sub-flows that are stable and functionally self-contained.

The Selector Object

The third addition is the Selector Object. It extends how a step pulls values out of a response. In Arazzo 1.0, that mostly happened through runtime expressions pointing at a fixed spot in the body. The Selector Object adds targeted queries via jsonpath, xpath, or jsonpointer.

That makes values in deeply nested structures, or in XML responses, cleanly addressable. A jsonpath expression like $.items[0].id picks out the ID of the first list entry without the workflow having to pass the whole body along. For APIs that deliver data in nested objects or as XML, this extraction used to be cumbersome.

An example makes the difference tangible. When an API returns a nested object with a list of positions, a 1.0 workflow often had to forward the entire section and leave the evaluation to a later step. With a selector, the step addresses exactly the value it needs, the status of the first position, say, or an amount buried in a deep field. That keeps the handoffs between steps lean and the workflow easier to read.

The three additions working together

Taken one by one, the three extensions look like independent refinements. In a real workflow, they tend to interlock. An order process can start with a synchronous call that creates the order, then wait for the payment confirmation through a receiving step, and finally call a shipping workflow that exists elsewhere anyway.

Each addition carries one part of that flow. The AsyncAPI support describes the wait for the payment confirmation. The Selector Object pulls exactly the transaction ID the shipping needs out of the confirmation message. Chaining brings in the shipping workflow that another team already maintains. What used to be three loosely connected descriptions in different documents now stands as one coherent workflow in one file.

For documentation, that is a real leap in expressive power. Where several teams used to maintain their fragments separately, one file now describes the whole path from order to shipment. Gaps between systems, the places where flows tend to fail in practice, become visible and verifiable.

What 1.1 deliberately leaves unchanged

For all the additions, the character of Arazzo stays the same. The specification describes flows. It does not execute them. In 1.1.0, as before, the consuming tool decides how a description gets worked through, whether that is a test runner, an SDK generator, or an agent. Runtime concerns, long-running retry strategies or executing many workflows in parallel, deliberately stay outside the specification.

The new AsyncAPI support changes nothing about that either. Arazzo states that a step waits for a message and when it counts as successful. How that message gets delivered technically, over which broker and with which delivery guarantee, belongs in the AsyncAPI description itself rather than in the workflow. This separation keeps Arazzo lean and portable across tools.

What this means for existing Arazzo files

As a minor release, Arazzo 1.1.0 stays backward compatible. Existing documents declaring arazzo: 1.0.0 remain valid and need no changes. To use the new fields, you raise the version field to 1.1.0 and can then bring in AsyncAPI sources, chained workflows, and the Selector Object.

An upgrade pays off most where parts of a flow used to be documented outside the spec. A workflow that makes a synchronous call and then waits for an event can be described completely in one file for the first time in 1.1.0. For purely synchronous REST flows, little changes, because the existing fields keep working untouched.

The upgrade itself is manageable. Raise the version field to 1.1.0, add the sources you need in sourceDescriptions, and run the workflows against your existing test runner. Because the 1.0 fields stay valid, an existing flow keeps running without changes. Only the steps you actively extend with AsyncAPI, chaining, or a selector bring new behavior.

Why 1.1 matters for AI-ready APIs

In 2026, Arazzo comes up most often in connection with AI agents. An agent that is supposed to execute a business process needs a reliable template for the order of calls. The work on AI-ready APIs aims at making interfaces usable for machine consumers, and Arazzo supplies the flow description for it.

Concretely, an agent reads an Arazzo description as a blueprint and never has to work out the right call order on its own. The steps, their data handoffs, and the success criteria are already settled. The agent supplies the inputs, reacts to the results, and stops when a step fails. For flows that have to be correct and repeatable, that noticeably lowers the error rate, because less is left to the model.

With the AsyncAPI support, that description now also covers steps that wait on events. For agents, this matters because real processes rarely finish inside a single synchronous call. How deterministic Arazzo workflows and dynamic agentic workflows complement each other remains the same question as before, just across a wider range of flows. The pillar on API orchestration maps out the bigger picture.

Staying current

Arazzo keeps evolving, and the gaps between releases are short enough to matter. If you run the specification in production, keep an eye on the OpenAPI Initiative’s releases, since every minor version can widen what the spec expresses.

Set the arazzo field in one existing file to 1.1.0 and check whether one of your workflows contains a step that used to wait for an event outside the spec. That exact step is the first candidate for the new AsyncAPI support.