--- title: "openemail keys" description: "Every command in this namespace, with its arguments, flags and examples." url: "https://openemail.uk/docs/cli/reference/keys" area: "CLI" category: "Reference" --- # openemail keys Every command in this namespace, with its arguments, flags and examples. ## Commands ### `openemail keys list` List one page of the workspace's API keys ```bash openemail keys list [flags] ``` Returns one page of the workspace's keys, newest first, with what the Settings, API keys page shows: status, scopes, role, send scope, when each was last used, how often, and who made and last changed it. Revoked and expired keys stay listed until somebody deletes them. No secret is ever returned; `maskedKey` is enough to tell two keys apart. A key narrowed to some domains or addresses only sees the keys whose send scope sits inside its own, so any other is a 404 rather than a refusal. Over OAuth only the workspace owner reaches it, and a member's token is 403 `owner_only`. Add `--all` to walk every page: a table on a terminal, one JSON object per line when piped or with `--ndjson`, and one `{ items, hasMore, nextCursor }` document with `--json`. `--max ` stops after that many items. - Scopes: `keys:read`. - Needs a sign-in. - Aliases: `ls`. **Flags** - `--limit ` (default `25`): Rows per page, a whole number from 1 to 100. The server defaults to 25. - `--cursor `: The `nextCursor` from the previous page, passed back unchanged. Never build one yourself. - `--all`: Fetch every page and stream the items as they arrive. - `--max `: Stop after this many items. Implies `--all`. - `--ndjson`: Print every item as one JSON object per line. Implies `--all` **Examples** ```bash openemail keys list ``` Walk every page and stop after 100 items ```bash openemail keys list --all --max 100 ``` One JSON object per line when piped ```bash openemail keys list --all > keys.ndjson ``` Also available in: API [`GET /keys`](https://openemail.uk/docs/api/reference/api-keys#get-keys); SDK [`keys.list()`](https://openemail.uk/docs/sdk/reference/keys#list). ### `openemail keys get` Read one API key, without its secret ```bash openemail keys get [flags] ``` Resolves with one key as `list` shows it. A key narrowed to some domains or addresses only sees the keys whose send scope sits inside its own, so any other is a 404 rather than a refusal. Over OAuth only the workspace owner reaches it, and a member's token is 403 `owner_only`. `openemail.me.get()` describes the calling key itself and needs no scope; this reads any key the caller can see. - Scopes: `keys:read`. - Needs a sign-in. - Aliases: `show`, `view`. **Arguments** - `` (required): Key id, the 24 hex characters after `oe_live_`. **Examples** ```bash openemail keys get 4c1b257a66287fd113bd89d0 ``` Print the raw JSON ```bash openemail keys get 4c1b257a66287fd113bd89d0 --json ``` Also available in: API [`GET /keys/{id}`](https://openemail.uk/docs/api/reference/api-keys#get-keys-id); SDK [`keys.get()`](https://openemail.uk/docs/sdk/reference/keys#get). ### `openemail keys create` Mint a new API key and receive its secret once ```bash openemail keys create --name [flags] openemail keys create --data [flags] ``` Creates a live key and resolves with it plus `token`, the whole secret. That is the only time it appears, so store it before doing anything else. Left out, `scopes` is `['emails:send']`, the role is the caller's own or none, the send scope is the caller's own or none (none means every address the workspace owns), and the expiry is the caller's own or none. The workspace cap on live keys applies, as a 422 `workspace_limit_reached`. A key never makes or reaches a key wider than itself. The target has to sit inside the caller on every axis: scopes the caller holds after its own role has narrowed them, the same role when the caller has one, an expiry no later than the caller's when the caller expires, the caller's mode, and a send scope inside the caller's own, where one address never covers its whole domain. Anything wider is 403 `beyond_caller_authority`, and `param` names the axis. Step-up verification, which the app asks for before it mints a key, cannot apply to a call made with a key, so `keys:manage` is a credential that makes credentials. Give it only to automation that provisions keys, narrow that key to the role and send scope it needs, and give it an expiry. - Scopes: `keys:manage`. - Needs a sign-in. - Aliases: `new`, `add`. **Flags** - `--name `: A name, 1 to 60 characters. Required, here or in `--data`. - `--scopes ` (repeatable, default `["emails:send"]`): The scopes the key holds, at least one, each held by the caller. Defaults to `['emails:send']`. - `--role-id `: A role to cap the key. Left out, the caller's own role. A caller with a role can only give its own, and `null` is refused for it. - `--address-allowlist ` (repeatable): Single addresses the key may send as, at most 50, each owned by the workspace. - `--domain-allowlist ` (repeatable): Whole domains the key may send as, at most 25, including addresses added to them later. Leave both lists out to inherit the caller's own; send both empty for none. - `--expires-in-minutes `: Minutes until the key expires, 5 to 5,256,000 (ten years). Left out, the caller's own expiry. - `--data `: The whole `body` as JSON, inline, from a file with @path, or - for standard input. Flags override its keys. **Examples** The required values only ```bash openemail keys create --name 'Billing sender' ``` With optional flags ```bash openemail keys create --name 'Billing sender' --scopes emails:send,emails:read --domain-allowlist billing.acme.com ``` Read the whole body from a JSON file ```bash openemail keys create --data @key.json ``` Also available in: API [`POST /keys`](https://openemail.uk/docs/api/reference/api-keys#post-keys); SDK [`keys.create()`](https://openemail.uk/docs/sdk/reference/keys#create). ### `openemail keys update` Rename a key, change its scopes or send scope, or switch it off and on ```bash openemail keys update [flags] ``` Applies a partial change and resolves with the key as it now stands. `scopes`, `--address-allowlist` and `--domain-allowlist` REPLACE what the key had, and a field left out stays as it was. `enabled: false` switches the key off: every call with it is refused with `inactive_api_key` and it keeps its secret, scopes, role and send scope, so `enabled: true` restores it exactly. That is the reversible alternative to `revoke`. A revoked key cannot be changed, and answers 409 `revoked`. A key never makes or reaches a key wider than itself. The target has to sit inside the caller on every axis: scopes the caller holds after its own role has narrowed them, the same role when the caller has one, an expiry no later than the caller's when the caller expires, the caller's mode, and a send scope inside the caller's own, where one address never covers its whole domain. Anything wider is 403 `beyond_caller_authority`, and `param` names the axis. A key changing itself may only narrow itself. A key narrowed to some domains or addresses only sees the keys whose send scope sits inside its own, so any other is a 404 rather than a refusal. Over OAuth only the workspace owner reaches it, and a member's token is 403 `owner_only`. - Scopes: `keys:manage`. - Needs a sign-in. - Aliases: `edit`. **Arguments** - `` (required): Key id, the 24 hex characters after `oe_live_`. **Flags** - `--name `: A new name, 1 to 60 characters. - `--scopes ` (repeatable): The whole new list of scopes, at least one. - `--address-allowlist ` (repeatable): The whole new list of single addresses. - `--domain-allowlist ` (repeatable): The whole new list of whole domains. - `--enabled`: False switches the key off, true switches it back on. - `--data `: The whole `patch` as JSON, inline, from a file with @path, or - for standard input. Flags override its keys. **Examples** With optional flags ```bash openemail keys update 4c1b257a66287fd113bd89d0 --name 'Billing sender (paused)' --no-enabled ``` Print the raw JSON ```bash openemail keys update 4c1b257a66287fd113bd89d0 --name 'Billing sender (paused)' --no-enabled --json ``` Also available in: API [`PATCH /keys/{id}`](https://openemail.uk/docs/api/reference/api-keys#patch-keys-id); SDK [`keys.update()`](https://openemail.uk/docs/sdk/reference/keys#update). ### `openemail keys delete` Remove a revoked key from the list ```bash openemail keys delete [flags] ``` Deletes a key that has already been revoked. Its request log and activity stay, under `Deleted key`, so the history of what it did is not lost with it. A key that has not been revoked is refused with 409 `not_revoked`, so nothing still calling with it loses its credential without somebody deciding that first. A key never makes or reaches a key wider than itself. The target has to sit inside the caller on every axis: scopes the caller holds after its own role has narrowed them, the same role when the caller has one, an expiry no later than the caller's when the caller expires, the caller's mode, and a send scope inside the caller's own, where one address never covers its whole domain. Anything wider is 403 `beyond_caller_authority`, and `param` names the axis. - Scopes: `keys:manage`. - Needs a sign-in. - Asks you to confirm. - Aliases: `rm`, `del`, `remove`. **Arguments** - `` (required): Key id, the 24 hex characters after `oe_live_`. **Examples** ```bash openemail keys delete 4c1b257a66287fd113bd89d0 ``` Skip the confirmation, for scripts ```bash openemail keys delete 4c1b257a66287fd113bd89d0 --yes ``` Also available in: API [`DELETE /keys/{id}`](https://openemail.uk/docs/api/reference/api-keys#delete-keys-id); SDK [`keys.delete()`](https://openemail.uk/docs/sdk/reference/keys#delete). ### `openemail keys rotate` Give a key a new secret and receive it once ```bash openemail keys rotate [flags] ``` Mints a new secret for a key and resolves with the key plus `token`, `rotationCount` and `rotatedAt`. The id, name, scopes, role, send scope, expiry and request history all carry on; only the secret and `keyLast4` change. There is no overlap window: the old secret stops working the instant this returns. Rotating the calling key itself is what `openemail.me.rotate()` does, and here it is allowed with `keys:write` as well as `keys:manage`. A revoked or expired key cannot be rotated, and answers 409 `revoked` or `expired`. A key never makes or reaches a key wider than itself. The target has to sit inside the caller on every axis: scopes the caller holds after its own role has narrowed them, the same role when the caller has one, an expiry no later than the caller's when the caller expires, the caller's mode, and a send scope inside the caller's own, where one address never covers its whole domain. Anything wider is 403 `beyond_caller_authority`, and `param` names the axis. Rotation hands the caller a working secret for the key, which is why the ceiling is checked against the key as it stands. A key narrowed to some domains or addresses only sees the keys whose send scope sits inside its own, so any other is a 404 rather than a refusal. Over OAuth only the workspace owner reaches it, and a member's token is 403 `owner_only`. - Scopes: `keys:manage`. - Needs a sign-in. - Asks you to confirm. **Arguments** - `` (required): Key id, the 24 hex characters after `oe_live_`. **Examples** ```bash openemail keys rotate 4c1b257a66287fd113bd89d0 ``` Skip the confirmation, for scripts ```bash openemail keys rotate 4c1b257a66287fd113bd89d0 --yes ``` Also available in: API [`POST /keys/{id}/rotate`](https://openemail.uk/docs/api/reference/api-keys#post-keys-id-rotate); SDK [`keys.rotate()`](https://openemail.uk/docs/sdk/reference/keys#rotate). ### `openemail keys revoke` Revoke a key for good ```bash openemail keys revoke [flags] ``` Revokes a key: every later call with it is refused with `revoked_api_key`, and it can never be switched back on, rotated or changed. `reason` is kept on the key and in the activity log. Revoking a key that is already revoked changes nothing and resolves with it as it is. A key may revoke itself, which is how an integration that believes its secret leaked retires it at once. A key never makes or reaches a key wider than itself. The target has to sit inside the caller on every axis: scopes the caller holds after its own role has narrowed them, the same role when the caller has one, an expiry no later than the caller's when the caller expires, the caller's mode, and a send scope inside the caller's own, where one address never covers its whole domain. Anything wider is 403 `beyond_caller_authority`, and `param` names the axis. A key narrowed to some domains or addresses only sees the keys whose send scope sits inside its own, so any other is a 404 rather than a refusal. Over OAuth only the workspace owner reaches it, and a member's token is 403 `owner_only`. - Scopes: `keys:manage`. - Needs a sign-in. - Asks you to confirm. **Arguments** - `` (required): Key id, the 24 hex characters after `oe_live_`. **Flags** - `--reason `: Why, at most 200 characters. - `--data `: The whole `body` as JSON, inline, from a file with @path, or - for standard input. Flags override its keys. **Examples** The required values only ```bash openemail keys revoke 4c1b257a66287fd113bd89d0 ``` With optional flags ```bash openemail keys revoke 4c1b257a66287fd113bd89d0 --reason 'Contractor offboarded' ``` Skip the confirmation, for scripts ```bash openemail keys revoke 4c1b257a66287fd113bd89d0 --yes ``` Also available in: API [`POST /keys/{id}/revoke`](https://openemail.uk/docs/api/reference/api-keys#post-keys-id-revoke); SDK [`keys.revoke()`](https://openemail.uk/docs/sdk/reference/keys#revoke). ### `openemail keys list-requests` List one page of one key's request log ```bash openemail keys list-requests [flags] ``` Returns one page of the calls one key made, newest first, the Requests tab of the key in the app. The request log records every authenticated call a key made: method, path, status, error code, duration, IP and user agent, and never a body or a query string. A call refused before a key could be identified is not in it, and neither is a call made with an OAuth access token. Nothing is pruned, so the log reaches back to a key's first call. `--failed-only`, `since` and `until` are the filters the app offers. A deleted key's log stays readable to a key that is not narrowed. A key narrowed to some domains or addresses only sees the keys whose send scope sits inside its own, so any other is a 404 rather than a refusal. Over OAuth only the workspace owner reaches it, and a member's token is 403 `owner_only`. Add `--all` to walk every page: a table on a terminal, one JSON object per line when piped or with `--ndjson`, and one `{ items, hasMore, nextCursor }` document with `--json`. `--max ` stops after that many items. - Scopes: `keys:read`. - Needs a sign-in. **Arguments** - `` (required): Key id, the 24 hex characters after `oe_live_`. **Flags** - `--failed-only` (default `false`): Only calls answered with a status of 400 or more. - `--since `: Only rows at or after this instant. A `Date` is sent as ISO 8601, and a string must already be one. - `--until `: Only rows before this instant. It has to be later than `since`, or the server answers 400 `invalid_parameter`. - `--limit ` (default `25`): Rows per page, a whole number from 1 to 100. The server defaults to 25. - `--cursor `: The `nextCursor` from the previous page, passed back unchanged. Never build one yourself. - `--all`: Fetch every page and stream the items as they arrive. - `--max `: Stop after this many items. Implies `--all`. - `--ndjson`: Print every item as one JSON object per line. Implies `--all` **Examples** The required values only ```bash openemail keys list-requests 4c1b257a66287fd113bd89d0 ``` With optional flags ```bash openemail keys list-requests 4c1b257a66287fd113bd89d0 --failed-only --limit 50 ``` Walk every page and stop after 100 items ```bash openemail keys list-requests 4c1b257a66287fd113bd89d0 --all --max 100 ``` One JSON object per line when piped ```bash openemail keys list-requests 4c1b257a66287fd113bd89d0 --all > keys.ndjson ``` Also available in: API [`GET /keys/{id}/requests`](https://openemail.uk/docs/api/reference/api-keys#get-keys-id-requests); SDK [`keys.listRequests()`](https://openemail.uk/docs/sdk/reference/keys#listRequests). ### `openemail keys list-activity` List one page of what happened to one key ```bash openemail keys list-activity [flags] ``` Returns one page of one key's audit log, newest first, the Activity tab of the key in the app. Every change to a key is a row: `created`, `updated`, `rotated`, `deactivated`, `reactivated`, `revoked` and `deleted`, plus `auth_failed` for every call that presented the key and was refused. `actor` names who made the change, a person as `@username` or a key as `API key ` in `label`, and `detail.source` says where it came from: `console`, `api`, `mcp` or `documentation`. A deleted key keeps its history, readable to a key that is not narrowed. A key narrowed to some domains or addresses only sees the keys whose send scope sits inside its own, so any other is a 404 rather than a refusal. Over OAuth only the workspace owner reaches it, and a member's token is 403 `owner_only`. Add `--all` to walk every page: a table on a terminal, one JSON object per line when piped or with `--ndjson`, and one `{ items, hasMore, nextCursor }` document with `--json`. `--max ` stops after that many items. - Scopes: `keys:read`. - Needs a sign-in. **Arguments** - `` (required): Key id, the 24 hex characters after `oe_live_`. **Flags** - `--since `: Only rows at or after this instant. A `Date` is sent as ISO 8601, and a string must already be one. - `--until `: Only rows before this instant. It has to be later than `since`, or the server answers 400 `invalid_parameter`. - `--limit ` (default `25`): Rows per page, a whole number from 1 to 100. The server defaults to 25. - `--cursor `: The `nextCursor` from the previous page, passed back unchanged. Never build one yourself. - `--all`: Fetch every page and stream the items as they arrive. - `--max `: Stop after this many items. Implies `--all`. - `--ndjson`: Print every item as one JSON object per line. Implies `--all` **Examples** ```bash openemail keys list-activity 4c1b257a66287fd113bd89d0 ``` Walk every page and stop after 100 items ```bash openemail keys list-activity 4c1b257a66287fd113bd89d0 --all --max 100 ``` One JSON object per line when piped ```bash openemail keys list-activity 4c1b257a66287fd113bd89d0 --all > keys.ndjson ``` Also available in: API [`GET /keys/{id}/activity`](https://openemail.uk/docs/api/reference/api-keys#get-keys-id-activity); SDK [`keys.listActivity()`](https://openemail.uk/docs/sdk/reference/keys#listActivity). ### `openemail keys list-workspace-requests` List one page of the request log of every key ```bash openemail keys list-workspace-requests [flags] ``` Returns one page of every call the workspace's keys made, newest first, the Requests tab of Settings, API keys. The request log records every authenticated call a key made: method, path, status, error code, duration, IP and user agent, and never a body or a query string. A call refused before a key could be identified is not in it, and neither is a call made with an OAuth access token. Nothing is pruned, so the log reaches back to a key's first call. `--key-ids`, `--failed-only`, `since` and `until` are the filters the app offers, and `--key-ids` may name a deleted key. A narrowed key reads only the log of the keys it can see, so naming another key in `--key-ids` matches nothing. Add `--all` to walk every page: a table on a terminal, one JSON object per line when piped or with `--ndjson`, and one `{ items, hasMore, nextCursor }` document with `--json`. `--max ` stops after that many items. - Scopes: `keys:read`. - Needs a sign-in. **Flags** - `--key-ids ` (repeatable): Key ids to read, at most 50, sent comma-separated. Left out, every key the caller can see. - `--failed-only` (default `false`): Only calls answered with a status of 400 or more. - `--since `: Only rows at or after this instant. A `Date` is sent as ISO 8601, and a string must already be one. - `--until `: Only rows before this instant. It has to be later than `since`, or the server answers 400 `invalid_parameter`. - `--limit ` (default `25`): Rows per page, a whole number from 1 to 100. The server defaults to 25. - `--cursor `: The `nextCursor` from the previous page, passed back unchanged. Never build one yourself. - `--all`: Fetch every page and stream the items as they arrive. - `--max `: Stop after this many items. Implies `--all`. - `--ndjson`: Print every item as one JSON object per line. Implies `--all` **Examples** ```bash openemail keys list-workspace-requests ``` With optional flags ```bash openemail keys list-workspace-requests --failed-only --since 2026-09-22T00:00:00Z ``` Walk every page and stop after 100 items ```bash openemail keys list-workspace-requests --all --max 100 ``` One JSON object per line when piped ```bash openemail keys list-workspace-requests --all > keys.ndjson ``` Also available in: API [`GET /keys/requests`](https://openemail.uk/docs/api/reference/api-keys#get-keys-requests); SDK [`keys.listWorkspaceRequests()`](https://openemail.uk/docs/sdk/reference/keys#listWorkspaceRequests). ### `openemail keys list-workspace-activity` List one page of what happened to every key ```bash openemail keys list-workspace-activity [flags] ``` Returns one page of the audit log of every key in the workspace, newest first, the Activity tab of Settings, API keys. Every change to a key is a row: `created`, `updated`, `rotated`, `deactivated`, `reactivated`, `revoked` and `deleted`, plus `auth_failed` for every call that presented the key and was refused. `actor` names who made the change, a person as `@username` or a key as `API key ` in `label`, and `detail.source` says where it came from: `console`, `api`, `mcp` or `documentation`. `--key-ids` narrows it, deleted keys included, and `since` and `until` keep a window. A narrowed key reads only the activity of the keys it can see. Add `--all` to walk every page: a table on a terminal, one JSON object per line when piped or with `--ndjson`, and one `{ items, hasMore, nextCursor }` document with `--json`. `--max ` stops after that many items. - Scopes: `keys:read`. - Needs a sign-in. **Flags** - `--key-ids ` (repeatable): Key ids to read, at most 50, sent comma-separated. Left out, every key the caller can see. - `--since `: Only rows at or after this instant. A `Date` is sent as ISO 8601, and a string must already be one. - `--until `: Only rows before this instant. It has to be later than `since`, or the server answers 400 `invalid_parameter`. - `--limit ` (default `25`): Rows per page, a whole number from 1 to 100. The server defaults to 25. - `--cursor `: The `nextCursor` from the previous page, passed back unchanged. Never build one yourself. - `--all`: Fetch every page and stream the items as they arrive. - `--max `: Stop after this many items. Implies `--all`. - `--ndjson`: Print every item as one JSON object per line. Implies `--all` **Examples** ```bash openemail keys list-workspace-activity ``` With optional flags ```bash openemail keys list-workspace-activity --since 2026-09-01T00:00:00Z ``` Walk every page and stop after 100 items ```bash openemail keys list-workspace-activity --all --max 100 ``` One JSON object per line when piped ```bash openemail keys list-workspace-activity --all > keys.ndjson ``` Also available in: API [`GET /keys/activity`](https://openemail.uk/docs/api/reference/api-keys#get-keys-activity); SDK [`keys.listWorkspaceActivity()`](https://openemail.uk/docs/sdk/reference/keys#listWorkspaceActivity). ### `openemail keys stats` Read what the keys did inside a window ```bash openemail keys stats [flags] ``` Returns the numbers behind the Analytics tab of the API keys page: the mail the keys sent and what became of it, the calls refused because a secret was wrong, revoked or expired, the requests they made and how many failed, the routes they called most with the median time each took, and the status codes they got back. It covers every key you can see, or the ones `--key-ids` names. The window runs from `since` to `until`, and left out it is the 30 days before now. `grain` sets the bucket width of the series and `--offset-minutes` shifts the boundaries so days break where the reader's day does. - Scopes: `keys:read`, `emails:read`. - Needs a sign-in. **Flags** - `--key-ids ` (repeatable): Only these keys, at most 50. Left out, every key you can see. - `--since `: The start of the window, a `Date` or an ISO 8601 instant. Defaults to 30 days before `until`. - `--until `: The end of the window, not included. Defaults to now. - `--grain ` (default `"day"`): Bucket width: `minute`, `hour` or `day`, defaulting to `day`. - `--offset-minutes ` (default `0`): Minutes east of UTC to bucket in, from -840 to 840, defaulting to 0. **Examples** ```bash openemail keys stats ``` With optional flags ```bash openemail keys stats --grain day ``` Print the raw JSON ```bash openemail keys stats --json ``` Also available in: API [`GET /keys/stats`](https://openemail.uk/docs/api/reference/api-keys#get-keys-stats); SDK [`keys.stats()`](https://openemail.uk/docs/sdk/reference/keys#stats).