webmati dev and webmati test
See theme changes the moment you save, and run workflows on your machine against sample data.
webmati dev — save a file, the page reloads
webmati dev --open
dev watches theme/. Every time you save (and the files are quiet for 300 ms),
it pushes that batch to the draft and reloads the page in your browser. The
page opens through a proxy on your machine, http://127.0.0.1:9393 by default. A
push the checks refuse is printed and skipped: fix the file and save again.
Ctrl-C stops it.
webmati dev --path /products/t-shirt # open one page
webmati dev --port 9400 # another port for the proxy
webmati dev --no-proxy # print the preview link only: no proxy, no reload
A theme of your own: --new-theme
The website has one draft, shared with the customizer and everyone else. To
experiment without getting in anyone's way, create a development theme (a
copy of the draft) and let dev push there:
webmati dev --new-theme --theme-name "new menu test"
From then on the project writes to your own theme (webmati.toml remembers it).
webmati test — run a workflow on your machine
webmati test orders
test runs the draft on disk of the workflow orders with the platform's own
engine, here on your machine. Nothing is written back to the server.
| What the workflow needs | Where it comes from in a test |
|---|---|
| the request | backend/fixtures/inputs/<code>.json, or --input |
| table rows | backend/fixtures/<table>.jsonl (one JSON record per line) |
outbound fetch | mocks in backend/fixtures/fetch.json |
| secrets | the environment variable WEBMATI_SECRET_<CODE>, or .webmati/secrets.json |
| email, SMTP, realtime, jobs | recorded in the result, never sent |
The request
webmati test orders --input '{"body":{"min":3}}' # inline JSON
webmati test orders --input backend/fixtures/big.json # a file
echo '{"query":{"page":"2"}}' | webmati test orders --input -
Its keys may be method, path, query, params, headers, body, ip,
user, event, geo and app. Stop at one node (handy for debugging):
webmati test orders --node calc
Mocks for fetch
backend/fixtures/fetch.json is an array of canned answers. url matches
exactly, or as a prefix when it ends with *:
[
{
"method": "GET",
"url": "https://api.example.com/rates*",
"status": 200,
"content_type": "application/json",
"body": { "usd_vnd": 25400 }
}
]
A fetch with no mock is not sent; the result lists it as NOT SENT.
--allow-network sends it for real (secrets then come from
WEBMATI_SECRET_<CODE> or .webmati/secrets.json):
WEBMATI_SECRET_STRIPE_KEY=sk_test_… webmati test checkout --allow-network
.webmati/secrets.json looks like {"STRIPE_KEY": "sk_test_…"} and is already in
.gitignore: never commit it.
On the platform: --remote
webmati test orders --remote
--remote is real
--remoteruns the same draft on the platform: every table write, email, outbound call and realtime publish is real. The CLI warns you and asks first (--yesskips the question). Use it when you need real data, on a test website.
Each code node gets 5 seconds by default (--timeout 10s gives it more).

