> ## Documentation Index
> Fetch the complete documentation index at: https://hevninc.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> HEVN has two products and they authorize money differently. Self-serve (the General tab): the person who owns the email holds the only key and signs for themselves. Whitelabel (the Whitelabel and REST API tabs): the integrator's backend holds a developer key, signs on behalf of client accounts it created, and HEVN co-signs. Never mix the two models in an answer.
> Use HEVN's terms exactly. A rail is a bank route a client can request. A virtual account (bnk_) is an opened rail. Account details are what a payer needs in order to wire money, and arrive in a field named requisites. A client is an account the integrator created; the business behind it is the integrator's customer. A contact is a saved destination; a beneficiary is the party at the far end of a fiat payout. Every departure of money is a payout, to a bank account or to a wallet alike.
> Never name a banking partner. Say 'a licensed banking partner'.
> There are no published fee rates, spreads or minimums. Prices come from a quote on a specific payment; direct pricing questions to HEVN rather than inventing numbers.
> The whitelabel API is at /dapi/v1 and takes a developer-key session plus an X-Hevn-Account header. The CLI uses an app API key in X-Api-Key. They are different credentials and neither works on the other surface.
# Overview
> Open partner-bank payment details for your own customers and move their money from your backend, with one API and one key.
With the whitelabel API you open partner-bank payment details for your own customers and move their
money from your backend — no HEVN UI, no HEVN operator, no signature from your customer.
```mermaid theme={null}
flowchart TB
K["Your backend
holds the developer key"]
I["Your integrator account
holds the registered public key"]
K -->|"one key, registered once"| I
I -->|"you create and act for these"| Wallet
subgraph Wallet["Client account — one per customer"]
W["Base smart wallet
the balance lives here"]
B["Bank rails
account details in the client's legal name"]
T["Contacts
saved payout destinations"]
B -->|"deposits settle into"| W
W -->|"payouts leave for"| T
end
```
## What you can build
* **A marketplace with on-chain escrow.** Lock a buyer's funds in a contract while a seller
delivers, then capture them minus your fee.
* **A payroll or payables platform.** Collect from an employer, pay contractors to their own bank
accounts in their own currencies.
* **An embedded payments account.** Give each of your customers payment details in their own company
name, a balance, a statement and outgoing payments, under your brand.
All three are assembled from the same five calls, in different orders —
[What you can build](/whitelabel/use-cases) takes each one end to end.
## How it works
You hold one HEVN account — your **integrator account** — and it creates and controls other HEVN
accounts, one per customer. Those are your **clients**. Each client is a real account: it has a legal
identity you submit for review once, **rails** that produce account details in its own name, a balance,
and a ledger.
Every client balance is a stablecoin balance on that client's own Base smart wallet. Fiat arriving
over a rail is converted by a partner bank and settles into that wallet; fiat leaving is the same
journey in reverse. See [How money moves](/whitelabel/how-money-moves).
Your backend authenticates with a **developer key** — a P-256 keypair whose private half never leaves
your server. You register its public half once, together with the source IPs it may be used from,
and the session it mints reaches this API and nothing else. The same key authorizes money movement:
HEVN builds each payment, echoes its exact terms, you check them and sign, HEVN executes. Nothing is
ever constructed by you, and nothing moves without your signature. See
[Developer key](/whitelabel/developer-key) and [Signing](/whitelabel/signing).
A client becomes usable by passing four gates in order — created, verification document complete,
application approved, rail active. After that, one payment is two calls: `POST /dapi/v1/payouts`
books and prices it, `POST /dapi/v1/payouts/{payoutId}/confirm` signs it.
Every route on these pages sits under `https://api.hevn.finance/dapi/v1`, or
`https://sandbox-api.hevn.finance/dapi/v1` in the sandbox. The spec is served by the API itself:
browse it at [`/dapi/v1/docs`](https://sandbox-api.hevn.finance/dapi/v1/docs) and fetch the schema
from `/dapi/v1/openapi.json`.
## What you get from HEVN, and what you keep
| You build | HEVN provides |
| --------------------------------------------------------- | ------------------------------------------------------------------------------- |
| Your product, your UI, your customer relationship | The account records, the partner-bank rails, the on-chain balances, the ledger |
| The onboarding form your customer fills in | The submission to the partner bank, and the review status you read back from it |
| The decision to pay, and the signature that authorizes it | The pricing, the operation, the execution and the receipt |
Two things HEVN switches on for you rather than the API: your integrator account itself, and the
permission to create clients. Both are a conversation, in the sandbox as in production — see
[Going live](/whitelabel/going-live).
## Where to start
Three products assembled out of the five moves every integration is made of.
Nine steps in the sandbox: a client company that holds testnet USDC and has sent some of it out, signed by your key.
One diagram and five rules: where a balance lives, who converts fiat, what is never instant.
Who can move a client's money, what HEVN cannot do alone, and what happens if your key leaks.