Governance & administration
The flags that gate the API, their live and startup behavior, 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. The Gateway serves nothing 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 Incoming (LAN) door, https port 8421), on top of loopback (127.0.0.1:8420). |
webhooks_enabled | Off | The Outgoing (webhooks) door; gates registration, tests, and delivery. |
deeplink_enabled | Off | Gates the editable meetilypro:// links door. This OS deep-link scheme is separate from the meetily:// MCP resource scheme and is not part of the Automation API. Capture-class links still require the master switch and in-app confirmation; license activation works independently. |
In Settings > Integrations > Advanced, the optional doors are Outgoing (webhooks), Incoming (LAN), and meetilypro:// links. gateway_config.json stores the corresponding flags.
Configuration and live behavior
In-app changes are live:
- The Automation API master starts or stops the Gateway in-process.
- Webhook delivery and Local targets changes apply immediately.
- Changing LAN reachability restarts the Gateway in-process when a listener rebind is required.
Direct external edits to gateway_config.json are read at app startup. The file is not an enforced fleet lock: the desktop UI can overwrite it later. If fleet policy must prevent a user from re-enabling a door, enforce that outside this file rather than treating one JSON value as immutable policy.
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:
- Request serving is disabled immediately; listener teardown and connection drain complete asynchronously.
- No credentials are minted automatically.
- Third-party configuration is not scanned automatically.
- The OS URL scheme is not registered automatically.
- The Gateway makes no automatic database writes beyond idempotent schema guards.
Explicit control-plane actions still write when the operator asks for them. You can create a credential while the API is off, for example to prepare a key before turning it back on; it remains inert until the API is enabled.
Safety actions also remain available: revoking a token, denying or closing a pairing, and disconnecting a device. The off switch blocks serving, not the operator's ability to withdraw authority.
Compliance and residuals
The audit log is content-free: it records who did what and which meeting or resource was involved, but never transcript, summary, or search text. Request-audit rows are pruned automatically at 50,000; door-event rows are pruned at 200,000. The log is not tamper-proof. Treat it as an operational troubleshooting record, not forensic-grade evidence.
Related
Last updated on