Solana aggregators for developers: Jupiter, DFlow, OKX, and the rest

On Solana, “aggregator” usually means a swap router that splits and multi-hops across venues so your user gets a better fill than hitting one AMM pool. For developers the question is narrower: what API surface, execution model, and extras does each provider actually ship?

This page is a builder map of the main layers — not a price bake-off. Liquidity and quotes change every second; contracts and docs change slower. Always re-check the linked docs before production.

Aggregator vs venue (don’t mix them up)

Integrating Raydium only is a single-venue trade. Integrating Jupiter or DFlow is “best effort across the graph.” Flint is prop-AMM infra for market makers (aggregator-facing liquidity), not a retail swap aggregator API. Imperial is a perps router — related idea, different product class.

At a glance (developer jobs)

*Jupiter’s surface area spans Swap, Price, Tokens, Portfolio, Trigger, Lend, Prediction, etc. — not only swap quotes.

Jupiter — the aggregation platform

Docs: developers.jup.ag. Portal: Developer Platform. Hub: dev.jup.ag. Existing DevRels: Jupiter overview.

What you get as a developer: a full DeFi API platform with Swap API V2 as the center of gravity.

Two swap paths

• Meta-Aggregator — GET /swap/v2/order + POST /swap/v2/execute. Engines compete: Metis (on-chain multi-hop), JupiterZ (RFQ market makers), Dflow, OKX. You sign an assembled tx; Jupiter manages landing (RTSE slippage, Beam-style pipeline). Jupiter platform fees apply; gasless / payer options exist. Best default for “just get the best price.”
• Router — GET /swap/v2/build (+ optional /submit). Metis only — raw instructions for custom v0 txs, CPI, memos, your own landing. No Jupiter swap fee on this path. Use when you must modify the transaction.

# Meta path (conceptual)
GET  https://api.jup.ag/swap/v2/order?...   # tx + requestId
# sign
POST https://api.jup.ag/swap/v2/execute     # managed land

# Router path (conceptual)
GET  https://api.jup.ag/swap/v2/build?...   # instructions
# assemble / simulate / send (or /submit)

Beyond swap

• Price, Tokens (search/metadata), Portfolio
• Trigger — limit orders & DCA (LO & DCA docs)
• Lend, Prediction, Send, Studio, and more on the same portal keys
• AI — @jup-ag/cli, agent skills, docs MCP, Trading MCP at https://mcp.jup.ag (large tool surface)
• Auth / ops — keyless low RPS for prototypes; x-api-key tiers, firewall, logs, analytics on the portal

When to pick Jupiter: wallets, bots, and apps that want one vendor for quotes + landing + token/price data, or need CPI via /build. Meta path already includes DFlow and OKX as competing engines — you do not need a second aggregator only to “add those brands” unless you want their direct APIs or features (WS books, Proof, multi-chain).

DFlow — trading infrastructure API

Docs: pond.dflow.net. Product: dflow.net. X: @DFlowProtocol.

What you get: a Solana-native Trading API focused on spot execution and market data streams. Spot is described as no protocol fee (you can still add your own platform fee). Dev endpoints work without a key; request a key for production limits.

• Order flow — request order → user signs → submit to RPC; imperative quote/swap and declarative intent-style endpoints; swap-instructions for composability
• JIT routing — re-optimizes at execution time as liquidity moves
• WebSockets — quote stream (top of book), book stream (ten levels), priority-fee stream
• Sponsored / gasless swaps — app pays fees so users need less SOL
• Venues / tokens lists, priority-fee helpers
• Proof — separate product: link KYC’d identity to a wallet for gating (not a swap feature)
• AI — Agent CLI, skills, docs MCP

When to pick DFlow directly: you want first-class streaming market data + fine venue control, sponsored swaps, intent/imperative shapes, or identity via Proof — or you want DFlow as primary router rather than only as a Jupiter meta engine.

OKX DEX / Onchain OS

Entry: Onchain OS · developer portal under OKX Web3. Trade capability is powered by the OKX DEX aggregation engine with multi-chain coverage (EVM + Solana).

What you get (platform shape):

• Trade — DEX aggregation, intelligent routing, maximize received amount
• Market — multi-chain prices and transaction data
• Wallet — agentic wallet patterns (TEE key handling in their agent stack)
• Payments — agent payment scenarios
• Integration via Open API and Skills / MCP for agents

When to pick OKX: multi-chain apps that already live in the OKX Web3 stack, or need the same vendor for EVM + Solana routing and market data. On Solana-only products, OKX also appears as a competing engine inside Jupiter’s meta-aggregator — so “access OKX liquidity” can mean either direct Onchain OS or Jupiter /order.

Titan

App: titan.exchange (also titandex.io). Consumer-facing swap UI with order types (instant, limit, DCA, private/prime-style modes in the product UI).

Developer surface: less open than Jupiter/DFlow — no Foundation-style public docs hub comparable to developers.jup.ag / pond.dflow.net in this research pass. Community/third-party clients exist in the wild; treat Titan primarily as a user product / venue competitor in the UI layer unless you have a private API agreement. Flint’s public materials previously listed Titan among live aggregator destinations for prop flow — that is venue connectivity, not a substitute for a full public integrator API.

How the graph actually nests

Meta path ≈ hire a committee of routers. Direct path ≈ hire one specialist plus their extras.

Practical chooser

Implementation notes that bite everyone

Related DevRels

• Jupiter
• Flint (prop AMM)
• Imperial (perps router)
• Phoenix · Solana Developer MCP

Resources

• Jupiter: Swap V2 · llms.txt · Trading MCP
• DFlow: Trading API · llms.txt
• OKX: Onchain OS
• Titan: titan.exchange

Bottom line

For most Solana apps, Jupiter’s meta-aggregator is the default developer surface: multiple engines (including DFlow and OKX), managed landing, and a whole portal around price/tokens/orders. DFlow is the specialist trading API when you want streams, JIT, sponsored swaps, and Proof. OKX is the multi-chain / Onchain OS choice. Titan is a strong user product with a thinner public integrator story. Pick by execution control and adjacent features, not by logo count — meta routing already folds several logos into one /order.