If you’ve used other Solana data APIs, you probably ask for OHLCV by token mint. Dexploit doesn’t work that way, and here’s why.Documentation Index
Fetch the complete documentation index at: https://docs.dexploit.dev/llms.txt
Use this file to discover all available pages before exploring further.
One token, many pools
A token like BONK trades on multiple DEX pools simultaneously. Each pool has its own liquidity, price, and volume. Asking “what’s the price of BONK?” is ambiguous — it depends which pool. For example, BONK trades across pools like these (real shape — fetch the latest from/api/v1/pairs?token_address=DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263):
| pair_address | protocol | recent_volume_sol |
|---|---|---|
<pumpswap_pool_address> | pumpswap | 1234.56 |
<raydium_pool_address> | raydium | 987.65 |
<meteora_pool_address> | meteora | 543.21 |
What pair_address actually is
pair_address is the on-chain address of the pool / LP account. Every swap that happens against that pool is captured under that address. When you ask Dexploit for OHLCV or swap history, you’re asking about activity in that specific pool.
Discovery: find pairs for a token
UseGET /api/v1/pairs?token_address=... to list every pool we index for a given token, sorted by recent volume.
pair_address to the OHLCV / swap endpoints.
What happens if you send mint or pair
The API rejects it with a clear pointer:
When mint is the right input
A few endpoints intentionally take a token mint, because they aggregate across all pools:
GET /swaps/token/{mint}— every swap of a token, across pools.GET /stats/token/{mint}— aggregate token stats.
pair_address.
