A workflow in Spirefy is a multi-step sequence of API calls where each step can use the output of an earlier one. It is a superset of Arazzo, the OpenAPI workflow specification that Spirefy’s founder co-authored, so anything Arazzo can describe the model can hold, plus a few things Arazzo leaves out.
The model underneath
Workflows do not stand alone. They live in the same unified model as the APIs they call, which holds:
- Operations: the REST calls from your OpenAPI imports.
- Channels: the publish and subscribe messages from AsyncAPI.
- Components: shared schemas, parameters, headers, and responses.
- Workflows: the multi-step sequences described here.
- Sources: a record of which import each entity came from.
Because a workflow references operations and channels that already exist in the model, it always points at the real thing. If an operation changes on its next import, the workflow still points at that operation rather than a stale copy.
Steps and outputs
A workflow is an ordered list of steps. A step usually points at an operation and supplies its inputs. A step can declare outputs, values pulled from its result, and a later step can read those outputs as its own inputs. That is how a value produced early, such as a new resource id, flows through the rest of the sequence.
Logic steps
A step does not have to be an API call. It can run your own WebAssembly, so a transform, a validation, or a small piece of glue lives in the flow beside the calls it supports. This is one of the places the model goes beyond Arazzo.
Beyond REST
The model is built for more than request-and-response APIs. It holds event-driven channels from AsyncAPI alongside REST operations, so a workflow can reason about both. Support for more protocols is part of the model’s foundation and grows over time.
Exporting a workflow
When a workflow is ready, the Arazzo exporter writes it back out as a standards-compliant bundle: the workflow file plus the API descriptions it references. Export runs in the app today for one-off output.