Core concepts

Keys and end users

One key per end user, 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 balance 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.

Create an end user and mint a key

seams users create ada --email ada@firm.com --bundle pro
seams keys mint --user ada --bundle pro --cap 5.00 --label "Ada laptop"

# ak_acme_m8avt…SIrY
# warning  shown once; store it now

Read and change the ceiling

seams keys show key_01J8Q…0x2m
seams keys cap key_01J8Q…0x2m --limit 10
seams users show ada

Freeze and revoke

seams users freeze ada
seams users unfreeze ada
seams keys revoke key_01J8Q…0x2m --yes

Key shape

FieldMeaning
keyPrefixak_<code>_<six>, the leader, safe to display
lastFourThe last four characters, for recognition
revokedAtSet on revocation; the row stays as evidence

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