How to Build Schemas, Flows, and Experiences Incrementally with the CLI

This guide shows you how to change one Schema field, Flow node or edge, or Experience block at a time, instead of sending a whole configuration.

Prerequisites

• You are authenticated (ligantic auth login or LIGANTIC_API_KEY).
• A current Space is set (ligantic space use <id> or LIGANTIC_SPACE_ID).

Schemas

Create a Schema with no fields, then add them one at a time. --field takes one field's configuration; the command returns the field's generated ID. Record data uses field names as keys unless you pass --id-based. Field types are listed in Schema Field Types Reference.

ligantic schemas create --name Ticket --display-name-template Ticket
ligantic schemas fields add Ticket --field '{"name":"Title","type":"string","required":true}'
ligantic schemas fields add Ticket --field '{"name":"Status","type":"string","display":"select","options":["Open","Closed"]}'

Address a field by ID, by name (case-insensitive), or by dot path for nested fields. An object field needs "properties":{}; add its fields with --parent.

ligantic schemas fields add Ticket --field '{"name":"Reporter","type":"object","properties":{}}'
ligantic schemas fields add Ticket --parent Reporter --field '{"name":"Email","type":"string"}'
ligantic schemas fields update Ticket reporter.email --changes '{"required":true}'
ligantic schemas fields delete Ticket reporter.email --yes

--changes is merged into the field; a null value removes a property. A list such as options is replaced, so send the whole list.

To change only the display name template, omit --schema:

ligantic schemas update Ticket --display-name-template '{P1a2b}'

Every change saves a new Schema version.

Flows

flows create without --nodes starts the Flow with a single Flow - Trigger node (flow:trigger) whose nodeId is trigger.

ligantic flows create --name "Close ticket"

To send the whole graph at once, pass --nodes and --edges (or --data with a JSON file). Each node needs only its type and data; give it a nodeId when an edge refers to it. Node and edge ids are generated, and a node without a position goes below the lowest node. Add --auto-layout to arrange every node along its edges instead. flows versions create and flows versions update accept graphs the same way.

ligantic flows create --name "Read heading" --auto-layout --data @flow.json

{
  "nodes": [
    { "nodeId": "trigger", "type": "flow:trigger", "data": { "label": "Trigger" } },
    {
      "nodeId": "open",
      "type": "browser:navigate",
      "data": { "label": "Open page", "url": { "type": "literal", "value": "https://example.com" } }
    }
  ],
  "edges": [
    { "source": "trigger", "sourceHandle": "trigger", "target": "open", "targetHandle": "trigger" }
  ]
}

--direction sets which way the Flow reads: TB (top to bottom: inputs on top, outputs at the bottom) or LR (left to right: inputs on the left, outputs on the right). --auto-layout arranges the nodes in that direction. Without --direction, flows create uses your direction for new flows (top to bottom unless you changed it), flows versions create keeps the latest version's direction, and flows versions update keeps the version's. flows versions show returns the Flow's direction. A node with its own direction overrides the Flow's for its handles; omit it to follow the Flow.

ligantic flows create --name "Read heading" --direction LR --auto-layout --data @flow.json

Look up the configuration a node type accepts before adding it:

ligantic flows node-types list
ligantic flows node-types show object:update

flows nodes add returns the new node's nodeId and its handles. Connect an edge from one of a node's outputs (--source-handle) to one of another node's inputs (--target-handle).

ligantic flows nodes add <flowId> --type data:literal --node-data '{"value":{"type":"string","value":"Closed"}}'
ligantic flows edges add <flowId> --source <nodeId> --source-handle value --target <otherNodeId> --target-handle <inputHandleId>

Read the graph compactly with flows nodes list (each node's ID, type, label, and handles, plus every edge), or one node in full with flows nodes show <flowId> <nodeId>. Change a node with flows nodes update --node-data, which is merged into the node's data. flows nodes delete also removes the node's edges; flows edges delete removes one edge. A Flow must always keep a flow:trigger node.

Node and edge edits change the Flow's draft. When the latest version is published, the first edit creates a new draft from it and returns "createdDraft": true; runs keep using the published version until you publish the draft:

ligantic flows versions publish <flowId> <flowVersionId>

Experiences

Look up a block type's properties with experiences block-types show <type>. The Experience Blocks Reference describes the block types. Add blocks with experiences blocks add; the first block becomes the root, and later ones go under the root, or under --parent-id at --index. IDs are generated for the block and any nested children.

ligantic experiences blocks add <experienceId> --block '{"type":"box","name":"Page"}'
ligantic experiences blocks add <experienceId> --block '{"type":"text","text":"Tickets","htmlElement":"h1"}'

Find blocks with experiences blocks outline (IDs, types, names, and text previews; --depth and --block-id narrow it), and read one in full with experiences blocks show. Then change it:

ligantic experiences blocks update <experienceId> <blockId> --changes '{"text":"Open tickets"}'
ligantic experiences blocks move <experienceId> <blockId> --parent-id <boxId> --index 0
ligantic experiences blocks delete <experienceId> <blockId> --yes

A property the block type does not have is rejected rather than ignored. Like Flows, block edits change the Experience's draft and create one from a published version when needed; publish with experiences versions publish.