Keys that prove themselves on every call
Per-client keys, HMAC-SHA256 over body and timestamp — replay-protected by construction
Every API call carries an HMAC-SHA256 signature over its body and a timestamp, so a replayed or tampered request is rejected before it reaches business logic. Creating or changing a key is itself an approval-gated action, and the key that authenticates a call never signs a transaction — a signature needs an MPC share.
Share the Trust, Guard the Keys
A bearer token is a standing invitation
A static credential that grants whatever its holder asks turns one leaked environment variable into an unbounded incident, and a log entry attributed to the API names nobody. Vaultody authenticates every call cryptographically, keeps key creation on the approval path, and leaves signing authority where a stolen credential cannot reach it.
- Signed, not bearerEach call carries an HMAC-SHA256 signature over its body and a timestamp. A replayed or tampered request is rejected before it reaches business logic.
- Key creation is governedCreating or changing a key is one of the 26 approval-gated action types — it does not complete because someone clicked it.
- Authentication is not signingA key authenticates a caller. Moving funds needs an MPC share and a policy decision, so a stolen key cannot sign on its own.
How it works
Authenticated per request, bounded by role and policy
Keys are per client and carry a role, and the policy engine applies to whatever they raise: below your threshold flows proceed, above it the request waits for people exactly as a dashboard request would. IP whitelisting is offered alongside as a platform access control.
- ✓HMAC-SHA256 over the request body, plus a timestamp — replay and tampering both fail
- ✓Idempotency keys on transaction creation, so a retry cannot double-spend
- ✓An explicit version header pins your integration while defaults move on
- ✓Creating or changing a key is recorded like any other sensitive change
What a key is, and is not
Plus the plan line it sits behind.
Frequently asked questions
Get answers to commonly asked questions.
Does an API key bypass policy?
No. It is bounded by its role and by the policy engine; above your threshold the request waits for people, whichever surface raised it.
What can a stolen key do?
Not sign. A signature needs an MPC share held by a co-signer, and the policy engine still applies to anything the key raises.
Who can issue a key?
Key creation and changes are approval-gated, so they take the approval path rather than one person's click, and each one is recorded.
Share the Trust Guard the Keys
Credentials that prove themselves, on a path that records itself.