Governance & administration
The flags that gate the API, how to lock it down for a whole fleet, the kill switch, and what turning the API off actually means.
All administration of the API, meaning turning it on or off, LAN, webhooks, and deep links, happens in the desktop app. There is no admin scope and no admin HTTP route. See Authentication & scopes.
The four flags
| Flag | Default | What it gates |
|---|---|---|
enabled | Off | The master switch. Nothing in the API starts, meaning no socket, no token minting, no event bridge, no webhook fan-out, unless this is on and the install has an active Pro license. |
lan_enabled | Off | Also serves the API over TLS on the LAN (the My network door, https port 8421), on top of the loopback listener (127.0.0.1:8420) that's available whenever the master switch is on. |
webhooks_enabled | Off | Gates whether a subscribed webhook event is actually delivered. |
deeplink_enabled | Off | Gates the meetilypro:// OS deep-link scheme (a different thing from meetily://, the MCP resource scheme). In this release the door is read-only in the UI (shown as meetilypro:// links, off) and is not part of the Automation API. Even when on, a capture-class link (start/stop recording) still needs the master switch on and an in-app confirmation; only the license-activation link works regardless. |
In the app's Advanced panel these appear as doors, each open only while something needs it: This computer (enabled, loopback 127.0.0.1:8420), Webhook delivery (webhooks_enabled), My network (lan_enabled, https 8421), and meetilypro:// links (deeplink_enabled). The gateway_config.json names above are what you set for fleet control below.
Locking it down for a whole fleet
The in-app toggle doesn't scale past a handful of machines. To force the API off everywhere without touching each machine's UI, push or template gateway_config.json with the flag forced off:
{"enabled": false}Any flag you leave out of the file falls back to its own default (all four default off), so this one line is enough to keep the API off no matter what a user does in the app afterward.
Restart-to-apply, except turning it off
Turning the master switch on, or turning lan_enabled (the My network door) or webhooks_enabled (the Webhook delivery door) on, needs an app restart. The config is read at startup, so the change does not reach an already-running instance - a webhook registered before the restart is refused with webhooks_disabled even though the toggle looks on.
Turning the master switch off from the in-app toggle is the exception: it's instant, no restart needed.
A config file you push or template yourself is also only read at startup, so pushing {"enabled": false} has no effect on a machine that's already running until it restarts. Pair a fleet push with a forced restart if you need a running instance locked down right now, rather than the next time it happens to restart.
The kill switch
Turning the API off doesn't touch the meeting
Turning the master switch off is a kill switch for the API, not for anything Meetily is doing with your audio. Recording, transcription, and summarization keep running exactly as they were. The off toast says so directly: "Recording and processing on this computer keep going."
There's an 8-second Undo right after you turn it off. Undo only restores door state, meaning it reopens whatever was open a moment before. It's a backend-owned deadline, not just something the UI counts down, and it cannot un-revoke a credential, un-expire a grant, or resurrect a pairing window that lapsed in that same instant. If one of those happened right before you hit off, Undo doesn't bring it back; it only reopens the doors.
What "API off" means
With the master switch off:
- Zero listening sockets.
- Zero automatic credential minting.
- Zero scanning for third-party configuration.
- Zero OS URL-scheme registration.
- Zero database writes beyond idempotent schema guards.
The one exception: you can still explicitly create a credential while the API is off, for example to have an app key ready before you turn it back on. That credential is minted, but inert - it grants nothing until the API is on again.
Managing authority you already hold always keeps working while the API is off: revoking a token, denying or closing a pairing, disconnecting a device. Those are safety actions, not new doors, so the off switch never blocks them.
Compliance and residuals
The audit log is content-free: it records who did what, and to which meeting or resource, but never the transcript, summary, or search text itself. It's bounded and prunable , not something left to grow forever with no way to clear it. And it's honest about what it isn't: it is not tamper-proof. Treat it as an operational record for your own troubleshooting, not as forensic-grade evidence.
Related
Last updated on