Skip to main content

​
Why this matters

When you build code that interpolates user input into API paths, the smallest case mismatch returns a 404 with no helpful explanation. The fix is one line, but you have to know about it. This page documents which identifiers are case-sensitive, what the canonical form looks like, and what happens at the wire level if you get it wrong.

​
Network IDs

Canonical form: lowercase, underscore-separated. Examples: ethereum, solana, base, arbitrum, bsc, polygon, optimism. What the REST API does with non-canonical input:
ETH returns 404. Ethereum, eth, Solana all return 404. Network IDs are strict lowercase canonical at the REST layer. What the MCP layer does with non-canonical input: The DexPaprika MCP normalizes common synonyms (eth → ethereum, sol → solana, arb → arbitrum, etc.) before calling the REST API. If you are calling the API through the MCP, mixed case and common abbreviations work. If you are calling REST directly, you need to canonicalize yourself. Recommended pattern: always call GET /networks once at startup and cache the id values. Treat any user-supplied network name as untrusted and map it through your cached list before constructing the URL.
Returns the authoritative list of canonical IDs.

​
Token and pool addresses

EVM chains (Ethereum, BSC, Base, Arbitrum, Polygon, Optimism, Avalanche, and similar): lowercase hex, 0x prefix, 40 hex characters.
The API normalizes checksum addresses internally, so both spellings work for input. The response always uses lowercase. If your code does string comparison between an address from the API and an address from another source (e.g., a wallet, a block explorer, a contract event), lowercase both sides before comparing. Solana: base58-encoded, case-sensitive. There is no concept of “lowercase Solana address.” Pass it through exactly as you received it.
Sui, Aptos: 0x-prefixed hex, similar to EVM. Lowercase canonical. TON: friendly format (base64url) is case-sensitive. Raw format is hex. Use whichever the explorer shows.

​
DEX identifiers

Canonical form: lowercase, underscore-separated.
DEX IDs are returned by GET /networks/{network}/dexes and passed to the dex_name filter on GET /networks/{network}/pools/search. The old GET /networks/{network}/dexes/{dex}/pools path took the id as a path segment; it was removed and returns 410 Gone. dex_name is the one identifier that is not case-strict. It resolves the id case-insensitively, so dex_name=curve, dex_name=Curve and dex_name=CURVE all return the same rows. It resolves only the id. The DEX list returns dex_id and dex_name on every row, and despite the matching parameter name it is dex_id you pass. Feeding it the dex_name field, a display name like Uniswap V3, returns HTTP 200 with an empty results array rather than an error. The dex_id form is also what the removed path segment held, so it is the value already sitting in most existing code. One catch: some commit messages and changelog entries refer to DEXes by their on-chain name (e.g., “CronosV3”), but the public API slug is different (e.g., vvs_v3 on Cronos). Always use the slug returned by the API, never the marketing name.

​
Quick reference

If you get a 404 and the path looks right at a glance, the first thing to check is case on the network ID and DEX ID. The second thing to check is whether you accidentally URL-encoded part of the path. For other 404 causes, see Error handling.