approved. See Set up Pods Ramp to get a user to that state, and Track Pods Ramp status to poll both KYC approval and quote status.
Pods Ramp uses the same Swap v2 quote routes across every supported country: originChain/destinationChain of fiat select the local payment rail, and tokenIn/tokenOut select the fiat currency or on-chain asset. The examples below use Brazil’s Pix rail, the only rail live today; Mexico, Colombia, and Argentina will use their own local rail and currency through the same routes once live.
Send all requests from your backend with x-api-key; never expose PODS_API_KEY to a browser or mobile client.
Supported Brazil Pix routes
Choose the pair with
tokenOut / tokenIn (USDC contract vs BRLA contract). Pods will not route a Pix→USDC request to the BRLA rail, or the reverse.
Integrate with
GET /v2/swap/quote only. Pass destinationAddress on onramps (Pix QR in the response) or originAddress + pixKey on offramps (transactionData ready to sign). New integrations should not call POST /v2/swap/bytecode.The quote response top-level id is the Action id (use with GET /actions/{id}). Track money-movement progress with GET /v2/swap/status/{quoteId} using quote.quoteId — these are different identifiers.Token addresses
Onramp: Pix BRL to USDC
Use this when a verified user pays Pix and receives USDC on Base or Monad. When you includedestinationAddress, the quote response includes payment instructions directly.
destinationChain to monad and tokenOut to Monad USDC from the table above.
Successful response:
paymentInstructions to the user in the shape of the local rail — for Pix, paymentInstructions.pix.copyPaste is the copy-paste code. Use quote.feeBreakdown to display payment-rail, Pods/customer, and bridge or slippage charges. There is no EVM transaction to sign on onramp (transactionData is empty; chainId is null). Poll GET /v2/swap/status/{quote.quoteId} until fulfilled.
Offramp: USDC to Pix BRL
Use this when a verified user sends USDC on-chain and receives Pix. The user must have anapproved Ramp profile for the same originAddress, and that wallet must belong to your customer on Pods. Pass originAddress and pixKey on the quote — the response includes transactionData ready to sign. Sign on the selected origin chain (base → 8453, monad → 143).
Successful response:
transactionData, in order, from originAddress on the selected origin chain (batch same-chain legs into one atomic tx when your wallet stack supports it — see Execute a swap). The first transaction transfers USDC to the returned depositAddress; the next transaction records the transfer for tracking. After Pods detects and collects the USDC payment, Pods creates the local-rail payout to pixKey. Track with GET /v2/swap/status/{quote.quoteId}.
Onramp: Pix BRL to BRLA (Polygon)
Use this when a verified user pays Pix and receives BRLA on Polygon directly in their wallet. Avenia mints BRLA todestinationAddress — there is no Deframe inventory hop and no Pods/customer swap markup. Quote amounts mirror Avenia’s fixed-rate response (Avenia rail fees may still appear as paymentRail in feeBreakdown).
Prefer this rail when the product needs BRLA itself. Prefer Pix→USDC when the product needs USDC on Base or Monad. Do not call Avenia’s APIs directly for either public pair — use
GET /v2/swap/quote.
Successful response shape matches other onramps:
paymentInstructions.pix.copyPaste for the user to pay, quote.tokenOut with BRLA (decimals 18, chainId 137), feeBreakdown without Pods/customer platform charges, empty transactionData, and chainId: null. After Pix settles, Avenia mints BRLA to destinationAddress. Track with GET /v2/swap/status/{quote.quoteId}.
Offramp: BRLA (Polygon) to Pix BRL
Use this when a verified user sends BRLA on Polygon and receives Pix. Amounts pass through Avenia with no Pods/customer markup. PassoriginAddress and pixKey on the quote; the response includes transactionData (BRLA transfer + track) for Polygon (chainId 137).
Execute
transactionData from originAddress on Polygon (chainId 137). After Pods validates the transfer, Avenia pays Pix to pixKey. Track with GET /v2/swap/status/{quote.quoteId}.
Onramp: Pix BRL to BRS (Solana)
Use this when a verified user pays Pix and receives BRS on Solana. Pricing is 1:1 after decimal scale (BRLA 18 decimals ↔ BRS 6 decimals). There is no Pods/customer swap markup. The user never holds or sends BRLA — Pods settles that inventory internally. The Ramp KYCwalletAddress for this pair must be the user’s Solana public key, and destinationAddress must match it.
Successful response shape matches other Pix onramps:
paymentInstructions.pix.copyPaste for the user to pay, quote.tokenOut with BRS (decimals 6, chainId 0), feeBreakdown without Pods/customer platform charges, empty transactionData, and chainId: null. After Pix settles, Pods sends BRS to destinationAddress. Track with GET /v2/swap/status/{quote.quoteId}.
Offramp: BRS (Solana) to Pix BRL
Use this when a verified user sends BRS on Solana and receives Pix. Amounts pass through 1:1 inventory with no Pods/customer markup. PassoriginAddress (the approved Solana wallet) and pixKey on the quote.
The origin payload is Solana, not an EVM transaction array. Default output=bytecode returns type: intra-chain-solana with transactionData.rawTransaction (base64). That transaction transfers BRS to the Pods inventory ATA and includes Memo V1 { version: 1, actionId } where actionId is the quote UUID (quote.quoteId), not the Action ObjectId. Sign and submit that transaction from originAddress.
Solana wallets that assemble instructions themselves can request output=instructions (Solana-origin only). EVM and fiat origins reject instructions with OUTPUT_NOT_SUPPORTED.
Sign
transactionData.rawTransaction from originAddress on Solana. After Pods confirms the inbound BRS transfer (Memo V1 quoteId), Avenia pays Pix to pixKey. Track with GET /v2/swap/status/{quote.quoteId}.
Onramp to yield: Pix BRL to Morpho hyperUSDCa (Monad)
Deposit Pix BRL directly into Morpho Hyperithm USDC Apex on Monad. The flow matches the plain USDC onramp — onlytokenOut is the vault share token (hyperUSDCa) instead of USDC.
Successful response:
quote.tokenOut.decimals is the vault share decimals (18). expectedAmountOut is a raw share amount of hyperUSDCa, not USDC. Store it so you can redeem the exact deposited shares later on the offramp.
There is no on-chain transaction for the user to sign on this side. After Pix settles, Pods converts to USDC on Monad, mints hyperUSDCa, and sends the shares to destinationAddress.
Offramp from yield: Morpho hyperUSDCa (Monad) to Pix BRL
Redeem Morpho hyperUSDCa shares and receive Pix.amountIn must be a raw share amount of hyperUSDCa — not a USDC amount and not a principal / currentPosition value from the wallet endpoint (see Check yield position and profit below).
Successful response includes
quote plus transactionData / chainId / id (same shape as the USDC offramp). Execute every transaction in transactionData, in order, from originAddress on Monad (chainId 143). The first transaction redeems hyperUSDCa to USDC and sends USDC to depositAddress; the next records the transfer for tracking. Pods validates the redeem before creating the Pix payout to pixKey.
Check yield position and profit
For Morpho hyperUSDCa positions, useGET /v2/wallets/{wallet} and find the entry where strategy matches Morpho Hyperithm on Monad.
spotPosition.currentPosition, principal, profit, and cumulativeProfit are reported in USDC terms, even though the wallet holds hyperUSDCa shares on-chain. Do not use those values as amountIn for a yield-to-Pix quote — use the on-chain share balance or the share amount stored from the onramp quote.
If the user wants to exit into USDC on Monad without Pix, use that strategy’s withdraw bytecode endpoint (underlying-token amount) — see the yield strategy guides.
Offramp to a third party
Use this when a verified user wants to convert USDC (base or monad) into a fiat payment sent to someone else, instead of paying themselves back. This is the same offramp flow as above, with two differences: set thirdParty=true on the quote, and pass the recipient’s pixKey (normal offramp assumes the Pix key belongs to the same person as originAddress; third-party offramp does not).
The response includes
transactionData like a normal offramp. Execute and track status the same way; only the recipient of the resulting payout differs.
Reference: