> ## 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.
# Rails and payment methods
> What each payment method needs, which currencies the deposit rails carry, and how a rail id is put together.
Rail ids are opaque strings you copy from `GET /dapi/v1/banks`. This page is what they mean and what each payment method needs.
## What each method needs
A payment method is defined by the identifiers it routes on. The same matrix governs both directions: the `requisites.fields` you read off an open rail, and the `fields` you send when you save a contact.
`+` means every group is required. `or` means any one of the alternatives in that group.
| Method | Identifiers |
| --------------- | --------------------------------- |
| `sepa` | `iban` |
| `swift` | `accountNumber` or `iban` + `bic` |
| `ach` | `accountNumber` + `routingNumber` |
| `fedwire` | `accountNumber` + `routingNumber` |
| `ukfps` | `accountNumber` + `routingNumber` |
| `uaefts` | `iban` |
| `pix` | `pixKey` or `accountNumber` |
| `spei` | `accountNumber` or `iban` |
| `npp` | `accountNumber` + `routingNumber` |
| `nip` | `accountNumber` |
| `breb` | `paymentKey` or `accountNumber` |
| `pse` | `accountNumber` or `iban` |
| `transfers_3_0` | `accountNumber` or `iban` |
These do not open as deposit rails; they are destinations you can save as contacts and pay out to.
| Method | Identifiers |
| --------------- | ------------------------------------------------------------------------------------------- |
| `bdt_ewallet` | `financialInstitutionId` + `phoneNumber` |
| `bdt_local` | `financialInstitutionId` + `branchNumber` + `accountNumber` |
| `bob_local` | `financialInstitutionId` + `accountNumber` + `accountKind` |
| `brl_local` | `financialInstitutionId` + `branchNumber` + `accountNumber` + `accountKind` |
| `cad_eft` | `financialInstitutionId` + `accountNumber` + `routingNumber` |
| `clp_local` | `financialInstitutionId` + `accountNumber` + `accountKind` |
| `cny_alipay` | `phoneNumber` |
| `cny_wechatpay` | `phoneNumber` |
| `cop_local` | `financialInstitutionId` + `accountNumber` + `accountKind` |
| `crc_local` | `financialInstitutionId` + `iban` + `phoneNumber` |
| `dkk_local` | `iban` |
| `dop_ewallet` | `financialInstitutionId` + `phoneNumber` |
| `dop_local` | `financialInstitutionId` + `accountNumber` + `accountKind` |
| `egp_local` | `financialInstitutionId` + `iban` |
| `fednow` | `accountNumber` + `routingNumber` |
| `gtq_ewallet` | `financialInstitutionId` + `phoneNumber` |
| `gtq_local` | `financialInstitutionId` + `accountNumber` + `accountKind` + `phoneNumber` |
| `hkd_fps` | `financialInstitutionId` + `accountNumber` |
| `hnl_local` | `financialInstitutionId` + `accountNumber` + `accountKind` + `phoneNumber` |
| `idr_ewallet` | `financialInstitutionId` + `phoneNumber` |
| `idr_local` | `financialInstitutionId` + `accountNumber` |
| `ils_local` | `financialInstitutionId` + `iban` |
| `inr_local` | `accountNumber` + `routingNumber` |
| `inr_upi` | `accountNumber` |
| `jmd_local` | `financialInstitutionId` + `branchNumber` + `accountNumber` + `accountKind` + `phoneNumber` |
| `jpy_local` | `financialInstitutionId` + `branchNumber` + `accountNumber` + `phoneNumber` |
| `krw_local` | `financialInstitutionId` + `accountNumber` |
| `myr_local` | `financialInstitutionId` + `accountNumber` |
| `nok_local` | `iban` |
| `php_ewallet` | `financialInstitutionId` + `phoneNumber` |
| `php_local` | `financialInstitutionId` + `accountNumber` |
| `pkr_ewallet` | `financialInstitutionId` + `phoneNumber` |
| `pkr_raast` | `financialInstitutionId` + `accountNumber` or `iban` |
| `pln_local` | `iban` |
| `rtp` | `accountNumber` + `routingNumber` |
| `sar_local` | `financialInstitutionId` + `iban` |
| `sle_local` | `financialInstitutionId` + `phoneNumber` |
| `thb_local` | `financialInstitutionId` + `accountNumber` |
| `try_fast` | `financialInstitutionId` + `iban` |
| `tzs_local` | `financialInstitutionId` + `phoneNumber` |
| `ugx_local` | `financialInstitutionId` + `phoneNumber` |
| `vnd_local` | `financialInstitutionId` + `accountNumber` |
| `xof_local` | `financialInstitutionId` + `phoneNumber` |
| `zmw_local` | `financialInstitutionId` + `phoneNumber` |
Alongside the identifiers, every requisite and every contact carries a `holder`: `type` (`individual` or `business`) with `firstName` and `lastName`, or `businessName`. Some methods route on the name alone and ignore the account identifiers for matching; the identifiers are still required.
## Deposit-rail coverage
These are the methods a client can hold a rail in, and the currency each one settles from. A payer wires that currency; the client's wallet is credited in a stablecoin.
| Method | Currency | Region |
| --------------- | -------- | -------------------- |
| `ach` | USD | United States |
| `fedwire` | USD | United States |
| `swift` | USD | International |
| `sepa` | EUR | Euro area |
| `ukfps` | GBP | United Kingdom |
| `uaefts` | AED | United Arab Emirates |
| `pix` | BRL | Brazil |
| `spei` | MXN | Mexico |
| `npp` | AUD | Australia |
| `nip` | NGN | Nigeria |
| `breb` | COP | Colombia |
| `pse` | COP | Colombia |
| `transfers_3_0` | ARS | Argentina |
`GET /dapi/v1/banks` is authoritative and narrower: it returns only the rails a given client may hold, after its residency is taken into account. Read `currency` and `method` off that response rather than deriving them from this table.
## Rail ids
An id usually reads `{method}_{named|pooled}-{bank}` — the ids written this way on these pages, `sepa_named-bank_a` and `ach_named-bank_b`, stand in for the real ones — though a few carry no bank segment at all (`wire_named`). Two parts matter:
* **`named`** — the client's own legal name is on the account. Payers see the client; nothing else is needed for the money to be attributed.
* **`pooled`** — one partner account serves many clients, and each deposit is attributed by the `paymentReference` on the account details. The payer must quote it.
The bank segment is the partner behind the rail and is not something to branch on. Treat the whole id as opaque: compare it for equality, store it, copy it into `POST /dapi/v1/banks`, and never parse it or show it to your customers. Ids are per environment — one you hardcoded in the sandbox does not exist in production.
## Accounts a rail settles into
`supportedAccounts` on a rail record is which of the client's accounts that rail can deliver into.
A rail's token is fixed when the rail is opened, so choosing the token means choosing the rail id: rails that can deliver either token ship as a pair of ids, one per token, with the EURC variant's id ending in `_eurc`. `destinationAccount` on the record echoes what the open rail delivers.
Per deposit the choice is on the money-in call: `POST /dapi/v1/payins` takes a `destinationAccount`, and a token no rail of the client's settles into answers `422 payin_not_available` with `details.options[]` listing the pairs that do.
`feeBps` on the rail record is HEVN's deposit fee in basis points for that rail. It is a whole number: `25` is 0.25%.
## Chain codes
On-chain destinations use a chain code, not a rail: a wallet [contact](/whitelabel/payouts#save-an-address-as-a-contact) carries one in `crypto.chain`, and a quoted on-chain [payin](/whitelabel/payins#quote-an-on-chain-transfer) carries one in `originChainId`.
`GET /dapi/v1/chains` answers the live list rather than this page: every chain, its EVM `chainId`, and each token's `decimals` and contract `address`. `settlement: true` marks the chain balances live on, and a token's `account` names the account it holds when a client can hold a balance in it. Read it once at startup instead of hardcoding what follows.
`eth` · `bsc` · `avax` · `op` · `arb` · `pol` · `sol` · `base` · `gnosis` · `tron` · `xrp` · `zec` · `doge` · `ltc` · `btc` · `cardano` · `bera` · `sui` · `near` · `near_intents` · `xlayer` · `plasma` · `ton` · `stellar` · `monad` · `starknet` · `aptos` · `adi` · `bch`
A client balance settles on **Base**, in USDC or EURC, so a contact on Base holding either token is paid straight out of it. A contact on any other chain in this list, or expecting any other token, is paid through a [cross-chain route](/whitelabel/payouts#a-routed-payout-is-priced) — the same `POST /dapi/v1/payouts`, quoted with `fromChainId` and `toChainId`, refused with `409 payout_not_fundable` when routing is unavailable for the account.
## Market rates
`GET /dapi/v1/rates?from=EUR&to=USDC` converts one currency or token into another at the current market rate, before any transfer exists:
```json theme={null}
{ "fromCurrency": "EUR", "toCurrency": "USDC", "rate": "1.14776038", "indicative": true }
```
Both sides accept a fiat code or a token symbol, so a fiat pair, a token pair and a mixed pair answer the same way. It is a display rate and says so: the rate a transfer settles at comes from that transfer's own quote, and a rail's deposit rate comes from `GET /dapi/v1/banks/{rail}/rate`. A currency HEVN does not price answers `404 not_found`.
Every field of the KYB document, its accepted values, and the document slots.