One platform, two doors
Everything operable by humans and by code, under one set of rules
Every action has both a screen and an endpoint. A transaction request raised by a script is evaluated by the same policy engine, approved by the same people and recorded in the same audit trail as one raised by hand.
Share the Trust, Guard the Keys
A console and an API that disagree is a governance gap
Platforms often ship a dashboard for people and an API for machines, and the two drift. A policy applies on one surface and not the other, the log records two different vocabularies, and the safe path becomes whichever one the team happens to use. Rules that only hold when a human is watching are not rules. Vaultody keeps one set of rules behind both surfaces: where a request came from changes nothing about what is enforced — only who has to be present.
- One policy engine, both doorsPolicy evaluation is identical whichever surface raised the request. The rule does not know, and does not care, which one it was.
- One approval pathApprovals reach the mobile co-signer no matter where the request originated, and an approval is an organisational act — separate from the signature it authorises.
- One audit trailEvery transaction request lands in the same append-only record, naming the actor whether it is a person or a key.
How it works
The dashboard
Vault, team, policy, automation and transaction management in the browser: create vaults and vault accounts, derive addresses, raise a transfer, edit rules, invite people, read history. Sensitive actions do not complete because someone clicked them — they enter the same approval-gated flow a transfer does, policy edits included.
- ✓Vaults, accounts, addresses and assets managed in one place
- ✓26 sensitive action types are approval-gated, policy edits among them
- ✓Transaction history exports as CSV, per vault and per period
The API
The same operations programmatically, with per-client keys. Every 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 — and creating or changing a key is itself an approval-gated action, so an integration cannot quietly widen its own mandate.
- ✓Idempotency keys on transaction creation, so a retry cannot double-spend
- ✓An explicit version header pins your integration while defaults move on
- ✓Signed webhook events push each state change, so nothing has to poll
The path a transfer takes, whichever door it came through
Four stages, and only the first one differs.
A person creates the transfer in the dashboard, or your service posts a transaction request with an HMAC-signed call. From here on it is the same object.
The governance layer evaluates the vault's rules: amount band, named approvers, required quorum and the rolling window the band is measured over.
Approvers confirm on the mobile co-signer, or an automated co-signer clears the flows you predefined — always inside the rule, never around it.
The parties run the threshold signature, the transaction is broadcast and tracked, and signed webhook events push each state change to your backend.
Surface specification
Everything your integration engineer will ask in the first hour.
Where the two surfaces are not identical
Entry runs on the dashboard and the mobile co-signer, with no webhook endpoints and no server co-signing key. If your integration is code-first, start at Standard.
An API key is bounded by its role and by the policy engine. Above your threshold the request waits for people, whichever surface raised it — that is the point, not a gap.
A request can be raised from either surface, but the approval that authorises it is an act on the mobile co-signer, or an automated co-signer you have configured for that flow.
Transaction, access and delivery evidence are complete. A single log of every administrative action taken in the dashboard is not there yet.
Frequently asked questions
Get answers to commonly asked questions.
Is the API a subset of the dashboard?
Vaults, accounts, addresses, assets, transaction requests and webhooks are managed from either surface, and both go through the same policy engine. Where a rule requires human approval, that approval happens on the mobile co-signer regardless of where the request came from.
Which plans include API access?
The dashboard is on every plan; API requests are included from Standard, along with webhook endpoints — three on Standard, five on Business.
How do we know a webhook is really from you?
Check the HMAC signature header against your webhook secret — standard practice, and non-optional in our docs.
