Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.codex.io/llms.txt

Use this file to discover all available pages before exploring further.

Unable to find the answers you’re looking for? Try asking our integrated AI assistant next to the searchbar at the top of the page, or reach out to us on Discord.
This FAQ covers cross-cutting questions about Codex. For endpoint-specific questions, check the GraphQL Reference. For error messages and debugging, see Troubleshooting.

​
Getting Started

Everything you need to get started can be found in our “Get Started” page. If you need further help, refer to this FAQ or reach out to us on Discord.
Yes, our explorer is a very powerful tool for testing Codex endpoints. It has been updated to allow multiple tabs and will save your progress when closed for future referencing.
We suggest downloading the Chrome GraphQL Network Inspector and then inspecting the queries used on Defined.fi as you navigate through the different sections of the site to find out what’s possible with the Codex API.
Codex supports over 75+ Million tokens across 80+ Networks and growing by the day. To see if we support a network you are interested in, you can browse our Supported Networks page, use the network filters at Defined.fi, or query getNetworks from our API using a free or paid API key at explorer.codex.io.

​
Pricing & Billing

Websocket requests are billed per message sent by the websocket, but we offer custom plans with discounts for high usage (10m+/month). Contact us on Discord or via Email for information on custom plans.
Overages are charged at the same per-million rate as your subscribed plan. For example, if you exceed your 1M Growth plan limit by 500K requests, you’ll be charged for an additional 1M requests at the same per-million rate. See Rate Limits & Connection Limits for full details.

​
Data Coverage & Methodology

Codex doesn’t expose a single “verified” or “spam” label, but several fields together cover this. Detection is automated, based on transaction flow patterns and the wallets interacting with each token. Defined.fi users can also flag tokens on the frontend (moderated daily), and confirmed flags are reflected in the isScam response field.Reading verification status (response fields):
  • isScam (boolean) — isScam: false is Codex’s equivalent of a token being “verified.” Includes both algorithmic detection and confirmed user flags from Defined.fi. There is no separate isVerified response field.
  • potentialScam (boolean) — automated flag based on transaction flow patterns and the wallets interacting with the token.
  • potentialScamReason — surfaces why a token was flagged when potentialScam is true.
These fields are available on token, tokens, filterTokens (via the nested token object), and pairMetadata (via enhancedToken0 / enhancedToken1).Filtering on filterTokens (input fields):
  • isVerified: true — only return verified tokens (excludes anything flagged as a scam). Note: this is a filter input only, not a response field.
  • potentialScam: true — return only tokens flagged as potential scams (useful for inspection).
  • potentialScam: false — explicitly exclude flagged tokens (matches default behavior).
  • includeScams: true — include scam-flagged tokens in your results.
By default filterTokens already excludes potential scam tokens, so a standard query gives clean results without extra config. Detection isn’t perfect, but it cuts exposure significantly.Recommended for trending pages: Combine potentialScam: false with trendingIgnored: false to also exclude uninteresting tokens like stablecoins, network base tokens, and known rugs.
Pricing comes down to finding the most liquid route through pools to a bucket of stablecoins. For example, getTokenPrices uses an aggregate value across all pairs based on liquidity and volume. We give each pair a weight and then use that to build a confidence score.
We index over 75+ Million tokens across 80+ networks, so there’s going to be a lot of unusable data mixed in. The best way to avoid this is by using filters with minimum (or maximum) values. For example, it will be higher quality data if you filter by tokens with at least 10 buys in the past 24hours, or specific amounts of volume, liquidity, trendingScore, etc.
Our Solana data begins on March 20th, 2024. Unfortunately, it is not feasible to backfill data prior to this date.
Our chart data does not explicitly display the exchange source, but you can retrieve this information using the filterTokens query and selecting the first result.

Keep in mind that exchanges are added manually. While we strive to keep our listings up to date, we index over 20,000 exhanges, so not all may be included. If you need specific exchange metadata added, feel free to reach out to our team.
There aren’t that many transactions that are dropped, but we will have multiple streams available (processed and confirmed) and you could dedupe on your end. The difference will be about 1.2s between the two.
Not currently a built-in field, but it’s been a popular request so we may add it in the future. For now you can find it yourself by requesting all the daily getBars for a token and finding the highest value, though it’s not a very efficient method.
Yes. Instead of getBars, you can now use getTokenBars for aggregated charts across all valid pairs.
We fetch data on the first trade. For social links and token images, we pull from 10+ sources to compile the most comprehensive metadata we can — some on-chain and some off-chain. We also allow user-proposed updates on Defined.fi via a moderated proposal system.

For established Web3 projects, additional verified metadata is enriched by The Grid. See Verified Metadata for details on the asset, assetDeployments, and organization fields available on filterTokens, token, and tokens.
If circulating supply exceeds total supply, we fall back to total supply to avoid inaccuracies. You can manually adjust this using: circulatingSupply * price
Unfortunately we do not have historical supply information. All responses will return current supply amounts.
Launchpads that utilize bonding curves, like pump.fun, have structured token progression from 0-100% before “graduating.” Some launchpad protocols like Zora, Base, and Clanker do not implement bonding curves, and lack the distinct graduation phases. Tokens on protocols without bonding curves will simply be ‘New’, without going through the further phases of completing, completed, or migrating. In these cases the associated attributes like migrated/completed, migratedAt/completedAt, migratedSlot, and graduationPercent will be absent. See Supported Launchpads for the full list of supported launchpads and which use bonding curves.
You can subscribe to the circulatingSupply through onPairMetadataUpdated (within enhancedToken) or just check on each page load. For the most part supplies don’t really change that often though.
This parameter is for filtering MEV results and can be set to the following:
  • FILTERED – MEV-related events are excluded from the data.
  • UNFILTERED – Includes all events, including those related to MEV activity.
MEV transactions can significantly impact volume, liquidity, and price calculations. By using FILTERED, you get a clearer picture of organic trading activity without MEV influence. Conversely, UNFILTERED provides a full view, including arbitrage and sandwich attacks.
You can find the creator/dev address on enhancedToken which is available for most queries.
Most of our endpoints support pagination with the cursor parameter in order to retrieve additional events when necessary.
They are Unix timestamps. For example, to retrieve data for December 26th 2024 you would use “from: 1735171200 to: 1735257600”
Uniswap V4 supports native ETH as a pool token (rather than wrapped WETH). To detect this, query the protocolData field on a pair and check the isToken0NetworkToken flag on the UniswapV4Data type:
protocolData {
  ... on UniswapV4Data {
    uniswapV4HookAddress
    isToken0NetworkToken
  }
}
The simplest way to surface this is via filterPairs or filterTokens responses. For full field detail see UniswapV4Data.
Yes. Pass profanity: false in your filterTokens filters to exclude tokens with profanity in their name or metadata. This is especially useful for consumer-facing search experiences. For full filter options see filterTokens.

​
Subscriptions

There’s no hard limit — what matters is how many tokens you’re watching on a single connection and how active those tokens are, not the number of subscribe messages. A good starting point is up to ~100 tokens per connection. Spread tokens across connections so one connection doesn’t end up with all the high-volume names (SOL, top trending tokens, busy pairs) while the others sit idle. If you start dropping messages, lower the per-connection density and add more connections. Growth plans allow up to 300 connections. See our Subscriptions concept for more information.
For the token balances, it’s updated in real-time after finalization which takes about 1.8s on average.
If you are using custom code to subscribe to websockets, we advise sending a ping to keep the connection alive. Alternatively, you can use our SDK which is easier to implement, but can be less flexible.