> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gethevn.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> HEVN accounts are non-custodial in both products. 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 customer creates and owns their account through Sign in with HEVN, a HEVN-hosted popup on the integrator's site; the integrator's backend holds a developer key, operates linked accounts and books their payouts, and the account holder approves every payout in that popup. The developer key signs only for the integrator's own wallet; it never signs a client's money.
> 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 a customer's own account linked to the integrator through Sign in with HEVN (POST /dapi/v1/connect/sessions, then POST /dapi/v1/clients/link); there is no API call that creates one. 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. Developer keys have an IP allowlist and no scopes. Remote transfers are at /api/v1/remote_spend_limit and take a remote transfer key (rsl_) in X-Api-Key, bounded by an onchain spend permission the account holder grants. They are different credentials and neither works on the other surface. The HEVN CLI is discontinued.

# Coverage

> The currencies and payment methods money can arrive in and leave by, the chains a payout can reach, and why the authoritative answer is always per client.

Coverage has two sides and they are not symmetric. A client can **receive** fiat only over a rail it
has opened, in one of a short list of currencies. It can **pay** a beneficiary in many more — every
payout method below is a destination you can save as a contact, whether or not the same market can
send money the other way.

> [!WARNING]
>
> This page is the shape of the catalogue, not a promise for your account. Rail availability is
> decided per integrator, per client and per partner, and the only authoritative answers are
> `GET /dapi/v1/banks` for a given client and
> `GET /dapi/v1/contacts/{contactId}/capabilities` for a given contact. Read them; do not derive
> from this page.

## Money in

These are the methods a client can hold a virtual account in, and the currency each one receives. A
payer wires that currency; the client is credited in the account that rail settles into.

| Method | Currency | Market |
| - | - | - |
| `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 |

Money can also arrive on chain with no rail at all: anything sent to the client's `baseSmartWallet`
on Base is its balance the moment it confirms, and a transfer from another chain can be quoted first
with `POST /dapi/v1/payins` carrying `originChainId`. Neither path needs a verified client — only a
`ready` one.

## Money out

Every method here is a destination a contact can hold. Grouped by market, with the identifiers each
one routes on in [Rails and payment methods](https://docs.gethevn.com/whitelabel/reference/rails.md#what-each-method-needs).

### Americas

| Currency | Market | Methods |
| - | - | - |
| USD | United States | `ach`, `fedwire`, `fednow`, `rtp` |
| CAD | Canada | `cad_eft` |
| MXN | Mexico | `spei` |
| BRL | Brazil | `pix`, `brl_local` |
| ARS | Argentina | `transfers_3_0` |
| COP | Colombia | `breb`, `pse`, `cop_local` |
| CLP | Chile | `clp_local` |
| BOB | Bolivia | `bob_local` |
| CRC | Costa Rica | `crc_local` |
| GTQ | Guatemala | `gtq_local`, `gtq_ewallet` |
| HNL | Honduras | `hnl_local` |
| DOP | Dominican Republic | `dop_local`, `dop_ewallet` |
| JMD | Jamaica | `jmd_local` |

### Europe, Middle East and Africa

| Currency | Market | Methods |
| - | - | - |
| EUR | Euro area | `sepa` |
| GBP | United Kingdom | `ukfps` |
| PLN | Poland | `pln_local` |
| DKK | Denmark | `dkk_local` |
| NOK | Norway | `nok_local` |
| TRY | Türkiye | `try_fast` |
| ILS | Israel | `ils_local` |
| AED | United Arab Emirates | `uaefts` |
| SAR | Saudi Arabia | `sar_local` |
| EGP | Egypt | `egp_local` |
| NGN | Nigeria | `nip` |
| XOF | West African CFA franc zone | `xof_local` |
| SLE | Sierra Leone | `sle_local` |
| TZS | Tanzania | `tzs_local` |
| UGX | Uganda | `ugx_local` |
| ZMW | Zambia | `zmw_local` |

### Asia-Pacific

| Currency | Market | Methods |
| - | - | - |
| AUD | Australia | `npp` |
| JPY | Japan | `jpy_local` |
| KRW | South Korea | `krw_local` |
| CNY | China | `cny_alipay`, `cny_wechatpay` |
| HKD | Hong Kong | `hkd_fps` |
| INR | India | `inr_local`, `inr_upi` |
| IDR | Indonesia | `idr_local`, `idr_ewallet` |
| MYR | Malaysia | `myr_local` |
| PHP | Philippines | `php_local`, `php_ewallet` |
| PKR | Pakistan | `pkr_raast`, `pkr_ewallet` |
| THB | Thailand | `thb_local` |
| VND | Vietnam | `vnd_local` |
| BDT | Bangladesh | `bdt_local`, `bdt_ewallet` |

`swift` is the exception to the grouping above: it is an international wire, not a domestic
system, and it carries USD to a beneficiary bank in most of the world.

A method suffixed `_ewallet` routes to a mobile wallet on a phone number rather than to a bank
account. A method suffixed `_local` is that market's domestic clearing system. Neither changes how
you call the API: both are a contact, then a payout.

## On chain

A client balance settles on **Base**, in USDC or EURC. A wallet contact on Base holding either token
is paid straight out of the balance, with nothing converted and no partner involved. A contact on any
other chain, or expecting any other token, is paid through a cross-chain route — the same
`POST /dapi/v1/payouts`, quoted with `fromChainId` and `toChainId`.

`GET /dapi/v1/chains` answers the live list: every chain, its EVM `chainId`, and each token's
`decimals` and contract `address`. Read it at startup rather than hardcoding the codes in
[Chain codes](https://docs.gethevn.com/whitelabel/reference/rails.md#chain-codes).

## Between a client's own accounts

A client holds up to three accounts: `USDC` and `EURC` on its Base smart wallet, and
`FDIC_USD` when a partner bank holds a dollar virtual account for it. `POST /dapi/v1/swaps` moves
money between any two of them it holds, and which pairs can be served at a given moment is answered
by pricing them — `POST /dapi/v1/swaps/preview` returns the best route or refuses with
`422 swap_route_unavailable` ([Swaps](https://docs.gethevn.com/whitelabel/swaps.md)).

## What actually decides availability

Four things narrow the catalogue above, and each one has a refusal that names it.

| What | Effect | You see |
| - | - | - |
| Your integrator agreement | Which products HEVN enables for you at all | `403 rail_not_available` on `POST /dapi/v1/banks` |
| The client's residency and legal form | Which of those products this client may request | The product is absent from `GET /dapi/v1/banks` for that client |
| The client's verification state | Whether a requested virtual account can go `active` | `blockers[]` on the record: `kyb_required`, `verification_required`, `terms_required` |
| The partner behind the rail | Whether it is accepting business right now | `503 provider_unavailable`, or the rail reports `channel_unavailable` |

The cheapest way to find out what a client can really do is to create one, verify it and read
`GET /dapi/v1/banks` — in the sandbox exactly as in production. Naming the currencies and markets
you sell into is part of the conversation that switches your integrator account on; see
[Going live](https://docs.gethevn.com/whitelabel/going-live.md#what-hevn-must-enable).

> [card] [Next: Fees](https://docs.gethevn.com/whitelabel/reference/fees.md)
>
> Where a fee is declared, where it is quoted, and which side of a payment absorbs it.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.