The daily loop

webmati pull                   # 1. take what changed on the server
#                                2. edit files
webmati validate               # 3. check as the server would, on your machine
webmati test orders            # 4. run a workflow (when you changed the backend)
webmati push --dry-run         # 5. see what would be sent and whether it is accepted
webmati push                   # 6. write to the DRAFT
webmati preview --open         # 7. open the draft in the browser
webmati publish theme          # 8. show it to visitors

Run these inside the project folder (or put --dir <folder> in front of the command).

1. pull — start every session with a pull

webmati pull

Takes what others (or you, in the admin) changed on the server. Your own changes that are not pushed yet stay as they are. When the same thing changed on both sides, pull merges it when it can and leaves a conflict when it cannot — see Conflicts.

Where things stand, at any time:

webmati status            # what changed here and on the server
webmati diff              # your changes since the last sync
webmati diff --remote     # against what the server has now

3. validate — an error here is something the server would refuse

webmati validate
webmati validate theme/sections/hero.liquid
webmati validate --remote

validate runs the server's own rules on your machine: theme lint (~70 rules), section schemas, theme settings, workflow graphs, table declarations, and the Liquid syntax exactly as the storefront parses it. Fix every error; warnings are advice.

• --remote also asks the server (a dry-run changeset and the server's workflow graph check), for rules that need the real data.
• --all also lists findings the stored copy already had, not only new ones.

Liquid parse skipped

The offline Liquid syntax check needs Node.js ≥ 18 on the machine. Without Node, validate reports Liquid parse skipped (install Node ≥18 or use --remote) — that step was skipped, not passed. Install Node, or use validate --remote.

4. test — run a workflow without touching real data

webmati test orders

Runs the draft of the workflow orders on your machine with the platform's own engine, against sample data in backend/fixtures/. See webmati dev and webmati test.

5–6. push — drafts only

webmati push --dry-run
webmati push
webmati push theme/sections/hero.liquid    # push one file only

push sends theme files into the theme draft, workflows into their workflow drafts and pages into their page drafts. Visitors see nothing yet. push runs validate first and sends nothing when it finds an error (--no-validate skips the offline step; the server still runs its own).

Each item's result:

• APPLIED written · UNCHANGED the server already had exactly this · WOULD_APPLY (with --dry-run) would be written
• CONFLICT the server changed it since your last pull — see Conflicts
• REJECTED the server refused it, with the reason · NOT_APPLIED not sent because another item in the same batch was refused
• SKIPPED a live change (a table, redirect, translation…) that goes through push --live — see Live changes

When the server stores something slightly different from what you sent (it normalised the JSON, say), the CLI replaces your file with what the server stored, so the next status is clean.

7. preview — look at the draft

webmati preview                  # print a link to the draft
webmati preview --path /about    # straight to one page
webmati preview --open           # open it in the browser

The link carries a preview token that expires after a while (--ttl sets it, in seconds). To have the page reload every time you save a file, use webmati dev.

8. publish — show it to visitors

webmati publish theme              # the theme draft becomes the live theme
webmati publish workflow orders    # the workflow draft becomes what its route runs

publish prints what will change and asks first (--yes skips the question). publish theme also publishes edits other people made in the draft (in the customizer, say); it lists them — read the list before you agree.

A page is published with the publish_page tool:

webmati tool call list_pages --json '{}' --select '.storePages[] | select(.slug == "about") | .id'
webmati tool call publish_page --json '{"id":"123"}'

(Replace 123 with the id the first command printed.)

Exit codes

Every command takes --json for machine-readable output.