Solana Trading Bot API: Build a Powerful 5-Stage Data Layer

Every Solana trading bot API stack succeeds or fails at the data layer, not the strategy layer. Most bots poll REST endpoints for new tokens and arrive late. They enter pools without security checks and get caught by hidden taxes or mintable supply. They enrich every token they see and burn their compute unit (CU) budget on tokens that were never tradeable.

This guide builds the pipeline for a Solana trading bot API differently, using Birdeye Data: a multi-chain market data layer covering real-time prices, trades, liquidity, security data, and holder stats. The entire Solana trading bot API data layer runs on 5 stages.

The pipeline is built around one rule: each stage is a gate for the next one. A token only earns deeper (and more expensive) analysis after it survives the cheaper checks upstream. Discovery is a free-flowing stream, security gating rejects most of it, and only the survivors ever reach screening, monitoring, or holder profiling.

Direct Answer: Build the Solana Trading Bot API Data Layer in 5 Stages

To build a Solana trading bot data layer with Birdeye Data, you need 5 stages covering discovery, security gating, screening, position monitoring, and holder profiling.

1. Subscribe to SUBSCRIBE_NEW_PAIR and SUBSCRIBE_TOKEN_NEW_LISTING over WebSocket to stream brand-new pools and listings the moment they appear, with GET /defi/v2/tokens/new_listing as REST backfill.
2. Call GET /defi/token_security and GET /defi/token_creation_info to reject scams (hidden taxes, mintable supply, mutable metadata), and GET /defi/token_overview to confirm real liquidity depth before entry.
3. Call GET /defi/token_trending and GET /defi/v3/token/list to bulk-scan and rank survivors by volume, liquidity, and price momentum using server-side filters.
4. Subscribe to SUBSCRIBE_PRICE, SUBSCRIBE_TXS, and SUBSCRIBE_LARGE_TRADE_TXS for live OHLCV candles, swap flow, and whale alerts on open positions, with GET /defi/v3/ohlcv and POST /defi/multi_price on the REST side.
5. Call GET /defi/v3/token/holder, GET /token/v1/holder-profile, GET /defi/v2/tokens/top_traders, and GET /smart-money/v1/token/list to analyze cap table concentration, holder profiles, and what historically profitable wallets are trading.

The pipeline starts with discovery because everything downstream only consumes what discovery emits; without a fast, filtered stream of candidates, the other four stages have nothing to work on. Before diving in, two conventions apply to every call in this guide: all REST endpoints share the same base URL (https://public-api.birdeye.so), use X-API-KEY for auth, and select the network via the x-chain header. The WebSocket connects at wss://public-api.birdeye.so/socket/solana with the API key passed as a query param. This guide targets Solana, where new token velocity makes the gated pipeline matter most.

Stage 1: Discover New Pools and Listings in Real Time

Interface: WebSocket: SUBSCRIBE_NEW_PAIR, SUBSCRIBE_TOKEN_NEW_LISTING

REST backfill: GET /defi/v2/tokens/new_listing

Docs: New Pair (WSS), New Token Listing (WSS), Token – New Listing

On Solana, new tokens launch every few seconds. Polling a REST endpoint in a loop means you are always late and always paying for requests that return nothing new. Discovery for a Solana trading bot API belongs on the WebSocket, where events are pushed to you the moment they happen on-chain.

Two subscriptions cover it. SUBSCRIBE_NEW_PAIR fires whenever a new liquidity pool is created on a supported DEX, which is your earliest possible signal that a token is tradeable. SUBSCRIBE_TOKEN_NEW_LISTING fires when a token is newly listed and indexed, with optional filters for meme platforms and minimum liquidity so dust gets dropped at the socket level instead of in your own code. One plan note before you build around this: WebSocket access requires a Premium package or higher, so on lower tiers the REST backfill endpoint below becomes your discovery loop instead.

import asyncio, json, websockets

WS_URL = "wss://public-api.birdeye.so/socket/solana?x-api-key=YOUR_API_KEY"

async def discover():
    async with websockets.connect(WS_URL, subprotocols=["echo-protocol"]) as ws:
        await ws.send(json.dumps({"type": "SUBSCRIBE_NEW_PAIR"}))
        await ws.send(json.dumps({
            "type": "SUBSCRIBE_TOKEN_NEW_LISTING",
            "meme_platform_enabled": True,
            "min_liquidity": 1000
        }))
        async for message in ws:
            event = json.loads(message)
            if event.get("type") == "NEW_PAIR_DATA":
                # the tradeable token is the base leg; data.address is the pair itself
                handle_candidate(event["data"]["base"]["address"])
            elif event.get("type") == "TOKEN_NEW_LISTING_DATA":
                handle_candidate(event["data"]["address"])

Two details that are easy to get wrong here. First, the filter parameters (min_liquidity, max_liquidity, meme_platform_enabled, sources) sit at the top level of the subscription message, not inside a data object; SUBSCRIBE_NEW_PAIR accepts the same liquidity bounds. Second, in NEW_PAIR_DATA the new token is data.base.address, while data.address is the pool address. Pushing the wrong one into your queue sends pool addresses through your security gate.

For cold starts and reconnects, backfill from REST instead of replaying the socket (the limit parameter caps at 20 per call, default 10):

curl --request GET \\
  --url '<https://public-api.birdeye.so/defi/v2/tokens/new_listing?limit=20>' \\
  --header 'X-API-KEY: YOUR_API_KEY' \\
  --header 'x-chain: solana' \\
  --header 'accept: application/json'

One architectural note before you wire this up: the output of this stage is nothing more than a stream of candidate addresses pushed into a queue. he discovery consumer in your Solana trading bot API should never act on a token directly, because most of what comes through this stream is about to fail the next gate.

Stage 2: Gate Every Token with Pre-Trade Security Checks

Endpoints: GET /defi/token_security, GET /defi/token_creation_info, GET /defi/token_overview

Chains: token_security covers all supported networks except Sui; token_creation_info currently supports Solana only

Docs: Token – Security, Token – Creation Info, Token – Overview, Security Data Glossary

This is the stage that protects your capital in any Solana trading bot API, and it is where the CU gating logic earns its keep. A new Solana token can look perfectly healthy on a chart while hiding a transfer tax, a mintable supply, or a creator wallet holding most of the float. Three checks, run in sequence, filter the stream down to tokens that are actually safe to touch. Note that token_security and token_creation_info are available from Lite/Starter packages and above; they are not included in the free Standard tier.

Check 1: security profile. GET /defi/token_security returns mint and freeze authority status, transfer fee configuration, metadata mutability, top holder concentration, and creator balances. A minimal rule set for a bot:

Field	Reject when	Why
ownerAddress	not null	Mint authority not renounced, so supply can still be inflated
freezeable	true	Your token account can be frozen mid-trade
mutableMetadata	true	Name and logo can be swapped post-launch
transferFeeEnable	true	Token-2022 transfer fee taxes every buy and sell
top10HolderPercent	> 0.30	Too concentrated to exit safely

One thing to internalize about this response: on Solana there is no literal mintable boolean. Mintability is derived from ownerAddress (null means renounced, no further minting possible), and null generally signals the absence of a risk, so a null transferFeeEnable or freezeable is safe, not missing data. The full field definitions live in the Security Data Glossary linked above.

curl --request GET \\
  --url '<https://public-api.birdeye.so/defi/token_security?address=TOKEN_ADDRESS>' \\
  --header 'X-API-KEY: YOUR_API_KEY' \\
  --header 'x-chain: solana'

Check 2: creator history. GET /defi/token_creation_info returns the creation transaction, timestamp, and the wallet that deployed the token. Cross-referencing the creator address against your own blacklist of serial ruggers is one of the highest ROI checks a bot can run, and it costs a single call.

Check 3: liquidity depth. A token can pass every security check and still be untradeable because there is no real exit. GET /defi/token_overview returns liquidity in USD alongside price, volume, trade counts, and unique wallets, so the gate can enforce a hard liquidity floor:

curl --request GET \\
  --url '<https://public-api.birdeye.so/defi/token_overview?address=TOKEN_ADDRESS&frames=1h,24h>' \\
  --header 'X-API-KEY: YOUR_API_KEY' \\
  --header 'x-chain: solana'

Use the frames parameter here. The gate only needs one or two timeframes, and narrowing frames shrinks the response payload. On the CU side, token_overview is actually the cheapest of the three gate calls (25 CU, versus 40 for token_security and 50 for token_creation_info at the time of writing), so the gate runs the strongest filter first rather than the cheapest. Current prices are listed on the Compute Unit Cost page and are subject to change.

Note for multi-chain builders: Birdeye Data also offers GET /defi/v3/token/exit-liquidity, which estimates how much value can realistically be extracted from a pool. That endpoint currently supports Base only. On Solana, the combination of token_security (holder concentration, LP data) and token_overview (liquidity depth) is the right approach, and this guide uses it throughout.

Tokens that clear all three checks are real, tradeable, and not obviously hostile. Stage 3 decides whether they are worth trading.

Stage 3: Screen Survivors by Momentum

Endpoints: GET /defi/token_trending, GET /defi/v3/token/list

Chains: token_trending covers all supported networks; this guide uses v3/token/list on Solana

Docs: Token – Trending List, Token – List (V3)

Passing the security gate makes a token safe for your Solana trading bot API. It does not make it a good trade. The screening stage ranks candidates by momentum so your Solana trading bot API spends attention where volume and flow actually are.

GET /defi/token_trending gives you the market’s attention in one call: a pre-ranked list sortable by rank, volumeUSD, or liquidity over 1h, 4h, or 24h windows. For a sniper-style bot, interval=1h surfaces breakout tokens far earlier than the 24h board.

curl --request GET \\
  --url '<https://public-api.birdeye.so/defi/token_trending?sort_by=rank&sort_type=asc&interval=1h&limit=50>' \\
  --header 'X-API-KEY: YOUR_API_KEY' \\
  --header 'x-chain: solana'

For systematic scanning, GET /defi/v3/token/list is the workhorse. It returns up to 100 tokens per request and pushes all filter logic to the server: liquidity bounds, market cap and FDV ranges, holder counts, listing age, multi-window volume and volume-change filters, price momentum, and trade counts. Both sort_by and sort_type are required, so a missing sort param returns a 400.

A practical “tradeable small caps with momentum” scan on Solana:

curl --request GET \\
  --url '<https://public-api.birdeye.so/defi/v3/token/list?sort_by=volume_24h_change_percent&sort_type=desc&min_liquidity=50000&min_holder=500&min_volume_24h_usd=100000&min_trade_24h_count=1000&limit=100>' \\
  --header 'X-API-KEY: YOUR_API_KEY' \\
  --header 'x-chain: solana'

The response per item is already dense (price, liquidity, market_cap, fdv, holder, multi-window volume, price change, and trade counts), so your ranking logic can run entirely from one scan without per-token follow-up calls.

Scaling up: if you are on a Business or Enterprise package, GET /defi/v3/token/list/scroll exposes the same filters and sorts but returns up to 5,000 tokens per batch with scroll-based pagination. For full-market scans it cuts the request count by 50x. The funnel logic is identical, so starting on v3/token/list and upgrading to scroll later requires no architectural change beyond pagination handling. For a build that revolves entirely around bulk scanning, see our guide on building a token screener with Birdeye Data.

The output of this stage is a ranked shortlist. When the strategy layer opens a position on one of them, Stage 4 takes over.

Stage 4: Monitor Open Positions with Live Streams

Interface: WebSocket: SUBSCRIBE_PRICE, SUBSCRIBE_TXS, SUBSCRIBE_LARGE_TRADE_TXS

REST: GET /defi/v3/ohlcv, GET /defi/price, POST /defi/multi_price

Docs: Token/Pair OHLCV (WSS), Track Large Transactions (WSS), OHLCV V3, Price – Multiple

The moment your Solana trading bot API opens a position, the data problem changes shape. You no longer care about ten thousand tokens; you care about a handful, with maximum freshness. That workload belongs on the WebSocket.

Three subscriptions cover a live position in your Solana trading bot API:

SUBSCRIBE_PRICE streams live OHLCV candles for a token or pair at intervals from 1 second upward. This drives stop loss, take profit, and trailing logic with zero polling.

SUBSCRIBE_TXS streams every swap on the token as it happens, which is how you detect sudden one-sided flow like a wall of sells from fresh wallets.

SUBSCRIBE_LARGE_TRADE_TXS is the whale alarm. You set a minimum volume and only receive trades above it:

await ws.send(json.dumps({
    "type": "SUBSCRIBE_PRICE",
    "data": {
        "queryType": "simple",
        "chartType": "1m",
        "address": TOKEN_ADDRESS,
        "currency": "usd"
    }
}))

await ws.send(json.dumps({
    "type": "SUBSCRIBE_LARGE_TRADE_TXS",
    "min_volume": 10000   # mandatory; optional max_volume caps the range
}))

Two production gotchas on these subscriptions. For SUBSCRIBE_PRICE, a new subscription message replaces the previous one on the same connection, so to monitor several positions you must resend the full address list every time (use the complex query type, up to 100 addresses per subscription) rather than sending one message per token. For SUBSCRIBE_LARGE_TRADE_TXS, note that min_volume is mandatory and sits at the top level of the message, and the resulting TXS_LARGE_TRADE_DATA events cover all tokens that clear the volume threshold, so your handler must filter by the addresses of your open positions client-side. Each event carries both legs of the swap, the trader address, the pool, and volumeUSD, which is everything the reaction logic needs without a follow-up call.

A single whale dump into thin liquidity can move a microcap 40% in one block. Reacting to the large trade event instead of waiting for the next candle close is often the difference between a controlled exit and a stop loss filled far below its trigger.

REST fills the gaps around the stream. GET /defi/v3/ohlcv backfills candle history so indicators can be computed at startup or after a reconnect. GET /defi/price answers one-off spot price checks. And POST /defi/multi_price keeps portfolio accounting cheap: up to 100 tokens per request, with include_liquidity=true available as a query param. If the PnL side is your main interest, we cover it end to end in our Solana portfolio tracker guide.

curl --request POST \\
  --url '<https://public-api.birdeye.so/defi/multi_price?include_liquidity=true>' \\
  --header 'X-API-KEY: YOUR_API_KEY' \\
  --header 'x-chain: solana' \\
  --header 'content-type: application/json' \\
  --data '{"list_address": "ADDRESS_1,ADDRESS_2,ADDRESS_3"}'

One gotcha worth handling explicitly: unknown or unsupported tokens come back as null on their key in the multi_price response, not as an error. If your PnL loop does not guard against this, a single delisted token will crash the whole refresh tick.

Streams and prices tell you what is happening to your position. The last stage tells you who is behind it.

Stage 5: Profile Holders and Track Smart Money

Endpoints: GET /defi/v3/token/holder, GET /token/v1/holder-profile, GET /defi/v2/tokens/top_traders, GET /smart-money/v1/token/list

Chains: holder-profile and the Smart Money list are Solana only; PnL-based sorting on top_traders is also Solana only

Docs: Token – Holder (V3), Token – Holder Profile, Token – Top Traders, Smart Money – Token List

The final stage of your Solana trading bot API answers a question charts cannot: who actually owns this token, and are the wallets that matter buying or selling?

GET /defi/v3/token/holder returns the holder list with each wallet’s balance. That is enough to compute cap table concentration: how much of the supply sits in the top 10 or top 50 wallets, and how that distribution shifts while you hold a position. A token whose top holders are quietly shrinking their balances while price grinds up is telling you something the candle chart will not.

For a richer view on top of raw balances, GET /token/v1/holder-profile (Solana only, available from Starter packages and above, with the token passed as token_address) returns a holder profile summary alongside the token’s market data: holder counts, total holdings as a share of supply, and aggregated top 10 holder stats in a single call. It pairs naturally with the holder list: use v3/token/holder for the full cap table, then holder-profile for the summarized view your dashboard or alerting logic reads on each tick.

GET /defi/v2/tokens/top_traders shows the wallets with the highest trading activity on the token over a chosen window. It sorts by volume_usd as well as PnL fields (total_pnl, unrealized_pnl, realized_pnl), with timeframes from 2 days to 90 days on Solana. Tracking whether those specific wallets are net buyers or net sellers is a far stronger signal than aggregate volume alone.

GET /smart-money/v1/token/list flips the direction of the question. Instead of asking “who trades this token,” it asks “what are historically profitable wallets trading right now,” returning tokens ranked by Smart Money activity. It is available from Starter packages and above, Solana only. Valid sort_by values are net_flow, smart_traders_no (the default), and market_cap; interval accepts 1d, 7d, or 30d; and trader_style segments the smart money cohort into risk_averse, risk_balancers, and trenchers, so a memecoin bot and a majors bot can follow entirely different wallet populations. Page size caps at 20.

curl --request GET \\
  --url '<https://public-api.birdeye.so/smart-money/v1/token/list?sort_by=net_flow&sort_type=desc&interval=1d&trader_style=all>' \\
  --header 'X-API-KEY: YOUR_API_KEY' \\
  --header 'x-chain: solana'

Feeding this list back into Stage 3 as an additional screening signal closes the loop: the bot is no longer just following volume, it is following the wallets that have repeatedly been right.

Profiling is the slowest-cadence stage in the pipeline. Holder distributions do not change second to second, so running it on open positions every few minutes (rather than on every screened token) keeps its CU footprint small relative to its signal value.

With all five stages running, one piece remains: visibility into what the whole pipeline actually costs.

Utility: Monitor Your CU Budget Programmatically

Endpoint: GET /utils/v1/credits

Docs: Utils – Credits Usage

A five-stage Solana trading bot API pipeline has five different consumption profiles, and without visibility you will not know which one is burning budget. Wire this endpoint into your monitoring from day one.

curl --request GET \\
  --url '<https://public-api.birdeye.so/utils/v1/credits>' \\
  --header 'X-API-KEY: YOUR_API_KEY'

With no parameters it returns the current billing cycle: total usage broken down into REST api and WebSocket ws, remaining credits, and overage fields. The REST/WS split is particularly useful for a bot, since Stages 1 and 4 live on the socket while Stages 2, 3, and 5 live on REST.

A practical pattern: poll hourly and alert below a safe threshold. When credits run low, degrade in priority order. Slow down Stage 3 scanning first, stretch Stage 5 profiling cadence second, and leave Stage 4 position monitoring untouched until last. Your screening can wait an extra minute; your stop loss cannot.

Here is how the five stages of the Solana trading bot API pipeline and the budget loop connect into a single deployable architecture.

Putting It Together: Reference Architecture

The WebSocket consumer pushes candidates into a queue and never trades directly. A gate worker drains the queue and discards most of it. A screening cron ranks survivors and feeds the strategy. Each open position gets its own monitoring subscriptions, with multi_price batching the portfolio PnL tick. Profiling enriches open positions on a slow cadence, and the credits endpoint watches everything.

Code review checklist before you ship your Solana trading bot API:

• Discovery only writes to the queue; no trades fire from the socket consumer.
• Every candidate passes token_security and a liquidity floor before any screening or entry logic sees it.
• Screening uses server-side filters on v3/token/list; no client-side filtering of bulk downloads.
• Stop loss and whale reaction logic run off the WebSocket, never off a REST polling loop.
• null responses from multi_price are handled explicitly, not assumed away.
• Credit usage is observable, with a defined degradation order that protects position monitoring.

FAQ

What package do I need to run this pipeline?

For a Solana trading bot API, the WebSocket stages (Discover and Monitor) require a Premium package or higher; on lower tiers, replace them with REST polling of new_listing and multi_price at a slower cadence. The REST gate and screening stages run from Lite/Starter and above (token_security and token_creation_info are not in the free Standard tier), and the scroll variant of token list requires Business or Enterprise. The full matrix is on the Data Accessibility by Packages page.

Can I use the exit-liquidity endpoint for Solana tokens?

Not yet. GET /defi/v3/token/exit-liquidity currently supports Base only. On Solana, approximate the same judgment by combining token_security (top holder concentration, LP information) with token_overview (liquidity in USD), and enforce a hard liquidity floor in your gate before entry.

Do I need the scroll endpoint for the screening stage?

No. GET /defi/v3/token/list exposes the full filter and sort parameter set at up to 100 tokens per call, which covers most bots. The scroll variant (/defi/v3/token/list/scroll, up to 5,000 tokens per batch) is available on Business and Enterprise packages and matters mainly for full-market scans. The filters are identical, so upgrading later does not change your funnel logic.

What does the holder endpoint actually tell me?

GET /defi/v3/token/holder returns the holder list and how much each wallet currently holds, which is what you need for cap table concentration math. For a summarized holder view beyond the raw list, pair it with GET /token/v1/holder-profile (Solana only, Starter packages and above).

Why run discovery on WebSocket instead of polling the new listing endpoint?

Latency and cost. New Solana tokens launch every few seconds, so a polling loop is either too slow to be competitive or too frequent to be affordable. The WebSocket pushes NEW_PAIR and TOKEN_NEW_LISTING events the moment they occur, and the REST endpoint is reserved for backfill after restarts or reconnects.

How fresh are the streamed OHLCV candles?

SUBSCRIBE_PRICE supports intervals from 1 second upward, streamed as trades happen. For indicator warm-up at startup, backfill history with GET /defi/v3/ohlcv and then switch to the stream, so your indicators never run on stale polled data.

How do I keep CU consumption under control as the bot scales?

Gate aggressively and degrade in order. This is the core discipline of CU management for any Solana trading bot API. The pipeline is designed so the cheap stages (discovery, security gate) reject most tokens before the expensive ones (overview enrichment, profiling) ever run. Monitor with GET /utils/v1/credits, and when budget runs low, slow screening and profiling first while keeping live position monitoring untouched.

---

Explore the full endpoint catalog in the Birdeye Data API reference or compare data packages at birdeye.so/data-api.