--- title: "openemail me" description: "Every command in this namespace, with its arguments, flags and examples." url: "https://openemail.uk/docs/cli/reference/me" area: "CLI" category: "Reference" --- # openemail me Every command in this namespace, with its arguments, flags and examples. ## Commands ### `openemail me get` Describe the API key or access token making the call ```bash openemail me get [flags] ``` Returns what the key is: its id, whether it is a live or test key, the workspace it belongs to, the scopes it can use and the allowlists that narrow who it may send as. It needs no scope, because a key may always describe itself, so it works with any valid key and is the first call to make when a request is refused. `scopes` is the effective list and the only one that authorises anything. It is the scopes the key was created with intersected with the permissions of the role it was issued under, resolved on every request rather than frozen into the key. `grantedScopes` is what the key was created holding and `roleId` names the role that capped it, so a scope present in `grantedScopes` and missing from `scopes` was removed by that role. A 403 `insufficient_scope` on a key the console shows as holding the scope is almost always this, and the fix is to change the role rather than to mint another key. A key can be narrowed by whole domains, by individual addresses, or by both. `domainAllowlist` holds whole domains, and the key may send as any address on one of them, including addresses created after the key was. `addressAllowlist` holds individual addresses and covers only those. Both null means the key may send as any address the workspace owns. When either is set the key is narrowed, and reads of sent mail, tracking and calendar narrow to the same set. An address whose domain is already in `domainAllowlist` is dropped from `addressAllowlist` when the key is saved, so the two lists never overlap. Called with an OAuth access token it describes the token instead, and `object` tells the two apart. A key answers `object: 'api_key'` and `kind: 'apiKey'`. A token answers `object: 'oauth_token'` and `kind: 'oauth'`, with `id` null, `clientId` naming the connected app, `roleId` null and `mode` always `live`. `scopes` and `grantedScopes` are the permissions the person approved for the app, and the allowlists are the addresses and domains the app may reach. `expiresAt` is when that approval runs out, or null when it never does. It is not the expiry of the access token, which the app renews with its refresh token. - Needs a sign-in. - Aliases: `show`, `view`. **Examples** ```bash openemail me get ``` Print the raw JSON ```bash openemail me get --json ``` Also available in: API [`GET /keys/self`](https://openemail.uk/docs/api/reference/account#get-keys-self); SDK [`me.get()`](https://openemail.uk/docs/sdk/reference/me#get). ### `openemail me ping` Check that a key or access token authenticates ```bash openemail me ping [flags] ``` An authentication smoke test. It runs the same key check every other endpoint runs and answers `ok: true` with the key id, its mode, the workspace and the effective scopes. It needs no scope, so a key with none at all still gets a 200. Use it in a health check or at process start to fail fast on a revoked, expired or mistyped key. The answer carries the same scope detail as `me.get`, `scopes` effective and `grantedScopes` as created with `roleId` naming the cap between them, but it leaves out both allowlists. Call `me.get` when you need to know which domains and which addresses the key may send as. An OAuth access token gets the same answer with `kind: 'oauth'`, `keyId` null, `clientId` naming the connected app, `roleId` null and `mode` always `live`. A key answers `kind: 'apiKey'`. - Needs a sign-in. **Examples** ```bash openemail me ping ``` Print the raw JSON ```bash openemail me ping --json ``` Also available in: API [`GET /ping`](https://openemail.uk/docs/api/reference/account#get-ping); SDK [`me.ping()`](https://openemail.uk/docs/sdk/reference/me#ping). ### `openemail me rotate` Replace the calling key's own secret ```bash openemail me rotate [flags] ``` Mints a new secret for the key making the call and resolves with the same body as `me.get` plus `token`, the new key in full. That is the only place the value appears, so store it before anything else. Everything else about the key survives. The id, the mode, the scopes, the role ceiling, the address allowlist and the domain allowlist all come back unchanged, so `token` is the only thing your configuration has to change. Because the id is stable, an audit trail joined on it stays joined up across rotations. There is no overlap window. The old secret stops authenticating the moment this call commits, and neither secret can be shown again. Write `token` to wherever the key is read from before the next request. A lost response is the bad case: the rotation may have committed to a secret nobody saw, which leaves the key unusable until someone mints it a new secret in the console. - Scopes: `keys:write`. - Needs a sign-in. - Asks you to confirm. **Examples** ```bash openemail me rotate ``` Skip the confirmation, for scripts ```bash openemail me rotate --yes ``` Also available in: API [`POST /keys/self/rotate`](https://openemail.uk/docs/api/reference/account#post-keys-self-rotate); SDK [`me.rotate()`](https://openemail.uk/docs/sdk/reference/me#rotate).