Capability preflight

Before an automation acts, it should confirm two things: the gateway is up, and the token has the scope the task needs. This is how a script discovers that the running Meetily build actually has the Agent API enabled, instead of hanging or failing partway through a job.

Preconditions

• A Pro license.
• Integrations turned on in Settings, then Integrations.
• Meetily restarted since you turned Integrations on.
• The gateway listening on http://127.0.0.1:8420.

If any of these is missing, preflight fails and the automation should stop, not retry.

1. Is the gateway up?

GET /health needs no token. It tells you the gateway is alive, and returns the running version plus a few counters:

curl -s http://127.0.0.1:8420/health

If the app is not running, or Integrations was off at startup, the request fails to connect. Treat that as "tell the operator to enable it," not "retry in a loop." The CLI exits with code 3 (cannot connect) in that case.

2. Who are you, and what can you do?

GET /v1/whoami returns your token id, its scopes, and your license tier. A script should check this before it attempts a write, so it fails fast with a clear message instead of a 403 partway through a job.

curl -s http://127.0.0.1:8420/v1/whoami -H "Authorization: Bearer $MEETILY_PRO_TOKEN"

meetily-pro whoami --json

from meetily_agent import MeetilyClient
print(MeetilyClient().system.whoami())

If Integrations is off, or the license is not Pro

If Integrations is turned off (or the Pro license lapses) while the app is running, routes return 503: the listener stays bound, so the connection succeeds but the response tells you the gateway is not usable. If Integrations was off when the app started, the gateway never binds a socket and the connection is refused instead. Treat either case the same way: stop, do not retry, and surface it.