meetily-pro CLI

Before any command works beyond health, turn on Allow for the auto-created loopback key under Settings > Integrations > Apps & scripts - see Enable & connect. That loopback key ("Meetily's own", Read) is what the CLI uses; the token file already exists on disk, but like every key it stays "Not allowed yet" until you flip its Allow toggle.

Install

meetily-pro reaches your PATH through one command, install-cli, regardless of how you got the binary:

./meetily-pro install-cli          # symlink into ~/.local/bin (unix default)
./meetily-pro install-cli --copy   # copy the binary instead of symlinking
./meetily-pro install-cli --dir /usr/local/bin --force

Global flags and token resolution

These flags work with every subcommand, before or after it:

How the token is resolved

If --token-file points at a path that can't be read, the CLI prints a warning to stderr rather than silently falling through to the next option.

~/Library/Application Support/pro.meetily.ai/gateway-token

%APPDATA%\pro.meetily.ai\gateway-token

$XDG_DATA_HOME/pro.meetily.ai/gateway-token

meetily-pro health is the one command that needs no token at all. Every other command needs a token with the right scope, or the Gateway returns 401/403 - exit code 4 below.

Exit codes

--help and --version exit 0. A 200 response with an empty body (several write/control endpoints return one) is parsed as JSON null, not treated as a parse error.

Scopes

Meetily has four scopes: read, record, write, and delete. There is no admin scope.

Unless a command below says otherwise: a GET route needs read, and a route that creates, changes, or removes data needs write. Recording control needs record instead of write, and deleting a meeting needs delete instead of write.

Commands

Read commands print a human-readable rendering by default, or the raw JSON with --json. Write and control commands do the same for their response body (often null).

Examples

meetily-pro whoami

Prints the identity and scopes attached to the resolved token. Add --json to get the raw response instead of the human-readable rendering.

meetily-pro meetings list

Lists meetings using the same pagination the desktop app uses. Add --limit and --offset to page through a large list.

What the CLI does not have

• No schema command. There's no meetily-pro schema for GET /openapi.json. Fetch that route directly with curl if you need the manifest.
• No --wait / SSE support. recording --wait is not wired into the CLI. The long-poll wait endpoints (GET /v1/jobs/:id/wait, GET /v1/recording/wait) have no CLI equivalent - use curl with -N, or reach them through the MCP server's wait_for_job / wait_for_recording tools.
• No webhooks command. Webhook registration, listing, deletion, and delivery logs are HTTP-only from the CLI's perspective.
• No pairings admin command. Listing or revoking existing pairings is HTTP-only; requesting and completing a new pairing is covered by meetily-pro pair above.
• No recording-state read command. GET /v1/recording (the current recording state) has no CLI subcommand - only the four control verbs under recording exist. Reach it with curl, or with the MCP server's get_recording_state tool.