You’ll need an API key to follow this guide. Contact the Vanish team via Discord to get one during onboarding.
Prerequisites
1. Environment Setup
Before starting, make sure you have the following available:- Vanish API key - provisioned during onboarding
- Solana RPC endpoint - any standard Solana RPC URL
- User keypair - the Ed25519 keypair for the wallet you’re trading from
- Solana balance - enough SOL to cover the deposit and transaction fees
2. Set Up the Client
Set up your Vanish HTTP client and Solana connection. These are used throughout the rest of the guide.3. Sign Requests
Several endpoints require a signed message proving ownership ofuser_address. Sign with the user’s Ed25519 keypair and base64-encode the result. The message format varies by endpoint - see Signing Requests for all formats.
4. Fund Your Account
Before trading, you need a Vanish balance. This involves three steps: fetching a deposit address, sending funds on-chain, then committing the transaction to Vanish.Get a deposit address
GET /deposit_address for full reference. Always fetch a fresh address before each deposit - addresses may rotate to ensure maximum privacy.Commit the deposit to Vanish
Once confirmed on-chain, notify Vanish by calling
POST /commit with the transaction signature.If the status is
pending, poll /commit again with the same tx_id until it resolves to completed.5. Build a Swap Transaction
Vanish wraps your swap instructions - it does not build the route itself. Fetch an unsigned transaction from your DEX aggregator of choice and pass it to Vanish.Critical: When building the swap transaction, set the one-time wallet as the transaction signer - not the user’s wallet. Pass the one-time wallet address wherever your aggregator asks for the signing wallet or user public key.
Get a one-time wallet from Vanish
GET /trade/one-time-wallet for full reference. Never reuse this address - fetch a fresh one for every trade.6. Execute the Trade
Submit the swap transaction to Vanish viaPOST /trade/create. Vanish wraps and submits it via Jito, returning a tx_id.
This step uses oneTimeWallet, swapTransaction, TARGET_MINT, and AMOUNT from the previous step.
7. Commit the Trade
Always callPOST /commit after every trade - whether it succeeded, failed, or expired on-chain. This resolves the user’s balance from its pending state.
| Status | Meaning |
|---|---|
completed | Trade settled: balance updated |
pending | On-chain confirmation or compliance check in progress: poll again shortly |
failed | Transaction rejected on-chain: balance released |
expired | Not confirmed in time: balance released |
8. Non-Jito Variant (Self-Broadcast)
By default, Vanish submits via Jito bundle and returns only atx_id. If you want to broadcast yourself - for custom retry logic or a low-latency RPC - add the prefer_non_jito object to the same /trade/create request from step 6.
Use
split_repay: 1 on the non-Jito route. Higher values increase transaction size and risk exceeding Solana’s limit./trade/create request body:
transaction yourself instead of using the tx_id directly:
9. Check Balances
SeePOST /account/balances for full reference.
10. Recover Interrupted Flows
If your app crashes after submitting a trade but before calling/commit, the user’s balance is held in a pending state. Call POST /account/pending on startup to catch and resolve these.
Lamport Reference
All SOL amounts in the Vanish API are in lamports. SPL token amounts use the token’s own decimal precision.| Amount | Lamports |
|---|---|
| 1 SOL | 1,000,000,000 |
| 0.012 SOL (loan_additional_sol) | 12,000,000 |
| 0.001 SOL (minimum recommended Jito tip) | 1,000,000 |
Review Your Integration
Before going live, work through these pages to complete your integration. Each one is the full reference for its part of the API.Integration Guide
The Integration Guide is the full reference for every flow - deposit, trade, and withdraw. Go through it to verify:
- Every field in your
/trade/createrequest is correct, includingsplit_repayandloan_additional_sol - Your signing format matches the exact message string for each endpoint type (read, trade, withdraw)
- You understand the interrupted flow recovery pattern using
/account/pending
Error Handling
The Error Handling page covers what happens when things go wrong. Go through it to verify:
- You handle all five
/commitstatuses (completed,pending,failed,expired,rejected) correctly - You’re polling
/commitwith the sametx_idwhen status ispending, not creating a new transaction - You call
/account/pendingon startup to catch any uncommitted transactions
FAQ
The FAQ covers the most common integration mistakes. Go through it to verify:
- You’re fetching a fresh one-time wallet for every trade - never reusing one
- Your swap transaction is unsigned before being passed to
/trade/create - Your timestamps are in milliseconds, not seconds
- Your signature is base64-encoded, not base58 or hex
- You understand the same-wallet-in, same-wallet-out compliance rule for withdrawals
