keys.getKey when you have the key’s ID, for example on a management screen. Use keys.whoami when you have the key itself, for example when a user pastes it into a support form. Both return the same fields, except keys.whoami can’t return the decrypted key.
Create a root key with the permissions listed on this page under Root Keys in the dashboard sidebar. CLI commands can instead use a session from unkey login with the required permissions. See Permission reference for every permission.
api.*.read_key or api.<api_id>.read_key. Adding decrypt: true to keys.getKey additionally needs api.*.decrypt_key or api.<api_id>.decrypt_key. See Root key permissions.
By identifier
The
key_... identifier from keys.createKey, a verification response, a listing, or the dashboard. 3 to 255 characters matching ^[a-zA-Z0-9_]+$.Include the plaintext for a key created as recoverable. See Recoverable keys.
err:unkey:data:key_not_found.
By plaintext
The full key including its prefix, 1 to 512 characters. Any change to it gives a not-found error.
keys.whoami doesn’t check whether the key is enabled, expired, or within its limits, and it doesn’t record a verification. Use keys.verifyKey when you need a verdict.
Response fields
Last successful verification as Unix milliseconds. It updates about once a minute, so it can lag real usage by up to a minute.
remaining (integer or null for unlimited) and, when configured, refill with interval, amount, and refillDay.The decrypted key. Returned only by
keys.getKey with decrypt: true on a recoverable key. keys.whoami never returns it.apis.listKeys, which returns the same objects. See Listing keys.