openemail.me

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 None 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 with object set to 'api_key' and kind set to 'apiKey'. A token answers with object set to 'oauth_token' and kind set to 'oauth', with id and roleId set to None, clientId naming the connected app 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 None when it never does. It is not the expiry of the access token, which the app renews with its refresh token.

An authentication smoke test. It runs the same key check every other endpoint runs and answers with ok set to True, 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 set to 'oauth', keyId and roleId set to None, clientId naming the connected app and mode always 'live'. A key answers with kind set to 'apiKey'.

Mints a new secret for the key making the call and returns the key as me.get describes it, without kind, 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, and build the next client from it, because a client keeps sending the secret it was created with. 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.