Command Line Interface

The API server ships with an administrative command line tool. It runs inside the server container (the deployment's init steps use it) and is available to operators and deploying partners for maintenance, diagnostics and configuration as code. Commands use the server's own configuration, so they act on the instance they are run in.

Command groups

Group	What it does
db	Database lifecycle: apply migrations, show the current revision and history, seed reference data (with a safe mode), list tables and models, inspect a table. Development-only commands reset, wipe or truncate a database and generate synthetic submissions.
user	Create a user, list users, look one up by identifier or email.
tokens	Revoke every active session of a user, for example when a device is lost.
config	Configuration as code: validate a desired-state manifest, snapshot the live configuration, plan the changes an apply would make, and apply them. See Configuration & Vault.
plugins	Discover installed plugins and register their definitions; invoke a plugin action directly by entry point for testing, without touching the database; send a test email through a mail plugin.
events	Inspect the event outbox: list delivery tasks, trigger a drain cycle manually, clean up completed tasks past the retention window. See Events & Delivery.
email	Send a test email through the configured mail settings to verify delivery.
tracker	Send a heartbeat to the central heartbeat service on demand, to verify connectivity after installation.
error	Export the error catalogue (codes, default HTTP status and message) as a document for client developers. See Observability.

Every command and subcommand documents its options with --help.

Typical uses

First installation. The init steps run migrations, seeding and plugin registration automatically. Running them by hand is useful when the steps are disabled or when diagnosing a failed start:

1. Apply migrations (db), then seed (db), then register plugins (plugins).
2. Verify with the migration history and the users list.

Locking out a user immediately. Disable the account in the web app, then revoke the user's sessions with tokens so that existing sessions stop at once.

Diagnosing stalled deliveries. List delivery tasks with events to see whether tasks are pending or dead-lettered, then trigger a drain manually while watching the log. If deliveries resume, check the scheduler leadership described in Background Jobs.

Testing a plugin before wiring it into a workflow. Invoke it by entry point with a sample payload and a sample configuration. Nothing is written to the database, so this is safe on any instance.

Configuration as code. Keep the instance's desired configuration in a versioned manifest; validate it, plan the difference against the live instance, and apply it during a maintenance window. The snapshot command captures changes made in the web app back into the manifest.

Conventions

• Commands are non-interactive by default so they can run in init containers and pipelines; commands that can destroy data ask for confirmation or require an explicit flag.
• Output is plain text suitable for logs; the error catalogue export supports structured output.
• Commands respect the same configuration and secrets as the running server, so they need the same environment.