Skip to main content

​
Overview

This page covers the most common sequences of API calls for typical tasks. Each pattern shows the exact endpoints, parameters, and response fields you need. Base URL: https://api.dexpaprika.com

​
Pattern 1: Get a token’s price

When you know the network and token address:
The price is at response.summary.price_usd. When you only know the token name or symbol:
  1. Search first:
  1. From the tokens array in the response, find the matching token. Note the chain and id (address) fields.
  2. Call the token endpoint:

​
Pattern 2: Compare prices of multiple tokens

Use batch pricing when you need prices for 2–10 tokens on the same network:
Response is an array of {id, chain, price_usd} objects. Order is not guaranteed. Tokens without pricing data are silently omitted (not an error). Limits: Max 10 tokens per request. More than 10 returns HTTP 400. Zero tokens also returns HTTP 400. For tokens across different networks, make separate requests per network.

​
Pattern 3: Find top pools on a network

Sorting options for order_by: volume_usd_24h, volume_usd_7d, volume_usd_30d, liquidity_usd, txns_24h, created_at, price_usd, price_change_percentage_24h Pagination: Cursor-based. Read has_next_page and next_cursor, then pass next_cursor back as cursor. The response wraps rows in a results array (not pools).

​
Pattern 4: Find pools for a specific token

This returns pools on that network containing the token, sorted by volume. The highest-volume pool is typically the best source for price data and OHLCV history. Network-scoped only: The token_address filter works on GET /networks/{network}/pools/search. The cross-network GET /pools/search accepts the parameter but silently ignores it. One token per query; repeating token_address does not act as a pair filter, and the API uses only one of the values (not guaranteed by order). An unknown address returns HTTP 200 with an empty results array.
The old GET /networks/{network}/tokens/{token_address}/pools endpoint was removed and returns 410 Gone. Its reorder and second-token address parameters have no equivalent on pool search.

​
Pattern 5: Get historical price data (OHLCV)

OHLCV data is per pool, not per token. The workflow is:
  1. Find the best pool — the highest-volume pool for the token:
  1. Get OHLCV data for that pool:
Intervals: 1m, 5m, 10m, 15m, 30m, 1h, 6h, 12h, 24h start is required — ISO 8601 date or UNIX timestamp. Optional end parameter (max 1 year from start). Max 366 data points per request. Response is a JSON array of candlestick objects with time_open, time_close, open, high, low, close, volume. Use inversed=true to flip the pair (e.g., get ETH/USDC instead of USDC/ETH).

​
Pattern 6: Filter pools by criteria

Use the pool search endpoint to find pools matching specific conditions:
Available filter parameters: All filters combine with AND logic. The response wraps rows in a results array (not pools) and pages with has_next_page + next_cursor (cursor-based; there is no page_info/total_pages).
Use the canonical volume_usd_* parameter names (e.g. volume_usd_7d_min, volume_usd_30d_max). The volume, liquidity, and transaction filters are all functional. Older short names like volume_7d_min are silently ignored.

​
Pattern 7: Monitor pool transactions

Transactions are returned in reverse chronological order. Each includes:
  • amount_0, amount_1 — token amounts
  • volume_0, volume_1 — volumes
  • price_0_usd, price_1_usd — USD prices for each token
  • token_0_symbol, token_1_symbol — token symbols
  • type — swap, add, or remove
  • created_at — timestamp
Pagination: Max 100 pages. For deep history, use cursor parameter (a transaction ID) instead of page numbers.

​
Pattern 8: Discover DEXes on a network

​
Pattern 9: Stream live prices

For real-time updates, use the streaming API instead of polling REST. Single token (GET):
Multiple tokens (POST) — up to 25 per connection:
Each SSE event:
The price field is a string (not a number) — parse it as a decimal for precision. Open additional connections in parallel if you need more than 25 subscriptions, up to 10 concurrent SSE streams per IP.

​
Pattern 10: REST + Streaming combined

The most common production pattern:
  1. REST for discovery — use search, token details, and pool listing to find what you want to track
  2. Validate — confirm the tokens exist and have pricing data via REST
  3. Stream for live updates — open an SSE connection for real-time prices
  4. REST for enrichment — periodically call REST for OHLCV history, pool details, or transaction data that streaming doesn’t cover

​
Quick reference: which endpoint for what?

​
FAQs

If all requested tokens are unknown or don’t have pricing data, you get HTTP 200 with an empty array — not an error. Verify the token addresses are correct.
GET /networks/{network}/pools, /pools, and /networks/{network}/pools/filter were removed (they return 410 Gone). Use GET /networks/{network}/pools/search (single network) or GET /pools/search (multiple networks via a chains filter). The search response wraps rows in a results array; each pool uses id (the pool address), volume_usd_24h, and transactions_24h. Pagination is cursor-based (has_next_page + next_cursor).
Use the highest-volume pool — it has the most representative pricing. Find it via GET /networks/{network}/pools/search?token_address={address}&limit=1 (the default sort is volume_usd_24h descending).
GET /networks/{network}/tokens/{token_address}/pools was removed (it returns 410 Gone). Use GET /networks/{network}/pools/search with the token_address query parameter. The filter is network-scoped only: the cross-network GET /pools/search accepts token_address but silently ignores it. The old reorder and second-token address parameters have no equivalent.