September 28 – October 4, 2026

0.62.0 — 2026-10-04

Sign in with Supabase, with no code. If your users sign in with Supabase Auth, vatio auth --supabase names the project in vatio.yml (auth: supabase:) and stores its URL and anon key as secrets. Then:

• Web: the widget reads the Supabase session already on the page and follows sign-in, sign-out and token refreshes. Nothing to add to the page.
• WhatsApp and Instagram: the Sign in button opens your login page, and the widget on it hands the session to Vatio once the person is signed in.
• Tools: forward $auth.token to the project’s REST API and your Row Level Security decides what the visitor sees.

Or skip the command: Connect Supabase in the console (Channels) signs in to Supabase, picks the project, sets the secrets and shows the auth: line; vatio auth --supabase then uses that project, and vatio diff warns when vatio.yml names a different one.

Vatio verifies against the project’s public keys, so the project has to use JWT signing keys (ES256 or RS256); a push with a project still on the legacy HS256 secret is refused with the fix. See Supabase.

0.61.0 — 2026-10-04

Send WhatsApp messages from your backend. Your backend calls POST /api/server/v1/:slug/messages with a number and what to tell them, and the agent keeps answering when the person replies:

• text goes out exactly as written, when the person wrote in the last 24 hours.
• brief has the agent write the message itself.
• template is the approved template to send when the window is closed, which is the only thing WhatsApp delivers then.

The request answers 202 at once and Vatio sends right after. The agent is shown the brief when the person answers. Around it:

• Idempotency-Key, so a retry never messages anyone twice.
• identity, a JWT your workspace signed, so private tools run when the person answers.
• Signed webhooks: message.sent, failed, delivered, read, delivery_failed and replied, with a delivery log and a ping.
• GET /messages and GET /templates, with each template’s parameter count.

Server keys. The server API takes a server key (vsk_…), not your CLI token. A key belongs to the workspace and one environment, and survives vatio login.

New commands.

• vatio keys list|create|revoke.
• vatio templates list.
• vatio webhooks list|create|test|deliveries|enable|rm.

0.60.0 — 2026-10-03

Signing in works when a coding agent runs the CLI. vatio push (the first time) and vatio login open the browser on Vatio’s sign-in page for that terminal and print the terminal’s code; on a machine with no browser they print the link, and tell a coding agent to show it to its human. There you sign in with your email — Vatio mails a link that signs you in on any device, creating the account if there is none — or with Google or GitHub, check that the page shows the same code, and confirm the terminal. After vatio push, the page then waits for the push and turns into the console’s Test screen. If the wait is cut off, running the same command again picks up the same sign-in page instead of starting over. The CLI no longer asks for an email. The device authorization start endpoint takes an optional workspace slug.

The hosted pages at vatio.ai/w/ are gone. Try an agent in the console’s Test screen — web chat, WhatsApp and Instagram — at the link vatio push and vatio env print after Try it:. To put it in front of customers, embed the widget on your own site, connect WhatsApp or Instagram, or use the SDKs. vatio env no longer prints a page link, and page_url is gone from the environment API.

The Test screen handles several numbers and accounts. Its WhatsApp and Instagram tabs list and verify up to five test phones and five test accounts, instead of only the latest one.

0.59.0 — 2026-10-03

vatio feedback. Tell the Vatio team what got in the way, in a sentence: vatio feedback "push said the tool was invalid but not which field". Coding agents are asked to run it when an error or the docs left them guessing; it arrives with the commands the session ran before it. See Feedback.

Errors say what to do next. API errors now carry a hint when there is a known next step, and the CLI prints it as Next: along with the error code and request_id. See Errors.

Telemetry. The CLI now reports how each command ended — its name, exit code and, on failure, the error it printed — with its version, the coding agent running it and a session id. Arguments, file contents and secrets are never sent. The first command on a machine says so once, and VATIO_TELEMETRY=0 turns it off. See Telemetry.

0.58.1 — 2026-10-03

A flag’s note is what should have happened. Supervisors write more than the sentence the agent should have said: an action, a tool it should have used, a handover. The inbox now asks for What should have happened, and vatio flags, the GitHub issue and the daily mail say the same.

The judge sees tool calls. Eval replays now show the judge every tool the agent called, so a note that asks for a tool passes when the agent calls it. An answer the judge could not read is an error, no longer a fail against the agent.

Analytics and Learning in the inbox. Analytics shows conversations per channel, handoffs, open flags and visitor ratings over 7, 30 or 90 days. Learning shows what became of every flag (pending, in testing, fixed, failing again) with every replay of its case, and lets a supervisor overrule the judge. A person’s verdict wins, and on the newest live replay it decides whether the flag is fixed.

0.58.0 — 2026-10-03

The brand belongs to the business too. The logo, the brand color and the widget’s “about” are set on the inbox’s Business page, next to the name and hours, and no longer on the console’s Widget page, which keeps the rest of the widget’s look. From a terminal: vatio business set --logo FILE | --remove-logo, --color #RRGGBB | --color default and --about TEXT. PATCH /business takes about, accent_color and logo (base64). See Business.

0.57.0 — 2026-10-03

The business and its hours belong to whoever runs it. The business name, description and opening hours live on the workspace and are set on the new Business page of the inbox — a time zone and shifts per day, or someone always available. They apply to every environment as soon as they are saved. The agent now also gets the weekly hours, so it can tell a customer when you are open.

hours: is ignored in vatio.yml. A push that still has it succeeds and prints a warning with a link to the inbox page; existing hours were carried over to the workspace. handoff: stays in vatio.yml. The console’s Widget page no longer edits the name and summary; it links to the inbox.

vatio business. Read and set the same business from a terminal: vatio business, vatio business set --name … --description …, and vatio business hours --timezone … --mon 09:00-18:00 … or --clear. See Business.

0.56.0 — 2026-10-02

One agent per workspace. agents: and entry: are gone from vatio.yml; a workspace runs one agent:, and private tools behind auth: cover what a second, signed-in agent was for. A push that still has them fails and says what to change.

vatio issue is gone; report on GitHub. Bugs and feature requests now go to the public repositories: cli, sdk, ios and ruby. Running vatio issue says where to go, and so does an older CLI that still has the command.

A smaller CLI. It now keeps only the commands a developer runs to build and ship an agent:

• vatio chat is two commands. vatio chat "message" [--new] talks to the agent, and --new starts over as a visitor it never met. vatio chat show [CHAT_ID] prints the chat you are in, or any chat, with every tool call. transcript, debug, reset and destroy are gone, and each one tells you what to use instead.
• vatio tools check is gone. vatio push validates before it deploys, and vatio diff validates without deploying.
• vatio widget is gone. vatio env prints the snippet and its token, and the look is edited on the console’s Widget page.
• vatio mcp is gone. Point your coding agent at vatio docs --save.
• WhatsApp and Instagram are set up in the console, on the Channels page: your own number or account, test phones, and test accounts. vatio whatsapp and vatio instagram print that link. Older CLIs get the same answer.

Every API is named after who calls it.

• The developer API (what the CLI uses) lives at /api/developer/v1.
  • Its routes read like the CLI: /:slug/deploy/* is now /:slug/check, /push, /publish, /rollback, /status, /manifest, /env and /secrets.
  • Signing in and creating a workspace move from /cli/* to /api/developer/v1/device_authorizations and /api/developer/v1/workspaces.
  • /deploy/revisions is gone.
• The visitor API (the widget and both SDKs) lives at /api/visitor/v1. The JavaScript SDK 3.3.0 and the iOS SDK 0.3.0 call it there.

/api/v1, /cli/* and /api/public/v1 keep answering, for clients released before these.

Server-to-server is removed. None of it was in use:

• The phone verification API, along with agent: false.
• Conversations over the API with no visitor (the api channel).
• The identity mint, and auth.mint in vatio.yml. WhatsApp and Instagram visitors are anonymous, and only public tools run for them. Signed-in visitors on the web work exactly as before. vatio-identity 0.3.0 signs and verifies the JWT, and no longer mounts a mint endpoint.

The widget is a bubble only. data-display="page" and data-mount are gone.

Agent modes are removed. modes, initial_mode and mode_reset_after in vatio.yml, and the switch_mode tool, no longer do anything. A push that still has them succeeds and warns that they are ignored; each agent works from its own tools and knowledge.

Knowledge is what you write. vatio kb follow, unfollow and refresh are gone, and Vatio no longer reads or re-reads websites. Pages it had already read stay as ordinary entries you can now edit (vatio kb cat / kb write).

Console notices show their message again. Inviting, resending or removing a team member, and registering, verifying or moving a test WhatsApp number, showed “Translation missing” instead of the confirmation or the error. They read correctly now.

0.55.0 — 2026-10-01

Flagged replies become work your coding agent can do. vatio flags prints every reply a supervisor flagged in the inbox as one document for a coding agent: the conversation, each tool call of that turn with what your backend answered, and what the reply should have been. Each flag is now an eval case, and vatio eval replays every case against an environment — the branch’s by default — with a judge comparing each reply to the supervisor’s note; it exits 1 when a case fails. Evals also run on every pull request preview, commented on the pull request, and after every publish to live, which is what marks a flag fixed in the inbox. The judge is a model from a different family than the agent’s, and replay chats stay out of the inbox and out of the conversation count. vatio init now adds a short Vatio section to the workspace’s AGENTS.md, and the Claude Code plugin at github.com/vatio-ai/skills adds two skills: vatio-new to build an agent from scratch and vatio-improve to work through flags. The docs’ For coding agents section now spells out how to start a new agent, so any coding agent reading vatio docs follows the same steps. Every morning, workspaces with new flags get a mail and, with GitHub connected, one issue labelled vatio-flags holding the digest, ready for a coding agent on GitHub to pick up. See Improve your agent from flags.

0.54.1 — 2026-10-01

Source and issues are public. The CLI, the JavaScript SDK, the iOS SDK and the vatio-identity gem each have a public repository under github.com/vatio-ai, where you can read the code and open issues. Swift packages now install from https://github.com/vatio-ai/ios, and the gem installs with gem "vatio-identity", git: "https://github.com/vatio-ai/ruby". Nothing else changed.

0.54.0 — 2026-10-01

Every git branch is an environment of its own. On a branch other than the default one, the CLI works in that branch’s environment without --env — fix/pagos is fix-pagos — and says so on stderr: push, chat, kb write, secrets set, tokens and publish all use it. The branch’s pull request deploys to the same environment instead of a separate pr-N, so what was tried there before the pull request existed is still there. On the default branch and outside a repository, every command keeps its old default. Several people or coding agents can now fix several conversations at once, each in a worktree, without their changes meeting before they merge.

Knowledge changes belong to an environment, and go live with it. The entries are what live answers from; a supervisor’s edit in the inbox, the console and a site re-reading a page change live directly. On a branch, vatio kb write makes a change only that branch answers from, and publishing the branch — vatio publish, or merging its pull request — takes the prompt and the knowledge live together. When live changed an entry the branch also changed, publishing is refused and names it; rewriting the entry on top of live clears it. Each environment has a page in the console with the diff of every entry it changed, where a conflict is resolved in place — keep the branch’s version, take live’s, or combine them. Pull requests get a vatio/knowledge status that turns red before the merge and links to that page, and a comment listing their knowledge changes. Today’s unpublished draft became the changes of preview.

A deployment is a snapshot of the whole agent. Once live, it records the version of every knowledge entry written by hand it answered from. Publishing, and a supervisor’s edit in the inbox or console, leave a new snapshot; vatio rollback moves live back one, prompt and knowledge together. Pages a site reads are not part of it. Environments other than live are disposable, with everything in them.

vatio env. Shows the environment you are in: its publishable token, the widget snippet, the link to try it, its knowledge changes and any conflicts. vatio env list shows every environment and vatio env rm NAME removes one. An environment with nothing left to publish is removed after 14 days idle.

A secret can have its own value in one environment. On a branch, or with --env, vatio secrets set sets the value only that environment uses, so a branch’s tools can call staging while live calls production.

A simpler console. Its menu is now Environments, Test and Channels. Environments lists live, preview and every branch, each with its deployment, agents, knowledge changes and conflicts, and secret names; GitHub is connected there too. Under Channels, the Widget page holds the install snippet, the brand settings and the tokens with their allowed origins, which used to be three pages. Knowledge is edited in the inbox (or the CLI); the console keeps each environment’s knowledge review. The public page, /w/<slug>, is live’s: the business with the widget’s bubble, no longer a full-screen chat. Each other environment has the same page at /w/<slug>/<environment>, for the workspace’s members; push, vatio env and pull request comments link to the console’s Test screen for it, and the /w/<slug>/p/… share links are gone.

Every channel can point at a branch. Each test phone on the shared WhatsApp number and each test account on the shared Instagram one reaches the environment it points at — vatio whatsapp numbers point PHONE --env NAME, vatio instagram accounts point ID --env NAME, or a selector in the console — instead of always preview. With the CLI on the branch, the widget and SDKs on its token, and /w/<slug>/<environment> for the workspace’s members, a branch is tried on every surface without touching live.

Breaking

• Preview share links (/w/<slug>/p/…) no longer open: try an environment in the console’s Test screen, signed in. The API’s share_url now points there.

• vatio kb rollback and the knowledge publications behind it are gone. vatio rollback now takes the knowledge back with the prompt; to go back on one entry alone instead: vatio kb history BASE lists what reached live, vatio kb cat BASE ENTRY --version N prints one, and writing it again with --env live restores it. The API’s snapshots paths answer 410.

• vatio kb publish no longer takes -m, and publishes the current environment’s changes to one base.

• Pages a site reads go live as soon as they are read, instead of waiting for a publish.

0.53.0 — 2026-09-30

The workspace’s brand is edited in the console, not in vatio.yml. The business name and summary, and the widget’s look (accent color, about, logo, locale, greeting, suggestions and the rest), live on the workspace’s new Brand page. They are one setting for every environment and apply as soon as you save. business:, widget: and root allowed_origins: in an existing vatio.yml still push, but they are ignored: vatio push, vatio check and the GitHub pull request comment print a warning with the console link. Remove them when convenient.

Allowed origins belong to each publishable token. A token works only from the origins listed on it, plus Vatio’s own pages. Every token started with the origins your workspace had, so nothing stops working. Edit them on the console’s Tokens page (the install snippet’s token is there too), or with vatio tokens create --origin URL (repeatable) and vatio tokens origins PREFIX URL.... vatio tokens list shows each token’s origins, and vatio init no longer writes business:.

0.52.0 — 2026-09-30

With GitHub connected, live changes only by merging. A workspace bound to a repository publishes when a commit lands on its default branch, and nowhere else: vatio publish is refused with a message naming the repository and the branch, and so are vatio push --env main and vatio push --env pr-N, which belong to the integration. vatio push to preview or another named preview still works, and vatio rollback stays as the emergency button.

Every GitHub deploy shows on its commit. Previews and publications post a commit status (vatio/preview (workspace), vatio/live (workspace)), green or red, linking to the preview, live or the console. A failed publication used to leave no trace outside a server log. Deploys to one workspace now run one at a time, and a merge that finishes late never replaces a newer one already live.

vatio publish without GitHub prints a notice. It works as before; the notice says publishing from the CLI will soon require a connected repository.

0.51.0 — 2026-09-30

Knowledge has a draft, a live version, and history. Every write to a base — vatio kb write, a site re-reading a page, an edit in the console or the supervisor inbox — lands in the base’s draft and is kept as a numbered version of its entry. Preview answers from the draft; live answers from what was last published. vatio kb status BASE shows what live does not have yet, vatio kb publish BASE -m NOTE takes it live, vatio kb history BASE lists every publication, and vatio kb rollback BASE NUMBER points live back at one instantly. Everything a base held before this release is already published, so live answers exactly as it did.

Supervisors can edit knowledge from the inbox. Written entries can be created, edited and deleted there, each entry shows its history with a diff and a restore button, and “answered from” in a conversation now links to the exact version the agent had.

0.50.0 — 2026-09-29

vatio secrets set KEY asks for the value. Leave VALUE out and the CLI prompts ? Paste your secret: and echoes a * per character, so the value never lands in your shell history. Off a terminal it reads stdin instead: op read op://Vault/item/field | vatio secrets set KEY. set KEY VALUE works as before.

The CLI tells you when a new release is out. After a command, if npm has a newer @vatio-ai/cli, you see the version and the command to upgrade. It checks the registry at most once a day, only when stderr is a terminal, and never in CI or under vatio mcp. VATIO_NO_UPDATE_NOTIFIER=1 turns it off.

0.49.0 — 2026-09-29

The identity token can enrich the inbox. Add a metadata claim to the JWT you already sign, and the inbox shows it in the conversation header:

"metadata": {
  "profile": "https://acme.com/admin/users/42",
  "badges": { "plan": { "value": "Premium", "tone": "green" }, "country": "CL" }
}

profile becomes a Profile ↗ link to the person in your own admin. If it is not an http(s) URL, the header shows a quiet “Invalid profile link” warning instead. Each entry in badges is a chip, and an optional tone (green, amber, red, gray) colours it. Nothing changes for tokens without metadata. vatio auth --new-key now lists the claim. See Enrich the inbox.

0.48.1 — 2026-09-28

vatio update now points to the correct npm package. The command recommended vatio@latest, which returns a 404 from npm. The package is @vatio-ai/cli; the executable it installs is vatio. The message now recommends npm install -g @vatio-ai/cli@latest for a global install and npx @vatio-ai/cli@latest to run the latest release directly.

0.48.0 — 2026-09-28

A bare vatio publish promotes your latest push. It used to promote whatever the preview alias pointed at, so vatio push --env pr-42 followed by vatio publish re-published the old preview and live never changed. Now it takes the most recent deployment, whichever preview it landed on, and says which one: Published live deployment #80 from pr-42. --env NAME still promotes a specific preview.

vatio chat show CHAT_ID reads any chat in the workspace. A visitor’s chat on the web or WhatsApp, not only the one your CLI opened: the channel, the environment and deployment that answered it, every message and every tool call. --json prints the raw payload.