Either of these endpoints will give you the asset identifiers needed for quotes:
GET /ramp/assets — Requires auth. Returns all rampable stablecoins and stablebonds for the specified blockchain. The currency parameter controls sort priority (matching assets appear first). Best for building integrations where you already know the customer’s wallet.
GET /lookup/stablebonds — Public, no auth. Returns all stablebonds across all chains with pricing and supply data. Best for exploring what’s available before onboarding a customer.
Use the identifier from either response as the asset value in your quote.
Asset identifier format differs by chain:
Solana — Base58 mint address (e.g. AvvetPGuuB5FD5m86fpw3LtDKyQoUFT1mG9WarNQLW4q)
Stellar — CODE:ISSUER format (e.g. CETES:GC3CW7...)
EVM (Base, Polygon) — Raw contract address only (e.g. 0xcC77c598d42f2f78Beb42C91d12B9d4041a5cE29)
Using SYMBOL:0x... on EVM chains will return UnsupportedBlockchain.
2
Create a Quote — POST /ramp/quote
Show Details
All orders require a quote. Quotes expire after 2 minutes. For onramps, set type: "onramp" with the fiat currency as sourceAsset and the token identifier as targetAsset. See POST /ramp/quote for the full schema.
Partner fees: If your organization has a partner fee configured, it is applied automatically. To override per-quote, add "partnerFeeBps": 100 (0–500) to the request body. See Partner Fees for details.
3
Create an Order — POST /ramp/order
Show Details
The quoteId carries the direction, blockchain, and amounts from your quote — no need to repeat them. The response includes orderId and depositClabe (the CLABE the customer wires MXN to in production). See POST /ramp/order for the full schema.
curl -X POST https://api.sand.etherfuse.com/ramp/order \ -H "Authorization: <api_key>" \ -H "Content-Type: application/json" \ -d '{ "orderId": "<uuid>", # You generate this UUID "bankAccountId": "<bank_account_uuid>", # From onboarding "cryptoWalletId": "<wallet_uuid>", # From onboarding "quoteId": "<quote_id_from_step_1>" # From Step 2 }'
One open order per bank account + amount. If a customer already has an open order for the same amount on the same bank account, creating a second order will be rejected. The first order must be cancelled before a new one with the same amount and bank account can be created.
The response includes a statusPage URL — e.g. https://devnet.etherfuse.com/ramp/order/<order_uuid>. Open it in a browser to track progress, sign transactions, or debug without polling the API.
4
Simulate the Fiat Deposit — POST /ramp/order/fiat_received
Show Details
In production, the customer sends MXN to the deposit CLABE. In sandbox, simulate the deposit using the Simulate Fiat Received endpoint with the orderId from the previous step.
This endpoint is sandbox-only. In production, fiat deposits are detected automatically via STP.
The deposit amount must match the order amount. In production, if a customer sends an amount that does not match the open order, the funds will be returned to the sender. Make sure the customer transfers the exact amount specified in the order.
5
Verify Completion — GET /ramp/order/{order_uuid}
Show Details
Poll the order status or listen for webhooks. Status progression: created → funded → completed. See GET /ramp/order for the full response schema.
When onramping to a Stellar wallet for the first time, the wallet may not have an on-chain account or the required trustline for the target token. Etherfuse handles this automatically using claimable balances — no pre-setup required from the user.
Pass walletAddress in the quote request. The system checks whether the wallet exists on-chain and has a trustline. If setup is needed, the quote fee (feeBps / feeAmount) will include a one-time onboarding cost to cover the XLM needed for account creation and/or trustline reserve.
Create the order as usual. The wallet used for the order must match the walletAddress from the quote.
After the order completes, the order response will include two new fields:
stellarClaimableBalanceId — The Stellar claimable balance ID (hex)
stellarClaimTransaction — An unsigned Stellar transaction XDR (base64) containing ChangeTrust and ClaimClaimableBalance operations
The user signs and submits the claim transaction. This single transaction adds the trustline and claims the tokens in one step. The user signs stellarClaimTransaction with their Stellar wallet and submits it to Horizon.
If the wallet already has an account and trustline, the flow is identical to a normal onramp — no claimable balance is used, and stellarClaimableBalanceId / stellarClaimTransaction will not be present on the order.
If the wallet needs setup, the response feeBps will be higher than the standard trading fee (e.g., 70 bps instead of 20 bps). The additional cost covers XLM account funding.
The user (or your application) signs stellarClaimTransaction and submits it to Stellar Horizon:
// Using Stellar SDKconst tx = TransactionBuilder.fromXDR( order.stellarClaimTransaction, networkPassphrase);tx.sign(userKeypair);await server.submitTransaction(tx);
After submission, the user’s wallet will have the trustline and the tokens.
The claim transaction uses the wallet’s current sequence number. If the user submits other transactions before claiming, the sequence number may become stale and the claim transaction will fail. In that case, your application can rebuild the claim transaction from the stellarClaimableBalanceId and asset info in the order response.