Funding your account
There are two rails for getting money in, each with its own endpoint:
| Rail | Endpoint | Returns |
|---|---|---|
| Crypto | GET /v2/deposit-addresses | one address per (asset, chain) pair |
| Fiat (CLP) | GET /v2/deposit-instructions | Skipo's bank accounts |
Both are read-only and take a Tier-1 key with the transfers:read scope.
:::danger Not to be confused with GET /v2/contacts
/v2/contacts lists your withdrawal destinations — addresses Skipo can send money to.
The endpoints on this page list Skipo addresses and accounts that you send to.
Sending funds to a contact's address does not credit your account. :::
Crypto deposits
GET /v2/deposit-addresses?assetSymbol=USDT
[
{
"assetSymbol": "USDT",
"networkId": "TRON",
"networkName": "Tron (TRC20)",
"address": "TDunhSa7jkTNuKrusUTU1MUHtqXoBPKETV",
"tag": null,
"tagRequired": false,
"tagType": null,
"tagLabel": null
}
]
Addresses are stable: Skipo does not rotate or retire them, so it is safe to cache one and re-display it. Reading this endpoint never mints a new address.
An (asset, chain) pair with no address yet is simply absent from the list rather than listed empty. It appears once provisioning completes.
Two ways a deposit is lost
1. Sending over the wrong chain. An address is only valid on the networkId it is listed
under. Several chains share an address format — every EVM chain does — so the same string can
appear under more than one networkId. Skipo credits only the chains it sweeps: funds sent over
another one are not recoverable.
2. Omitting the tag. Where tagRequired is true, the tag is mandatory. On those chains
Skipo shares one address across accounts and the tag is the only thing identifying yours; a
deposit without it does not credit automatically.
Read tagRequired, not tag !== null — it is a property of the chain, not of that row.
tagType tells you which of the two names the chain uses (MEMO or DESTINATION_TAG) as a
machine key; tagLabel is the display text.
Minimums and fees
Not on this resource. They live on GET /v2/assets:
networks[].minimumDeposit— the smallest amount that will be credited- asset-level
minimumDeposit— the platform floor
Deposits carry no fee. The fee returned by GET /v2/deposits is always "0" and exists
only for shape parity with withdrawals.
Fiat deposits (CLP)
GET /v2/deposit-instructions
[
{
"assetSymbol": "CLP",
"accountHolder": "Skipo Chile SpA",
"accountHolderNationalId": "77.777.777-7",
"bankName": "Banco de Chile",
"accountType": "Cuenta Corriente",
"accountNumber": "00-123-45678-90",
"accountEmail": "deposits@skipo.com",
"mustMatchSenderNationalId": true
}
]
:::danger The transfer must come from an account in your own name Skipo matches an incoming transfer to an account by the originator's national id (in Chile, the RUT) as the bank reports it. There is no reference code, no memo and no per-customer account number to fall back on.
A transfer sent from someone else's account — a company account for a personal balance, a partner, a friend, a payment processor — cannot be matched and is not credited. Recovering it is a manual support case, not an automatic return.
Check which id Skipo holds for you with GET /v2/account (nationalId).
:::
accountHolderNationalId is Skipo's id — it identifies the destination. It is not the id the
money has to come from; that one is yours.
More than one account is returned, and they are interchangeable
A deposit into any of them credits the same balance. They exist to spread volume across banks, not to segregate funds.
Prefer the one at the bank you already use: in Chile a same-bank transfer settles faster and costs less than an interbank one.
CLP only
There is no USD bank account. GET /v2/deposit-instructions never returns one, and
GET /v2/deposit-addresses?assetSymbol=CLP returns [] — fiat has no chain. To fund in USD, use
the crypto rail.
Reconciling a deposit that has arrived
GET /v2/deposits publishes, at the top level, who sent the money and when it moved:
{
"id": "dp_01HZY0...",
"assetSymbol": "CLP",
"amount": "500000",
"status": "COMPLETED",
"createdAt": "2026-08-20T14:04:42.000Z",
"senderName": "JANE DOE",
"senderNationalId": "12.345.678-9",
"senderBankId": "BANCO_DE_CHILE",
"senderAccount": "00-123-45678-90",
"bankReference": "987654321",
"bankDescription": "transferencia",
"valueDate": "2026-08-20T14:03:11Z"
}
All are null on a crypto deposit, and on a fiat deposit an operator entered by hand.
senderNationalId means "this was you"
It is published only when it matches your own. If the money came from anyone else the field is
null — so read it as "this deposit was self-funded", never as "this is who paid".
A null there does not mean the deposit went unattributed. It means the sender was not you.
valueDate is not createdAt
valueDate is when the money moved; createdAt is when Skipo credited it. On production the
median gap between the two is 91 seconds, and they fall in different months about once in 27
months.
To close a month, use valueDate and join to the ledger on source.id.
:::caution Date filters bound createdAt
startDate and endDate on GET /v2/deposits and GET /v2/ledger filter on creation time, not
value date. A month-end query has to read valueDate back and check it.
:::
bankReference
The operation number the bank assigned the movement. Present on nearly every automated deposit, absent on operator-entered ones. Free-form and short — treat it as an opaque string for reconciliation, never parse it.
bankDescription is a different thing: the free text the sender put on the transfer, and it is
empty on most deposits.
Finding out without polling
A deposit emits deposit.created. The webhook payload carries the same fields as
GET /v2/deposits, sender attribution included.
⚠️ An automated fiat deposit emits exactly one webhook: it is born COMPLETED, so no
deposit.status.updated follows.
See also: Webhooks · Withdrawal fees · Deposits · Assets.