Build Transactions with Solana Swap API

Build a real Solana swap flow end-to-end: direct routing logic, quote inspection, transaction build, wallet signing, submission, confirmation, and fallback strategy

Try the live demo: https://solana-swap-api.vybenetwork.com

Most swap content leans heavily into quote/routing. That is useful, but builders usually need a full swap execution article that starts at routing philosophy and ends at onchain confirmation.

This article is built as a full Swap Execution walkthrough using Swap Overview as the anchor, and it explicitly covers every related section:

• Swap overview
• Fetch Quotes & Routes
• Build Transaction
• Slippage & Fees
• Supported Protocols
• Gas Fee Sponsorship
• Privy Integration

The complete swap lifecycle

Quote

• Request route + pricing preview via get_swap_quote_proxy.
• Output: expected output, impact, route plan.

Build

• Create an unsigned transaction with policy via do_swap_proxy.
• Output: unsigned base64 transaction.

Sign

• Sign client-side in wallet (wallet adapter or embedded wallet).
• Output: signed transaction.

Submit

• Broadcast to Solana with sendRawTransaction.
• Output: transaction signature.

Confirm

• Confirm finality with confirmTransaction.
• Output: confirmed/finalized state.

Most “swap API” content stops at step 2. Real product execution quality lives in steps 3–5 as well.

Why direct routing is a product decision

Swap Overview emphasizes direct DEX program calls where possible, with fallback routes when needed. The practical point is not ideology. It is execution shape:

• fewer intermediary accounts
• fewer instructions
• smaller transactions
• fewer failure surfaces

That is especially relevant for high-frequency products, onboarding paths, and embedded wallets where extra transaction bloat shows up immediately as failed or expensive swaps.

Hidden overhead comparison (what teams usually miss)

Routing path

• Aggregator-heavy: extra intermediary hops
• Direct-first: direct program calls when available

Instruction count

• Aggregator-heavy: typically higher
• Direct-first: typically lower

Transaction size

• Aggregator-heavy: typically larger
• Direct-first: typically smaller

Failure points

• Aggregator-heavy: more moving parts
• Direct-first: fewer moving parts

Fallback behavior

• Aggregator-heavy: depends on aggregator policy
• Direct-first: explicit direct-first plus fallback

The key takeaway: this is not just “cost optimization.” It affects reliability and UX.

Step 1: quote and inspect route quality

Use get_swap_quote_proxy to evaluate:

• expected output amount
• route plan and protocol
• pool context
• price impact
• slippage constraints

Don’t treat quote as a number-only endpoint. It is your pre-trade risk and quality check.

Step 2: build a transaction with explicit policy

Then call do_swap_proxy to build the unsigned transaction. This stage is where you enforce product policy:

• router preference
• slippage tolerance
• fee handling
• ATA creation behavior
• optional mode flags (for embedded wallet workflows)

The most important security boundary remains unchanged: the user still signs client-side.

Key build fields developers usually care about

Core request fields:

• accountAddress: the wallet the transaction is being built for
• amount: swap amount in UI units
• inputMintAddress: source token mint
• outputMintAddress: destination token mint

High-impact optional controls:

• slippage and autoCalculateSlippage
• gasless
• router
• protocol
• poolAddress
• simulate
• swapFee and partner

This is what makes the build endpoint practical for production apps rather than just demo flows.

Step 3–5: sign, submit, and confirm

Many articles skip this, but this is where production behavior is proven:

1. Sign in wallet (or embedded signer)
2. Submit raw transaction
3. Confirm and handle success/failure explicitly

If your article does not include confirmation handling, it is not a full swap execution guide.

Router modes and fallback strategy

In practice, teams need both efficiency and coverage. A direct-first strategy with fallback gives you both:

• direct execution where supported
• broader coverage when direct routes are unavailable

That framing is more useful than “pick one router forever.” It lets you tune for your product and token universe.

Router and protocol controls in practice

Router choice is often about execution policy:

• vybe: direct-first behavior for efficiency
• titan: broader route coverage
• jupiter: fallback breadth for exotic paths

Protocol targeting is useful when your app needs venue control instead of black-box routing. Common protocol families include Pump.fun/Pumpswap, Raydium variants, Meteora variants, and Sanctum.

For advanced products, combining router plus protocol is usually the cleanest way to balance control and fill reliability.

Slippage and fees: execution guardrails, not UI settings

Slippage & fees should be treated as execution controls:

• low slippage can increase failed trades in volatile windows
• high slippage can create poor fills
• fee model affects net user output and repeat behavior

Execution teams should define slippage policy by token/liquidity class, not with one static global value.

Protocol coverage is a product feature

Supported protocols matters because route behavior differs by venue type (launch pools, concentrated liquidity, staking-related liquidity).

Coverage quality directly changes what products you can safely ship:

• consumer swap UI
• recurring DCA flows
• bot execution logic
• treasury rebalance tooling

Embedded wallets and gas sponsorship

Two supporting docs are critical for real distribution:

• Privy integration for embedded wallet compatibility and transaction-shape constraints
• Gasless mode for fee-sponsored onboarding flows

This is where swap APIs move from “works for power users” to “works for normal users.”

Gas Fee Sponsorship (why it matters)

Gas sponsorship is not cosmetic. It fixes the first-user problem:

• user has tokens but no SOL
• user can’t complete first swap without extra onboarding steps
• conversion drops before value is delivered

If your app targets new users, a gas-sponsored path should be treated as a core growth feature, not an optional add-on.

Privy Integration (why it matters)

Privy flows need stricter transaction-shape discipline around signing and blockhash handling. In practice, this means you should test embedded-wallet execution as a first-class path:

• build transaction with embedded wallet constraints in mind
• verify signature flow in real client environment
• confirm submission + confirmation behavior under production-like latency

If this isn’t tested separately, swaps can work in wallet-adapter QA but fail in embedded-wallet production.

Where this fits in real products

This execution model is especially useful for:

• wallet apps that need unsigned transaction build + direct user signing
• trading interfaces that expose route/protocol preferences
• onboarding flows where gas sponsorship removes first-swap friction
• embedded wallet products that need predictable build/sign behavior
• bots and treasury tools that require explicit execution policy

The pattern is simple and durable: quote first, inspect route quality, build unsigned transaction, sign client-side, submit, then confirm.

Implementation checklist (ship-ready)

• Quote includes route, impact, and protocol visibility
• Build step enforces router/slippage/fee policy
• Signing happens client-side only
• Submission and confirmation are first-class code paths
• Fallback logic is explicit and observable
• Embedded wallet mode tested (if applicable)
• Gas sponsorship tested for onboarding wallets (if applicable)

Final takeaway

This piece should be positioned as Swap Overview + execution flow, not as quote coverage.

A complete Solana swap article has to show the whole chain:

• route philosophy
• quote inspection
• transaction build
• signature boundary
• submission + confirmation
• fallback and onboarding modes

That is the difference between “here is an endpoint” and “here is a production swap system.”

Further reading

Guides

• https://docs.vybenetwork.com/docs/swap-overview
• https://docs.vybenetwork.com/docs/get-quote
• https://docs.vybenetwork.com/docs/build-transaction
• https://docs.vybenetwork.com/docs/slippage-fees
• https://docs.vybenetwork.com/docs/supported-protocols
• https://docs.vybenetwork.com/docs/gasless-mode
• https://docs.vybenetwork.com/docs/privy-integration

API reference

• https://docs.vybenetwork.com/reference/get_swap_quote_proxy
• https://docs.vybenetwork.com/reference/do_swap_proxy