schema prints the exact shape the server expects for Flow payloads. Useful when you’re hand-editing JSON, writing config-as-code, or building a tool that produces Flow payloads.
Commands
schema show
- Every top-level field.
- Every block type (Agent, Tool, Action, Trigger, Router, …).
- Every block field with its type, required-ness, allowed values.
- Every edge/wire field.
--json to pipe into a JSON-schema-aware tool (jq, ajv, an IDE JSON schema binding).
When to use it
- Before
flows apply— check your JSON matches what the server accepts. - When your JSON gets rejected and the error message is unclear.
- As reference material when writing generators or migrations.
Validating a Flow file locally
The server always validates onflows apply, but you can pre-validate offline with any JSON-schema tool:
Schema evolution
The schema is versioned along with the server. Newer server versions may add optional fields; required fields never change without a migration path. Track schema changes: runschema show in CI and diff against the previous version. When something new appears, ask whether your generators need updates.
What the schema does NOT cover
- Runtime state — the schema is the editable payload, not the run history.
- Version metadata (author, timestamp, etc.) — those are added server-side on publish.
- Settings (
nora flows settings get) — those are a separate object. - Variables (
nora vars list) — technically part of the payload but often edited viavars set.