> ## 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.

# Frequently Asked Questions

> Find answers to commonly asked questions about Codex

<Tip>
  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](https://discord.gg/9ZB7zcWuBY).
</Tip>

<Note>
  This FAQ covers cross-cutting questions about Codex. For endpoint-specific questions, check the [GraphQL Reference](https://docs.codex.io/api-reference/introduction). For error messages and debugging, see [Troubleshooting](https://docs.codex.io/extra/troubleshooting).
</Note>

## Getting Started

<AccordionGroup>
  <Accordion title="How do I get started with the Codex API?">
    Everything you need to get started can be found in our "[Get Started](/get-started)" page. If you need further help, refer to this FAQ or reach out to us on [Discord](https://discord.gg/9ZB7zcWuBY).
  </Accordion>

  <Accordion title="Is this OpenAI Codex? Is there a Codex CLI or app to download?">
    No — this Codex is unrelated to OpenAI's Codex coding agent (or its CLI). Codex ([codex.io](https://codex.io)) is a GraphQL API for real-time on-chain data: token prices, charts, trades, wallets, launchpads, and prediction markets. There is no app or CLI to install; you access it over HTTP or WebSocket with an API key from the [dashboard](https://dashboard.codex.io).

    If you're looking to use Codex *from* an AI coding agent (Claude Code, Cursor, OpenAI Codex, etc.), see [Codex Skills](/agents/codex-skills) and the [Codex Docs MCP](/agents/docs-mcp).
  </Accordion>

  <Accordion title="Do you have an explorer for building and testing queries?">
    Yes, our [explorer](https://explorer.codex.io/?utm_source=codex\&utm_medium=docs\&utm_campaign=extras-faq) 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.
  </Accordion>

  <Accordion title="How can I find practical examples of Codex queries currently in use?">
    We suggest downloading the [Chrome GraphQL Network Inspector](https://chromewebstore.google.com/detail/graphql-network-inspector/ndlbedplllcgconngcnfmkadhokfaaln) and then inspecting the queries used on [Defined.fi](http://Defined.fi) as you navigate through the different sections of the site to find out what's possible with the Codex API.
  </Accordion>

  <Accordion title="What networks does Codex support?">
    Codex supports over 75+ Million tokens across [80+ Networks](/networks) and growing by the day. To see if we support a network you are interested in, you can browse our [Supported Networks](https://docs.codex.io/networks) page, use the network filters at [Defined.fi](https://www.defined.fi/tokens/discover), or query [`getNetworks`](/api-reference/queries/getnetworks) from our API using a free or paid API key at [explorer.codex.io](https://explorer.codex.io/).
  </Accordion>

  <Accordion title="How do I get help with signing up, signing in, or deleting my account?">
    Account creation, sign-in problems, account deletion, and billing questions are handled by the Codex team directly. Email [support@codex.io](mailto:support@codex.io) or reach out in [Discord](https://discord.gg/9ZB7zcWuBY) with details of the issue, and the team will help.
  </Accordion>

  <Accordion title="Is there an SDK for Python, Go, or another language?">
    The only official SDK is the TypeScript GraphQL SDK. There are no current plans for additional language SDKs. From any other language, call the GraphQL endpoint over HTTP using any HTTP client. The request format is the same one shown in the [Get Started](/get-started) and [Authentication](/concepts/authentication) guides.
  </Accordion>

  <Accordion title="How do I keep my API key out of the browser's network tab? Can I use a temporary API key?">
    Yes — use short-lived API tokens so your long-lived key never ships to the client. Call [`createApiTokens`](/api-reference/mutations/createapitokens) from your backend to mint a token with a short `expiresIn`, then pass that token in the `Authorization` header of requests made from the browser. See the [Authentication](/concepts/authentication) guide for details, and the [`shortLivedTokens` SDK example](https://github.com/Codex-Data/sdk/blob/main/examples/simple/shortLivedTokens.ts) for a working sample.
  </Accordion>

  <Accordion title="How many tokens can I generate with `createApiTokens`?">
    You can request up to 25 tokens per [`createApiTokens`](/api-reference/mutations/createapitokens) call. There is no limit on the total number per account.
  </Accordion>
</AccordionGroup>

## Pricing & Billing

<AccordionGroup>
  <Accordion title="What payment methods does Codex accept?">
    Codex accepts all major debit and credit cards through our payment processor, Stripe. We also accept crypto payments in 3-month increments — email [support@codex.io](mailto:support@codex.io) or reach out on [Discord](https://discord.gg/9ZB7zcWuBY) if you'd like to pay in crypto.
  </Accordion>

  <Accordion title="How are WebSocket requests billed?">
    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](https://discord.gg/9ZB7zcWuBY) or via Email for information on custom plans.
  </Accordion>

  <Accordion title="How are overages billed if I go over my plan's monthly request limit?">
    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](/concepts/rate-limits) for full details.
  </Accordion>

  <Accordion title="How is usage counted for queries, subscriptions, and webhooks?">
    Usage is counted per query response. A single query response counts as one request. If you combine multiple queries in one request using aliases, each query response counts separately, so `filterTokens` plus `getDetailedTokenStats` in the same request counts as two. Subscriptions count one request per message delivered to you. An open subscription that is not currently sending messages does not consume usage. Webhooks count only when a message is delivered, meaning when your condition is met. Codex evaluates events against your conditions internally, and that evaluation is not counted. To serve many users without multiplying usage, subscribe once on your backend and fan out updates to your users. See [Rate Limits & Connection Limits](/concepts/rate-limits) and the [Optimization](/concepts/optimization) guide for details.
  </Accordion>
</AccordionGroup>

## Data Coverage & Methodology

<AccordionGroup>
  <Accordion title="How does Codex identify and label scam tokens vs verified tokens?">
    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.
  </Accordion>

  <Accordion title="How are token prices computed by Codex?">
    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.
  </Accordion>

  <Accordion title="How do I filter out noise and low-quality tokens from `filterTokens`?">
    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.
  </Accordion>

  <Accordion title="How far back do your historical prices go on Solana?">
    Our Solana data begins on March 20th, 2024. Unfortunately, it is not feasible to backfill data prior to this date.
  </Accordion>

  <Accordion title="How do I find which exchange a token is trading on?">
    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.
  </Accordion>

  <Accordion title="How does Codex handle dropped transactions and chart candle corrections?">
    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.
  </Accordion>

  <Accordion title="How do I get a token's all-time high (ATH) price?">
    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.
  </Accordion>

  <Accordion title="Is there aggregated chart data for launchpad tokens (creation → graduation → migration)?">
    Yes. Instead of getBars, you can now use [getTokenBars](/api-reference/queries/gettokenbars) for aggregated charts across all valid pairs.
  </Accordion>

  <Accordion title="How and when is metadata for tokens obtained?">
    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](http://Defined.fi) via a moderated proposal system.\
    \
    For established Web3 projects, additional verified metadata is enriched by The Grid. See [Verified Metadata](https://docs.codex.io/recipes/discover-tokens#verified-metadata) for details on the `asset`, `assetDeployments`, and `organization` fields available on `filterTokens`, `token`, and `tokens`.
  </Accordion>

  <Accordion title="What's the difference between `createdAt` and `token.createdAt`?">
    These represent different things and often won't match. `createdAt` (on the result, e.g. a `filterTokens` result) is the on-chain creation timestamp of the token's *current top pair* — not the token itself, so for older tokens with multiple pairs it can be later than the token's first pair. `token.createdAt` (on the `token`/`enhancedToken` object) is our *indexing time* — when we first saw the token. That's typically 1-2s after pair creation for new tokens, but can be months or years later for historical tokens that predate our coverage of their source (e.g. pump.fun tokens created before we supported it). For per-pair creation timestamps, use [`listPairsForToken`](/api-reference/queries/listpairsfortoken).

    You may also notice `lastTransaction` (the last on-chain *trade*) timestamped prior to `token.createdAt` — that's expected, since our indexing time can be later than the last trade, and transfers or burns don't update `lastTransaction`.
  </Accordion>

  <Accordion title="How is market cap calculated when circulating supply is higher than total supply?">
    If circulating supply exceeds total supply, we fall back to total supply to avoid inaccuracies. You can manually adjust this using: circulatingSupply \* price
  </Accordion>

  <Accordion title="How do I get historical token supply data?">
    Unfortunately we do not have historical supply information. All responses will return current supply amounts.
  </Accordion>

  <Accordion title="Why are some launchpad tokens missing graduation/migration data?">
    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](https://docs.codex.io/launchpads) for the full list of supported launchpads and which use bonding curves.
  </Accordion>

  <Accordion title="How do I keep market cap up-to-date in a chart when circulating supply changes?">
    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.
  </Accordion>

  <Accordion title="What does `statsType` (FILTERED vs UNFILTERED) do?">
    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.
  </Accordion>

  <Accordion title="How do I get the creator/dev address for a token?">
    You can find the creator/dev address on `enhancedToken` which is available for most queries.
  </Accordion>

  <Accordion title="How do I paginate results past the 200-result limit?">
    Most of our endpoints support pagination with the `cursor` parameter in order to retrieve additional events when necessary.
  </Accordion>

  <Accordion title="What is the proper format for the &#x22;from&#x22; and &#x22;to&#x22; timestamps?">
    They are Unix timestamps. For example, to retrieve data for December 26th 2024 you would use "from: 1735171200 to: 1735257600"
  </Accordion>

  <Accordion title="How do I detect when a Uniswap V4 pool's quote token is actually ETH and not WETH?">
    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:

    ```graphql theme={null}
    protocolData {
      ... on UniswapV4Data {
        uniswapV4HookAddress
        isToken0NetworkToken
      }
    }
    ```

    The simplest way to surface this is via `filterPairs` or `filterTokens` responses. For full field detail see [UniswapV4Data](https://docs.codex.io/api-reference/types/uniswapv4data#uniswapv4data).
  </Accordion>

  <Accordion title="Can I filter out tokens with profanity in their name or metadata?">
    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](https://docs.codex.io/api-reference/queries/filtertokens).
  </Accordion>

  <Accordion title="Does Codex have a token screener?">
    There is no separate screener product. The [`filterTokens`](/api-reference/queries/filtertokens) query powers screeners, trending feeds, and token discovery. You can rank by attributes such as volume, price change, and trending score, and filter by network, exchange, and liquidity. You can also see Codex's trending data in action on [Defined.fi](https://www.defined.fi). For a step-by-step guide, see the [Discover Tokens](/recipes/discover-tokens) recipe.
  </Accordion>

  <Accordion title="What is a token &#x22;mint&#x22; and how do I look one up?">
    On Solana, a token's mint is its on-chain address. Use that address as the `address` value together with Solana's `networkId` (`1399811149`) in queries such as `token`, `tokens`, or `filterTokens`. Across Codex, tokens are always identified by address plus `networkId`. See [Supported Networks](/networks) for every chain's ID.
  </Accordion>

  <Accordion title="What is the difference between marketCap and circulatingMarketCap?">
    `marketCap` is the fully diluted value, price multiplied by total supply. It replaces the older FDV field, which is deprecated. `circulatingMarketCap` is a separate field based on circulating supply, price multiplied by circulating supply. The two are equal only when total supply equals circulating supply.
  </Accordion>

  <Accordion title="What is trendingScore, and what is the difference between trendingScore and trendingScore24?">
    `trendingScore` is a composite ranking signal built from factors such as volume, liquidity, and unique buyers and sellers, among others. The exact formula is not published and is subject to change. The windowed variants (`trendingScore5m`, `trendingScore1`, `trendingScore4`, `trendingScore12`, `trendingScore24`) are the same metric measured over different time windows. `trendingScore` and `trendingScore24` return the same data. To reproduce the Defined.fi Discover list, rank by `trendingScore24` with `trendingIgnored` set to `false` and `statsType` set to `FILTERED`.
  </Accordion>
</AccordionGroup>

## Subscriptions

<AccordionGroup>
  <Accordion title="What's the limit of subscriptions per websocket connection?">
    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](https://docs.codex.io/concepts/subscriptions) for more information.
  </Accordion>

  <Accordion title="What's the latency for real-time data? For example, retrieveing user token balances after a swap?">
    For the token balances, it's updated in real-time after finalization which takes about 1.8s on average.
  </Accordion>

  <Accordion title="How do I keep my WebSocket subscription from disconnecting?">
    If you are using custom code to subscribe to websockets, we advise [<u>sending a ping</u>](https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md#ping) to keep the connection alive. Alternatively, you can use our SDK which is easier to implement, but can be less flexible.
  </Accordion>
</AccordionGroup>