Skip to main content
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

Prints the full payload schema:
  • 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.
Default output is human-readable structured text. Add --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 on flows apply, but you can pre-validate offline with any JSON-schema tool:
Catches typos and shape mismatches before the network round-trip.

​
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: run schema 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 via vars set.