Skip to main content
wat is a small command-line tool that books WAT rooms by driving the same public API the web app uses. The command is wat; the package is @wat-toolbox/wat.

​
Install (or don’t)

Zero-install: every command runs on demand through npx, which is what agents should default to:
For regular use, install globally so the wat command is on your PATH:
The skills plugin shells out to wat, so the skills require the global install. Login state is shared either way — both forms read the same ~/.config/wat/config.json, so you can log in via npx today and install globally later.

​
Log in

This runs an email one-time-password flow: it sends a 6-digit code to your email and prompts for it. On your first login your account is created automatically if your email is on WAT’s resident list (your company’s domain, or your address added by a WAT admin) — otherwise login fails with NOT_AUTHORIZED and an access request is automatically filed with the WAT admins: you’ll receive an email if it’s approved, then log in again. It then mints an API key and stores it as your active profile in ~/.config/wat/config.json (mode 0600). Every later command reuses this key.
To revoke a key everywhere (not just locally), run wat keys revoke <id> or use the API keys tab on the Account page in the web app.

​
Non-interactive login (two-step)

Scripts and agents log in without a TTY in two calls. First send the code, then complete with the code your human reads from their inbox:
Do not skip step 1: each send invalidates earlier codes, so completing must not trigger a fresh send — and with --code present, it doesn’t. With --json, wat login never prompts: a missing required flag fails fast with a structured MISSING_FLAG error instead of hanging on input. See Error codes, and the Agent playbook for the full conversational handoff.

​
Command reference

You can pass --room either a room name (case-insensitive) or a room id. Run wat rooms list to see both. Availability is clipped to the opening hours (06:00 to 22:00 Europe/Brussels): time outside them never shows as free, and creating or editing a booking outside them is rejected with outside_hours. Every command accepts --json for machine-readable output. The skills plugin relies on this; the envelope is { "success": true, "data": { ... } } or { "success": false, "error": { ... } }. The codes you can get back are listed on the Error codes page.

​
Choosing the environment

The CLI defaults to production (https://app.wat.com). Pass --env dev to target the staging deployment, which reads development data. Use it only when you mean to.

​
Overrides and precedence

Any command also takes a per-call --api-key <key> and --api-url <url>, and three environment variables cover scripted use: WAT_CLI_ENV (dev or prod), WAT_CLI_API_KEY, and WAT_CLI_API_BASE_URL. The base URL resolves in this order (highest wins):
  1. The --api-url flag
  2. WAT_CLI_API_BASE_URL
  3. The active profile’s stored base URL
  4. --env dev|prod, or WAT_CLI_ENV
  5. The production default
The API key resolves as --api-key, then WAT_CLI_API_KEY, then the active profile. Run wat config show to see exactly which source each one resolved from.

​
Time and time zones

Bare datetimes such as 2026-06-10T10:00 are read as Europe/Brussels wall-clock, matching the web app, then converted to UTC for the API. Pass --tz <IANA> to read bare times in another zone, or include an explicit offset (2026-06-10T10:00+02:00) to pin the exact instant. Times are printed back in the same zone you gave, so what you type and what you see always agree.
Need to book conversationally instead of by hand? Install the skills plugin and ask your agent. The skills wrap these same commands.