CLI (met)

Run Mets, listen to events and forward them to your local app, from the terminal.

met is Meteor's terminal: it runs a Met, follows the run history, opens a chat and — most useful while you integrate — listens to your workspace's events and forwards them to your local server.

npm i -g @meteor.ia/cli

Node ≥ 20. It uses the same met_ API key as the SDK.

Configure

met config set --key met_live_xxx --workspace 7
met config show    # the key comes out masked

It is stored in ~/.config/met/config.json. It also reads MET_API_KEY, MET_WORKSPACE and MET_BASE_URL from the environment, and every command accepts --key / --workspace for one-off use. In CI, use the environment variables.

While developing, use a test key (met_test_): runs cost nothing and external side effects are blocked.

Run a Met

met run "Summarize today's leads"

In an interactive terminal it streams by default. For a pipeline or a cron job:

met run "Hello" --json --no-stream

--json prints the whole object on one line, ready for jq. --met <name> picks which Met runs if you don't want the workspace's default.

met runs list --status failed --limit 20

Run a task

A task is a procedure with steps that your Met runs. From the terminal:

met tasks list
met tasks run tsk_123

run fires the execution and returns right away, because the steps run in the background. For a cron job or a pipeline that isn't enough — the command would say "ok" for having been able to fire it, not for it having worked — so use --wait:

met tasks run tsk_123 --wait

With --wait the command waits for the final state and the exit code reflects the result: 0 if it finished completed, 1 if it failed or was cancelled. The default ceiling is 300 seconds; raise it with --timeout 900.

met tasks show tsk_123          # the task and its latest executions
met tasks executions tsk_123 --json

Chat

met chat --met sales

A REPL over the same run stream. Good for trying out a prompt without writing code.

Listen to events, and forward them to your machine

This is the command that makes installing the CLI worth it:

met listen --forward http://localhost:3000/webhooks

It takes the workspace's events live and POSTs them to your local server, so you develop the webhook handler without exposing your machine to the internet or setting up a tunnel. Filter for what you care about:

met listen --types run.completed,run.failed

Without --forward it prints them, which is enough to see what is going on. The event catalog is in Webhooks.

Collections and items

Collections are the workspace's no-code databases, and they are the step before everything else: without a collection's id you can't list or create anything inside it.

met collections list
met collections show 12        # the field schema

show prints the fields with their type because those keys are exactly the ones you then use to write:

met items list --collection 12 --limit 20
met items create --collection 12 --set title="House up north" --set price=250000
met items update 9812 --collection 12 --set status=sold

--set is repeatable and is written without escaping anything, which is what you want in a terminal. It splits on the first =, so a URL with a query string goes through whole.

Watch out for types: everything arrives from the shell as text, and --set only converts what is unambiguous. true, false, null and numbers go through; 007, 1.50 and 1e3 stay as text because they don't survive the round trip. What it cannot tell apart is a phone number 3001234567 from a quantity — for those cases, pass JSON and set the type yourself:

met items create --collection 12 --data '{"phone":"3001234567"}'

--data wins over --set if you pass both.

Contacts

met contacts list --limit 50
met contacts show 42                          # the contact and their latest messages
met contacts send 42 "The visit is booked"

send sends as a human operator, not as a Met: it is the equivalent of writing from the inbox, and the message is attributed to a person in the history. If what you want is for a Met to answer, that is met run.

Which Mets are there

met run --met <name> needs the name of a Met. To see them:

met agents list
met agents show 3        # its tools

show prints the tools because it answers the next question — *"why doesn't the Met do X?"*, which is almost always that it doesn't have the tool, not that the prompt is wrong.

How much you are spending

met billing resumen --from 2026-07-01 --to 2026-07-31
met billing ejecuciones      # the detail, sorted by cost
met billing saldo

resumen is the period's aggregate and ejecuciones the detail. When the invoice doesn't add up, the answer is in the detail: it walks every execution and sorts them by cost, and at the top there is almost always a Met calling itself in a loop.

saldo warns you if automatic recharging is off. It matters more than it looks in an unattended integration: running out of Energy stops executions, and on the customer's side that looks like "the API stopped responding".

Debug webhooks

It is the counterpart of met listen: that one brings the events to your machine, and this answers the other half — *"the webhook is configured, why isn't my server receiving anything?"*.

met webhooks list
met webhooks events 12       # delivery history, with the HTTP code
met webhooks sample 12       # fires a test event

If events comes back empty, you already have your answer: the webhook never fired, so the problem is in the trigger and not in your endpoint.

It is read-and-test only, on purpose: creating a webhook or rotating its secret is done from the panel. A secret left in your shell history is exactly what you don't want.

Provision a workspace from a script

A template (Snapshot) sets up a whole vertical in the workspace: collections, Mets, flows and content. From the terminal you can do it without opening the panel, which is what you need when you onboard a new customer from your own signup flow or from CI.

met snapshots list --vertical inmobiliaria
met snapshots show inmobiliaria-basica     # what it includes and which variables it asks for

show prints the variables with a * on the required ones. They are the business data the template uses to personalize prompts and content, and they are passed at install time:

met snapshots claim 3f1e…                  # free templates only
met snapshots install 3f1e… --set negocio="Muebles del Norte" --set ciudad=Medellín

install requires the workspace to already have access to the template: claim grants it for the free ones, and paid ones are bought from the panel. Here --set does not convert types: a phone number or a tax id stays text, which is what they are. If a variable really isn't text, pass it as JSON with --vars '{"cupo":10}'.

The install is additive and idempotent, and everything arrives switched off: install prints the id on stdout and the state on stderr, so in a pipeline you can store the id and review before turning anything on.

When something doesn't work

met whoami

It tells apart the three cases that look identical from the outside: the key is wrong (401), the key is valid and missing the operation's scope (403), or everything is fine. The second is the one that wastes the most time, because it authenticates without trouble and the operation still fails — and the first suspicion always falls on the key. It also tells you which host and which workspace you are hitting, which is the other silent mistake.

If you are a partner

Your partner business is also queried from the terminal, with the same key:

met partner leads --status won
met partner clients
met partner commissions --status approved --json
met partner payouts --period 2026-07

The resources are clients, leads, projects, commissions and payouts. They are read-only: creating an opportunity or moving a stage is done over the SDK or from the panel — not something you want to fire off in one go from a terminal.

The exception is support, which does write:

met partner tickets list
met partner tickets show 84                     # the whole thread
met partner tickets reply 84 "Fixed — give it another try"

show prints the messages and not just the header, because the next thing you are going to write is reply. Opening a ticket and closing it are done from the panel or over the SDK.

A partner key has no workspace, and these commands don't need one. The Partners API host is a different one, so if you point at another environment it is configured separately:

met config set --partner-base-url https://api.partners.meteor.com.co

Every command

Common options

What it doesn't do yet

The CLI covers runs, Mets, tasks, collections, items, contacts, flows, webhooks, billing, events, templates and the partner business (read, plus support tickets). The ones left out — skills, channels, automations, integrations, functions — are operated over the SDK or REST, where they are complete.

It is not a gap to be filled for symmetry: a CLI is for what you do one command at a time, in a cron job or while trying something out. Configuring a webhook or activating a skill is done once, and from the panel.

API keys are created from the panel (Settings → Developers), not from the terminal: issuing credentials from a CLI is the kind of thing that ends up in a shell history. To check the one you are using, met whoami.