How to Build a Token Investigation Dashboard: 8 Smart Checks

A token investigation dashboard pulls everything you need to judge one Solana token into a single screen, so you stop opening six explorer tabs every time a new ticker lands in your feed. You paste one token address, and the dashboard answers the questions that matter before you trade: how big and liquid is it, who holds it, which behavior tags dominate the float, who trades it, how much fee flow it throws off, and whether its supply can still be tampered with. This guide wires eight Birdeye Data endpoints into that one screen. Every call runs over REST, because a dashboard reads on demand when you open a token rather than streaming a feed you never watch.

The token is the unit of investigation here, not the wallet and not the market. One address goes in, eight answers come back. That keeps the query pattern flat: one token address, one x-chain header set to solana, and a small set of endpoints that each answer one question.

Direct Answer: token investigation dashboard in 8 steps

You can stand up a working token investigation dashboard with eight Birdeye Data calls, one per panel. Read these eight steps as a self contained recipe.

1. Market snapshot. Call GET /defi/token_overview for price, liquidity, market cap, supply, and 24 hour volume in one response.
2. Price chart. Call GET /defi/v3/ohlcv for the candle series that drives your chart.
3. Ownership concentration. Call GET /holder/v1/distribution for each wallet’s share of supply.
4. Behavior tags. Call GET /token/v1/holder-profile for the bundler, sniper, insider, dev, and smart trader breakdown.
5. Top traders. Call GET /defi/v2/tokens/top_traders to rank the wallets moving the most volume.
6. Fee flow. Call GET /defi/v3/token/fee/single to see how much fee the token generates and where it goes.
7. Supply authority. Call GET /defi/token_security to read mint authority, freeze authority, and metadata mutability.
8. Mint and burn history. Call GET /defi/v3/token/mint-burn-txs for the supply event log.

Each step below expands one panel with the exact parameters, a curl example, and the mistake that costs you an hour.

Start your token investigation dashboard with 1 market call

Start with the panel that gives instant context on size and traction, because every later judgment leans on it. A behavior tag means one thing on a token with 30 million dollars of liquidity and something very different on a token with 3 thousand. Market context comes first so the numbers underneath have a frame.

Endpoint: GET /defi/token_overview

Chains: all

Plan availability: Standard and above

Docs: token overview

One call returns almost the entire top panel, which keeps your credit spend low and your render logic flat. The response carries price in United States dollars, liquidity in dollars, marketCap, fdv, circulatingSupply, v24hUSD for 24 hour volume, and holder for the raw holder count. It also returns price change across 10 windows, from 1 minute to 24 hours, so you can render a momentum row without a second call.

Parameter	Where	Notes
address	query	The token address. This path uses address.
x-chain	header	Defaults to solana.

Only one thing here goes wrong often, and it is the parameter name. This path follows the address convention, so reach for token_address and the call fails.

curl --request GET \
  --url '<https://public-api.birdeye.so/defi/token_overview?address=YOUR_TOKEN>' \
  --header 'x-api-key: YOUR_API_KEY' \
  --header 'x-chain: solana'

Watch the casing, because it is mixed inside one response. Most fields are camelCase, such as marketCap and v24hUSD, but two are snake_case: holder and global_fees_paid. If you map the response assuming camelCase throughout, those two read as undefined and your panel shows blanks. Copy each field name exactly as the response spells it.

Price, liquidity, and supply give you the token’s size. A chart gives you its trajectory, and that is one more call.

Chart price action with 5,000 candles

A price of 0.004 dollars means nothing until you see whether it was 0.001 yesterday or 0.04. This panel feeds your price chart with OHLCV (open, high, low, close, volume) candles so the number has a shape behind it.

Endpoint: GET /defi/v3/ohlcv

Chains: Solana and major chains

Plan availability: Standard and above

Docs: OHLCV V3

Each item in the response carries o, h, l, c, v, v_usd, and unix_time, and one call returns up to 5,000 candles. Set type to pick the interval, from 1 second up to 1 month.

Parameter	Where	Notes
address	query	The token address.
type	query	Interval, such as 15m or 1H. Required.
time_from	query	Window start, Unix seconds. Required.
time_to	query	Window end, Unix seconds. Required.

The three required fields here are type, time_from, and time_to. If you request candles without a window, the call fails, because the endpoint has no default range. Pass all three every time.

curl --request GET \
  --url '<https://public-api.birdeye.so/defi/v3/ohlcv?address=YOUR_TOKEN&type=1H&time_from=1726670000&time_to=1726700000>' \
  --header 'x-api-key: YOUR_API_KEY' \
  --header 'x-chain: solana'

Size and trajectory are the public face of a token. Underneath sits the holder list, and that is where a real project starts to look different from a wallet wearing a costume.

Map ownership concentration

A token where two wallets hold 60 percent of supply is one bad decision away from a dump, and nothing in the price or volume figures will warn you about it. Ownership is where that risk becomes visible, so this panel maps how tightly the float is held.

Endpoint: GET /holder/v1/distribution

Chains: Solana

Plan availability: Standard and above

Docs: holder distribution

Each wallet comes back with its percent_of_supply already calculated, alongside a summary aggregate. Because the percent is precomputed, the concentration table needs no division on your side.

Parameter	Where	Notes
token_address	query	This path uses token_address.
mode	query	top returns top_n holders. percent filters a supply band. Defaults to top.
include_list	query	Defaults to true, so the wallet list is returned.
limit	query	Max 50 per page.

Leave mode alone and you get what a concentration table wants: it defaults to top, which returns holders ranked by supply share. Just note that limit caps at 50, so design the table around a top 50 view and paginate with offset when you need to go deeper.

curl --request GET \
  --url '<https://public-api.birdeye.so/holder/v1/distribution?token_address=YOUR_TOKEN&mode=top&top_n=20&include_list=true>' \
  --header 'x-api-key: YOUR_API_KEY' \
  --header 'x-chain: solana'

What the concentration table cannot answer is what kind of wallets those top holders are. Twenty wallets splitting the float evenly looks healthy right up until you learn they all bundled in on the same block. The next panel puts a label on each one.

Flag 5 behavior tags on the float

A wallet holding 10 percent of supply reads very differently depending on who that wallet is. A bundler sitting on half the float is a warning. A dev wallet that already sold is another kind of signal. This panel labels the holders.

Endpoint: GET /token/v1/holder-profile

Chains: Solana

Plan availability: all plans

Docs: holder profile

This is the panel that gives a token investigation dashboard its edge over a block explorer. The response groups holders into five tags, bundler, sniper, insider, dev, and smart trader. Each tag entry carries holder_count, percent_of_supply, buy and sell volume, avg_buy_price, and pnl. That is enough for a compact table showing who holds what and whether they are sitting on a profit.

Parameter	Where	Notes
token_address	query	This path uses token_address.
include_zero_balance	query	Defaults to true, which counts wallets that traded but no longer hold.
x-chain	header	Solana only for this endpoint.

Set include_zero_balance to false when you want tags weighted by current holders only, since the default counts wallets that traded the token and have since exited. The parameter that breaks calls is token_address, because /token/v1/holder-profile follows the token_address convention while the overview call three panels up used address. Mixing them up is the most common reason this call returns nothing.

curl --request GET \
  --url '<https://public-api.birdeye.so/token/v1/holder-profile?token_address=YOUR_TOKEN>' \
  --header 'x-api-key: YOUR_API_KEY' \
  --header 'x-chain: solana'

One timing note belongs in your panel copy. The bundler tag is accurate for tokens created from 1 March 2026 onward, because older tokens are still backfilling. Show the tag with a small dated qualifier on legacy tokens so you do not over trust it.

Holders and traders overlap less than you would expect. A wallet can sit on 5 percent of supply and never trade, while another cycles millions through the token without holding any of it overnight. The next panel covers the second group.

Validate the top 10 traders

Holding and trading are separate behaviors, so a clean holder distribution can sit on a dead token, and a concentrated float can still trade with genuine volume. This panel ranks the wallets actually doing the trading.

Endpoint: GET /defi/v2/tokens/top_traders

Chains: all

Plan availability: Standard and above

Docs: top traders

The response ranks wallets over a window you choose, and each item carries a per wallet tags array using the same vocabulary as the ownership panel. That crossover, a top trader that is also a bundler, is often the most revealing cell in the whole dashboard.

Parameter	Where	Notes
address	query	This /defi/v2/ path uses address.
time_frame	query	30m through 90d, default 24h.
sort_by	query	volume, trade, total_pnl, unrealized_pnl, realized_pnl, or volume_usd.
sort_type	query	desc or asc.
limit	query	Max 10.

The limit caps at 10, so build the panel around a top ten list rather than a long scroll. The parameter that actually breaks calls is sort_by, which takes exact values: pass sort_by=pnl and the request is rejected, because the valid profit fields are total_pnl, realized_pnl, and unrealized_pnl, never a bare pnl.

curl --request GET \
  --url '<https://public-api.birdeye.so/defi/v2/tokens/top_traders?address=YOUR_TOKEN&time_frame=24h&sort_by=volume&sort_type=desc&limit=10>' \
  --header 'x-api-key: YOUR_API_KEY' \
  --header 'x-chain: solana'

Watch the casing on the volume fields, because it shifts inside one object. The total is volumeUsd, but the buy and sell splits are volumeBuyUSD and volumeSellUSD. The suffix changes from Usd to USD between sibling fields, so map each one explicitly.

Ranking the traders shows you who moves the token. Whether that movement is worth anything is a separate question, and fees answer it.

Trace fee flow by venue

Every swap on the token leaves a paper trail of fees paid to whoever routed it, which is harder to hollow out than a volume figure. Breaking those fees down by venue tells you where the token actually trades and how much real value moves through it.

Endpoint: GET /defi/v3/token/fee/single

Chains: Solana

Plan availability: Starter and above

Docs: token fee

The response buckets fees by timeframe, then splits each bucket by fee type, network, priority, tips, and trading platform, and by provider such as axiom, photon, jito, and gmgn. That is far richer than the single global_fees_paid figure the overview call returns.

Parameter	Where	Notes
address	query	The token address.
interval	query	Up to 3 of alltime, 24h, 8h, 4h, 2h, 1h, 30m, 15m, 5m, 1m.
x-chain	header	Solana.

Ask for at most 3 timeframes in interval, since that is the ceiling per call, and request only the ones your panel renders. The stranger detail sits in the details block, where one field reads trading_platform_fee_amout_stablecoins, missing a letter in the word amount. Read it by that exact key, or the lookup returns nothing and your stablecoin fee row quietly shows zero.

curl --request GET \
  --url '<https://public-api.birdeye.so/defi/v3/token/fee/single?address=YOUR_TOKEN&interval=24h,alltime>' \
  --header 'x-api-key: YOUR_API_KEY' \
  --header 'x-chain: solana'

The first five panels describe the token as it trades today. The last two step back from behavior to structure, and ask whether the token can still be changed at the supply level.

Check supply authority

Everything so far describes the token as it is. None of it rules out a live mint authority that can print fresh supply tomorrow, or a freeze authority that can lock holders out of their own balances. This panel surfaces those levers.

Endpoint: GET /defi/token_security

Chains: all except Sui

Plan availability: all plans

Docs: token security

The response returns the authority and supply structure of the token, including freezeAuthority, mutableMetadata, top10HolderPercent, isToken2022, and jupStrictList.

Parameter	Where	Notes
address	query	The token address.
x-chain	header	Selects the schema. Solana and EVM return different fields.

On Solana there is a detail that trips up every first pass: the response has no mintable boolean. You read the mint authority from ownerAddress. When ownerAddress is null, the mint authority has been renounced and no new supply can be minted. When it holds an address, that authority is still live. The field is named ownerAddress, not mintAuthority, so do not look for the latter, because the response does not carry it.

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

Authority covers what could still happen to supply. For what already happened, you need the event log, which is the final panel.

Audit mint and burn history

A renounced mint authority next to a clean burn history reads very differently from a live authority next to a recent stealth mint. This panel closes the loop with the supply event log.

Endpoint: GET /defi/v3/token/mint-burn-txs

Chains: Solana

Plan availability: Standard and above

Docs: mint and burn transactions

Each item carries common_type set to mint or burn, a ui_amount, a block_time, and a tx_hash, which is enough to render a supply event timeline.

Parameter	Where	Notes
address	query	The token address.
sort_by	query	Required. Use block_time.
sort_type	query	Required. desc or asc.
type	query	Required. all, mint, or burn.
limit	query	Max 100.

Three parameters travel together here, and leaving out any one of them fails validation, because the endpoint has no default sort to fall back on. Send sort_by, sort_type, and type on every call, even when the values never change.

curl --request GET \
  --url '<https://public-api.birdeye.so/defi/v3/token/mint-burn-txs?address=YOUR_TOKEN&sort_by=block_time&sort_type=desc&type=all&limit=100>' \
  --header 'x-api-key: YOUR_API_KEY' \
  --header 'x-chain: solana'

Read the two integrity panels together. The dashboard does not pass a verdict for you, and it should not. It lays the structural facts next to the behavior facts so you decide.

Track credit usage

Every panel above spends compute units, and a token investigation dashboard that fills eight panels on each token open can burn through a budget faster than you expect. Call GET /utils/v1/credits to read your remaining allowance, and render it somewhere visible while you develop, so a runaway loop shows up as a falling number rather than a surprise suspension.

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

Putting it together: reference architecture

The eight panels share one input, the token address, and run independently, so you can fire all eight calls in parallel and render each panel as its response lands. Nothing downstream waits on anything upstream, so a slow fee call never blocks your market panel.

Before you ship, walk this checklist:

• Market panel reads holder and global_fees_paid as snake_case, everything else as camelCase.
• Ownership panel calls distribution with mode=top and holder-profile with token_address.
• Bundler tags carry a dated qualifier for tokens created before 1 March 2026.
• Traders panel sorts by an exact sort_by value and maps volumeUsd against volumeBuyUSD.
• Fee panel reads the misspelled trading_platform_fee_amout_stablecoins key verbatim and sends at most 3 intervals.
• Integrity panel reads the mint authority from ownerAddress and sends all three required parameters to mint-burn-txs.
• The x-chain header is solana on every call, since five of these endpoints are Solana only.

For deeper background on why a null mint authority matters, the Solana documentation on the SPL token program explains how mint and freeze authorities work at the protocol level.

FAQ

What is a token investigation dashboard?

It is a single screen that pulls the market, ownership, trading, and supply facts for one token from an API, so you can judge the token without opening several explorers by hand. This guide builds one on Solana with eight Birdeye Data endpoints.

Do you need a paid plan to build this?

Every endpoint in this guide is available across the Birdeye Data packages, so plan choice comes down to volume rather than access. A dashboard that fills eight panels per token open spends eight calls each time, so size your package around how many tokens you expect to investigate per day.

Why is the token investigation dashboard Solana only?

Five of the endpoints, holder distribution, holder profile, token fee, and mint and burn history, return data for Solana only. The market, chart, and top trader panels work across chains, so you can extend part of the dashboard to EVM tokens, but the ownership, fee, and supply panels stay Solana bound.

How do you read mintability without a mintable field?

On Solana the security response has no mintable boolean. You read it from ownerAddress. A null value means the mint authority is renounced and supply is fixed. An address means the authority is live and more supply can be minted.

Can you run all the calls at once?

Yes. The eight panels share only the token address as input and do not depend on each other, so you can fire the calls in parallel and render each panel as its response arrives.

Ready to build your own token investigation dashboard? Grab an API key and compare plans at Birdeye Data, and browse the full endpoint reference at docs.birdeye.so/reference.