Keys and end users

One key per customer, and why never a header.

Attribution lives on the credential, not in the request. A key is minted for one end user and bound to their wallet at that moment, so the caller never asserts who they are.

Why not a header

A header is an assertion. Anything holding the key could set it to anything, and your usage records would be a record of what callers claimed rather than what happened.

Minting

POST /v1/keys
{ "endUserId": "ada@acme.com", "name": "Ada laptop" }

Key shape

Field	Meaning
`keyPrefix`	`ak_<code>_test_<six>` — the leader, safe to display
`lastFour`	The last four characters, for recognition
`actorType`	`human` or `agent` — an agent's spend is separable
`revokedAt`	Set on revocation; the row stays as evidence

Revoked keys are still listed. A key that vanishes on revocation takes the evidence with it.

← Model aliases Spend caps →