> ## 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. # Serialized to Codex > Move your Serialized Data API integration to Codex Serialized and Codex cover a similar problem space: real-time token, pool, trade, holder, and wallet data for trading apps across Solana and EVM chains. Serialized's endpoints map cleanly onto Codex queries and subscriptions, and most of your integration has a direct equivalent. This guide maps every Serialized endpoint and stream to its Codex query, subscription, or webhook, shows working side-by-side examples for the most common patterns, and ends with a copy-paste prompt you can hand to an LLM to migrate the rest of your codebase. ## Mental model Serialized is a REST API at `https://api.serialized.xyz/v1/...` where every call takes a `chain` query parameter (`evm:8453`, `solana`), single-item endpoints have `POST` batch twins, each endpoint has its own credit cost, and every response is wrapped in `{ data, meta }` with millisecond timestamps. Codex is a single GraphQL Supergraph: one endpoint (`https://graph.codex.io/graphql`), one auth header, one query language, and the network is a numeric `networkId` argument on each field. What that means in practice: * Single and batch endpoints collapse into one field. `GET /v1/token` and `POST /v1/token` become one `tokens` or `filterTokens` query that takes an array, and GraphQL aliases batch anything else. * Per-endpoint credit costs go away. Every Codex query response counts as one request, whether it returns a price, a candle set, or a holder list. See [Rate Limits](/concepts/rate-limits). * Network selection lives next to the data, so the same query covers Solana, Ethereum, Base, BNB, and [80+ networks](https://docs.codex.io/networks) instead of 18 EVM chains plus Solana. * Real-time data has two delivery options instead of one. Serialized is WebSocket-only with three channels; Codex gives you [WebSocket subscriptions](/concepts/subscriptions) and [webhooks](/concepts/webhooks), and you can mix them in the same app. If you've never used GraphQL, [Learn GraphQL](/learn-graphql) is a 10-minute primer that's enough to follow the rest of this guide. ### Conventions that change The data is the same; the shapes differ. Keep this table next to you while migrating. | | Serialized | Codex | | :---------------- | :----------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------- | | Network | `chain=evm:8453`, `chain=solana` | `networkId: 8453`, `networkId: 1399811149` | | Token identity | `chain` + `address` params | `"
:"` string (`0x4ed4…efed:8453`) where a `tokenId` or `symbol` is expected, otherwise `{ address, networkId }` | | Timestamps | Unix milliseconds, `At` suffix (`fromAt`, `createdAt`) | Unix seconds (`from`, `to`, `timestamp`, `createdAt`) | | USD amounts | Numbers | Strings on most stats fields (`priceUSD`, `volume24`), floats on `getTokenPrices.priceUsd`. Parse before doing math. | | Percent changes | Percent values (`12.42` = 12.42%) | Decimals (`0.1242` = 12.42%) on `change*` fields | | Response envelope | `{ data, meta }`, `meta.asOf` | `{ data: { : ... } }`, plus `errors` on failure. See [Errors & Retries](/concepts/errors). | | Pagination | `cursor` + `meta.nextCursor` on tapes, `limit`/`offset` on wallets | `cursor` on events and balances, `offset` on `filterTokens` and other filter queries | | Batching | `POST` twins with `items[]` | Array inputs (`getTokenPrices(inputs: [...])`, up to 25) and GraphQL aliases | | Billing | 1 to 750 credits per call depending on endpoint | 1 request per query response, flat | Codex network IDs used below: `evm:1` → 1, `evm:8453` → 8453, `evm:56` → 56, `evm:42161` → 42161, `evm:43114` → 43114, `evm:130` → 130, `evm:143` → 143, `evm:4326` → 4326, `evm:4663` → 4663, `solana` → 1399811149. For anything else, call [`getNetworks`](/api-reference/queries/getnetworks) once; for `evm:` the numeric part is the Codex `networkId` on every network Codex supports. ## Authentication Serialized uses an `Authorization` header set to your raw API key against `https://api.serialized.xyz`, with an unauthenticated demo host at `https://demo.serialized.xyz`. Codex also uses an `Authorization` header with your API key from the [dashboard](https://dashboard.codex.io?utm_source=codex\&utm_medium=docs\&utm_campaign=migrations-serialized), so the header itself doesn't change. The difference is network moves from a query parameter to a field argument, and the request body becomes GraphQL. For trying queries without writing code, use the [explorer](/explore) or the "Try it" panels throughout the reference. ```bash Serialized theme={null} curl "https://api.serialized.xyz/v1/token/price?chain=evm:8453&address=0x4ed4e862860bed51a9570b96d89af5e1b0efefed" \ -H "Authorization: $SERIALIZED_API_KEY" ``` ```bash Codex theme={null} curl https://graph.codex.io/graphql \ -H "Authorization: $CODEX_API_KEY" \ -H "Content-Type: application/json" \ -d '{"query":"{ getTokenPrices(inputs: [{ address: \"0x4ed4e862860bed51a9570b96d89af5e1b0efefed\", networkId: 8453 }]) { priceUsd timestamp address } }"}' ``` For browser-facing apps, generate a short-lived JWT with [`createApiTokens`](/api-reference/mutations/createapitokens) and pass it as `Bearer `. See [Authentication](/concepts/authentication) for the full pattern. ## Endpoint mapping The tables cover every Serialized endpoint, grouped the way their docs group them. Where Serialized splits a concept into a single endpoint and a `POST` batch twin, the Codex equivalent on the right replaces both. ### Token snapshot, prices, and metadata | Serialized | Codex equivalent | Notes | | :------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `GET /v1/token`, `POST /v1/token` | [`filterTokens(tokens: [...])`](/api-reference/queries/filtertokens) or [`token`](/api-reference/queries/token) + [`getDetailedTokenStats`](/api-reference/queries/getdetailedtokenstats) | `filterTokens` with a `tokens` list returns metadata, price, market cap, liquidity, launchpad state, and 24h stats for up to 200 tokens in one call. Use `token` + `getDetailedTokenStats` when you want the full multi-window picture for one token. | | `GET /v1/token/price`, `POST /v1/token/price` | [`getTokenPrices`](/api-reference/queries/gettokenprices) | Lean price tier. Max 25 inputs per call; chunk larger batches. Market cap and liquidity come from `filterTokens`. | | `GET /v1/token/stats` | [`getDetailedTokenStats`](/api-reference/queries/getdetailedtokenstats) | Serialized returns 5m / 1h / 6h / 24h. Codex returns 5m / 1h / 4h / 12h / 24h, plus weekly, each with its own change value, and splits unique buyers and sellers. | | `GET /v1/token/metadata`, `POST /v1/token/metadata` | [`token`](/api-reference/queries/token), [`tokens`](/api-reference/queries/tokens) | `info` (supply, images, description) and `socialLinks` on the same object. | | `POST /v1/token/sparklines`, `POST /v1/pools/sparklines` | [`tokenSparklines`](/api-reference/queries/tokensparklines) | Token-level sparklines. Pool-level sparklines have no direct twin; use [`getBars`](/api-reference/queries/getbars) at a coarse resolution. | | `GET /v1/prices/native` | [`getTokenPrices`](/api-reference/queries/gettokenprices) | Pass each network's wrapped native token (WETH, WSOL, WBNB) as an input. | | `GET /v1/search` | [`filterTokens(phrase: ...)`](/api-reference/queries/filtertokens) | Address or free text. Use `$SYMBOL` for exact symbol matches; combine with rankings and filters. | ### Security and deployer | Serialized | Codex equivalent | Notes | | :-------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `GET /v1/token/security`, `POST /v1/token/security` | [`token`](/api-reference/queries/token) + [`filterTokens`](/api-reference/queries/filtertokens) + [`liquidityMetadataByToken`](/api-reference/queries/liquiditymetadatabytoken) | Mint and freeze authority (`mintable`, `freezable`), `isScam`, `creatorAddress`, and `top10HoldersPercent` are inline on `token`. Holder count, sniper / bundler / insider / dev held percentages, and `potentialScam` are `filterTokens` attributes. Locked and burned LP come from `liquidityMetadataByToken` and [`liquidityLocksV2`](/api-reference/queries/liquiditylocksv2). Buy / sell / transfer tax and `dexPaid` have no Codex field today. | | `GET /v1/token/dev-tokens` | [`filterTokens(filters: { creatorAddresses: [...] })`](/api-reference/queries/filtertokens) + [`detailedWalletStats`](/api-reference/queries/detailedwalletstats) | Every token a wallet deployed, with the same stats as any other token. `wallet.tokensCreatedCount` and `wallet.tokensMigratedCount` give the aggregate; there is no per-deployer risk verdict. | | `GET /v1/audit/contract`, `GET /v1/audit/chains` | Not supported | Contract source auditing is Serialized's separate Audit product. See the note below. | **Dedicated token safety is coming soon.** Today, Codex surfaces safety flags on [`token`](/api-reference/queries/token) (`isScam`, `mintable`, `freezable`, `creatorAddress`, `top10HoldersPercent`), distribution-based risk signals through [`filterTokens`](/api-reference/queries/filtertokens) (insider / sniper / bundler / dev held %, `potentialScam`), and locked-LP context through [`liquidityLocksV2`](/api-reference/queries/liquiditylocksv2). A dedicated token contract scanner for honeypot and hidden-tax detection, closer to Serialized's `/v1/audit/contract`, is in active development. If contract-level security is core to your product, flag those call sites during migration and reach out so we can share timelines. ### Holders and traders | Serialized | Codex equivalent | Notes | | :-------------------------- | :-------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `GET /v1/token/holders` | [`holders`](/api-reference/queries/holders) + [`filterTokenWallets`](/api-reference/queries/filtertokenwallets) | `holders` for the ranked balance list with `count`; `filterTokenWallets` for per-holder realized and unrealized PnL, buy / sell volume, average cost, and behavioral labels (`includeLabels` / `excludeLabels`). | | `GET /v1/token/top-traders` | [`tokenTopTraders`](/api-reference/queries/tokentoptraders) | `tradingPeriod` is `DAY`, `WEEK`, `MONTH`, or `YEAR`. For `all`, or to sort by bought / sold / txns, use `filterTokenWallets` with rankings. | | `GET /v1/pool/top-traders` | [`filterTokenWallets`](/api-reference/queries/filtertokenwallets) | Codex ranks traders per token, not per pool. | ### Pools and markets | Serialized | Codex equivalent | Notes | | :--------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `GET /v1/token/pools` | [`listPairsWithMetadataForToken`](/api-reference/queries/listpairswithmetadatafortoken) | All venues for a token with liquidity, price, and volume. The `pool` object on `filterTokens` results is the pair Codex prices the token from. | | `GET /v1/pool` | [`pairMetadata`](/api-reference/queries/pairmetadata) | Static definition: exchange, tokens, fee, creation. `pairId` is `":"`. | | `GET /v1/pool/data`, `POST /v1/pools/data` | [`getDetailedPairStats`](/api-reference/queries/getdetailedpairstats), [`getDetailedPairsStats`](/api-reference/queries/getdetailedpairsstats) | Windowed volume, buys / sells, price change per pool. The plural form is the batch twin. Live twin: [`onPairMetadataUpdated`](/api-reference/subscriptions/onpairmetadataupdated). | | `GET /v1/pool/ohlcv`, `POST /v1/pool/ohlcv` | [`getBars`](/api-reference/queries/getbars) | Pair-scoped OHLCV; `symbol` is `":"`, use `quoteToken` to pick the side. | | `GET /v1/pool/trades`, `POST /v1/pools/trades` | [`getTokenEvents`](/api-reference/queries/gettokenevents) | Pass the pool address in `query: { address, networkId }`. Filter by `maker`, direction, USD size, and time range. | | `GET /v1/meta/factories` | [`filterLaunchpads`](/api-reference/queries/filterlaunchpads) + [`getExchanges`](/api-reference/queries/getexchanges) | Launchpads and DEX exchanges are separate catalogs on Codex. | | `GET /v1/meta/chains` | [`getNetworks`](/api-reference/queries/getnetworks) | Returns the `networkId`s you use everywhere else. [`getNetworkStatus`](/api-reference/queries/getnetworkstatus) gives indexing health. | ### Charts and OHLCV | Serialized | Codex equivalent | Notes | | :-------------------------------------------- | :---------------------------------------------------- | :----------------------------------------------------------------------------------------------- | | `GET /v1/token/ohlcv`, `POST /v1/token/ohlcv` | [`getTokenBars`](/api-reference/queries/gettokenbars) | Token-level OHLCV from the token's top pair. `from` / `to` are unix seconds. Batch with aliases. | | `GET /v1/pool/ohlcv` | [`getBars`](/api-reference/queries/getbars) | Pool-level OHLCV. | Interval names change. Serialized `1s` → Codex `1S`, `5s` → `5S`, `15s` → `15S`, `30s` → `30S`, `1m` → `1`, `5m` → `5`, `15m` → `15`, `30m` → `30`, `1h` → `60`, `4h` → `240`, `12h` → `720`, `1d` → `1D`, `1w` → `7D`. Serialized's `3m`, `2h`, `6h`, and `1M` have no direct Codex resolution; request the next finer resolution and roll up client-side. Sub-minute resolutions are only populated for the last 24 hours. Serialized's `quote=usd` is the `currencyCode: "USD"` argument on Codex; `quote=native` is `currencyCode: "TOKEN"`. ### Trades | Serialized | Codex equivalent | Notes | | :--------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `GET /v1/token/trades` | [`getTokenEvents`](/api-reference/queries/gettokenevents) | Pass the token address and Codex reads its top pair; pass a pool address for a specific pool. Filter by USD size, direction, maker, and time range. Serialized's `isSniper` / `isProTrader` badges map to the `labels` on each event's maker and to `filterTokenWallets` labels. | | `POST /v1/token/trades` (makers filter) | [`getTokenEvents(query: { maker: ... })`](/api-reference/queries/gettokenevents) or [`getTokenEventsForMaker`](/api-reference/queries/gettokeneventsformaker) | Single maker on a token via the `maker` filter; one wallet across tokens via `getTokenEventsForMaker`. | | `GET /v1/pool/trades`, `POST /v1/pools/trades` | [`getTokenEvents`](/api-reference/queries/gettokenevents) | Pool address in `query.address`. Batch pools with aliases. | Serialized's `fromAt` is milliseconds; Codex `timestamp: { from, to }` is seconds. Serialized's `isWash` flag has no Codex equivalent. Codex events carry `tradeSource` (the wallet or terminal that originated the swap) on Solana and major EVM networks, which Serialized does not expose. ### Wallets | Serialized | Codex equivalent | Notes | | :-------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `GET /v1/wallet/positions`, `POST /v1/wallet/positions` | [`balances`](/api-reference/queries/balances) + [`filterTokenWallets`](/api-reference/queries/filtertokenwallets) | `balances` for holdings with USD value (`networks` is an array, so one query can span chains; native EVM balances require traces support). `filterTokenWallets` with `wallets: [...]` for per-token realized / unrealized PnL and average cost. | | `GET /v1/wallet/closed-positions`, `POST /v1/wallet/closed-positions` | [`filterTokenWallets`](/api-reference/queries/filtertokenwallets) | Filter to rows where `tokenBalanceLive` is zero; `realizedProfitUsd1y`, `amountBoughtUsd1y`, and `amountSoldUsd1y` (and the 1d / 1w / 30d variants) are on each row. See [Wallet PnL](/concepts/wallet-pnl) for the accounting. | | `GET /v1/wallet/trades`, `POST /v1/wallet/trades` | [`getTokenEventsForMaker`](/api-reference/queries/gettokenevents) | Swap events for a wallet, newest first, with `cursor` pagination. Filter by `tokenAddress` if needed. | | `GET /v1/wallet/pnl`, `POST /v1/wallet/pnl` | [`detailedWalletStats`](/api-reference/queries/detailedwalletstats) + [`walletChart`](/api-reference/queries/walletchart) | `detailedWalletStats` returns realized PnL, wins / losses (win rate is `wins / (wins + losses)`), swap counts, and volume across 1d / 1w / 30d / 1y windows in one call. `walletChart` is the daily curve. | | `GET /v1/wallet/equity/history` | [`walletChart`](/api-reference/queries/walletchart) | Net worth and PnL over time; resolutions `60`, `240`, `1D`, `7D`. | | `GET /v1/wallet/profile`, `POST /v1/wallet/profile` | [`detailedWalletStats`](/api-reference/queries/detailedwalletstats) (`wallet` object) | `displayName`, `avatarUrl`, `category`, `identityLabels`, socials (`twitterUsername`, `telegramUsername`, `farcasterUsername`, `website`), `ethosScore`, `tradeSourceIds`, and `polymarket` profile. ENS / Basename / `.sol` names are not resolved separately from `displayName`. | | `GET /v1/wallet/funding` | [`detailedWalletStats`](/api-reference/queries/detailedwalletstats) (`wallet.firstFunding`) | First inbound transfer that funded the wallet. Coverage starts October 2025 and is strongest on EVM. | | `GET /v1/wallet/transfers` | Not supported | Codex returns swap and token-lifecycle events, not arbitrary transfers. See Gaps. | ### Discovery, screening, and launchpads Serialized's discovery surface (`/v1/pulse` for launchpad columns, `/v1/screener` for trending markets, `/v1/search`) collapses into a single Codex query: [`filterTokens`](/api-reference/queries/filtertokens). It is the most flexible endpoint in the API and worth understanding well before you migrate, because it replaces every Pulse view, every screener sort, and search at once. `filterTokens` takes a set of **filters** (range or boolean conditions on token attributes), optional **rankings** (sort by any attribute, ascending or descending), an optional **phrase** for search, and a network scope. In one request you can filter and rank across 100+ attributes, including: * **Price and valuation**: `priceUSD`, `marketCap`, `circulatingMarketCap`, `fdv`, and all-time highs / lows. * **Windowed trading stats** (5m / 1h / 4h / 12h / 24h): `volume*`, `buyVolume*`, `sellVolume*`, `txnCount*`, `uniqueBuys*`, `uniqueSells*`, `change*`, `high*`, `low*`. * **Liquidity and fees**: `liquidity`, `totalLiquidityUsd`, `totalFees*`, `poolFees*`. * **Holders and age**: `holders`, `top10HoldersPercent`, `age`, `createdAt`, `lastTransaction`. * **Safety and distribution signals**: `potentialScam`, `mintable`, `freezable`, `isVerified`, `insiderHeldPercentage`, `sniperHeldPercentage`, `bundlerHeldPercentage`, `devHeldPercentage`. * **Launchpad state**: `launchpadName`, `launchpadProtocol`, `launchpadGraduationPercent`, `launchpadCompleted`, `launchpadMigrated`. * **Creator**: `creatorAddresses`. Pulse's `view=new` is a `createdAt` range with `launchpadCompleted: false`; `view=bonding` is `launchpadGraduationPercent` between 0 and 100 with `launchpadMigrated: false`; `view=graduated` is `launchpadMigrated: true` ranked by `launchpadMigratedAt`. Pulse's `ageMin` / `liquidityMin` / `marketCapMin` / `bondingMin` / `volumeMin` / `txnsMin` / `feesMin` ranges are the same attributes as `filterTokens` range filters (`age`, `liquidity`, `marketCap`, `launchpadGraduationPercent`, `volume*`, `txnCount*`, `totalFees*`), and `factories` is `launchpadProtocol`. There is no `socials` filter; read `token.socialLinks` on each result instead. See the [Launchpads recipe](/recipes/launchpads) and [Discover Tokens recipe](/recipes/discover-tokens) for worked examples. `filterTokens` has a real-time twin: [`onFilterTokensUpdated`](/api-reference/subscriptions/onfiltertokensupdated) pushes the live, re-ranked result set for a filter as the market moves, so a Pulse column or trending board stays current without polling. Serialized has no streaming equivalent for Pulse or the screener. | Serialized | Codex equivalent | Notes | | :------------------------------------------------------------------ | :--------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `GET /v1/pulse` (`new`, `bonding`, `graduated`) | [`filterTokens`](/api-reference/queries/filtertokens) on launchpad fields | One query per column with the filters above. Stream via [`onFilterTokensUpdated`](/api-reference/subscriptions/onfiltertokensupdated) or [`onLaunchpadTokenEventBatch`](/api-reference/subscriptions/onlaunchpadtokeneventbatch). | | `GET /v1/screener` (`trending`, `volume`, `marketCap`, `createdAt`) | [`filterTokens`](/api-reference/queries/filtertokens), [`filterPairs`](/api-reference/queries/filterpairs) | Rank by `trendingScore*`, `volume*`, `marketCap`, or `createdAt` over any window. `filterPairs` if you want pool rows rather than token rows, like Serialized returns. | | `GET /v1/search` | [`filterTokens(phrase: ...)`](/api-reference/queries/filtertokens) | Search is an argument on the same endpoint. | ### Utility | Serialized | Codex equivalent | Notes | | :---------------------------------------------------------- | :--------------------------------------------------------- | :------------------------------------------------------------------ | | `GET /v1/meta/chains` | [`getNetworks`](/api-reference/queries/getnetworks) | Network catalog with `networkId`s. | | `GET /v1/usage`, `/v1/usage/history`, `/v1/usage/breakdown` | Codex usage in the [dashboard](https://dashboard.codex.io) | Request metering and per-endpoint breakdowns live in the dashboard. | ## Side-by-side examples The four patterns below are the ones trading apps migrate first. Token and wallet addresses are real (DEGEN on Base) and the queries are runnable. ### 1. Token snapshot (metadata + price + 24h stats) Serialized returns this from `GET /v1/token`. On Codex, `filterTokens` with a `tokens` list returns the same picture for up to 200 tokens in one call. ```bash Serialized theme={null} curl "https://api.serialized.xyz/v1/token?chain=evm:8453&address=0x4ed4e862860bed51a9570b96d89af5e1b0efefed" \ -H "Authorization: $SERIALIZED_API_KEY" ``` ```graphql Codex GraphQL theme={null} query TokenSnapshot { filterTokens( tokens: ["0x4ed4e862860bed51a9570b96d89af5e1b0efefed:8453"] limit: 1 ) { results { token { address name symbol decimals createdAt creatorAddress isScam info { totalSupply circulatingSupply imageLargeUrl description } socialLinks { twitter telegram website } launchpad { launchpadName graduationPercent completed migrated } } priceUSD marketCap circulatingMarketCap liquidity holders volume24 buyCount24 sellCount24 txnCount24 change24 pair { address exchangeHash } } } } ``` ```typescript Codex SDK theme={null} import { Codex } from "@codex-data/sdk" const sdk = new Codex(process.env.CODEX_API_KEY!) const { filterTokens } = await sdk.queries.filterTokens({ tokens: ["0x4ed4e862860bed51a9570b96d89af5e1b0efefed:8453"], limit: 1, }) const t = filterTokens?.results?.[0] console.log(t?.token?.symbol, t?.priceUSD, t?.marketCap, t?.change24) ``` `change24` is a decimal (`0.0375` = 3.75%), and `priceUSD`, `marketCap`, and `volume24` are strings. For the full 5m through weekly picture with unique buyers and sellers, add [`getDetailedTokenStats`](/api-reference/queries/getdetailedtokenstats). The [Detailed Token Page recipe](/recipes/detailed-token-page) shows the full pattern. ### 2. OHLCV chart ```bash Serialized theme={null} curl "https://api.serialized.xyz/v1/token/ohlcv?chain=evm:8453&address=0x4ed4e862860bed51a9570b96d89af5e1b0efefed&interval=1h&limit=24"e=usd" \ -H "Authorization: $SERIALIZED_API_KEY" ``` ```graphql Codex GraphQL theme={null} query TokenChart { getTokenBars( symbol: "0x4ed4e862860bed51a9570b96d89af5e1b0efefed:8453" from: 1757376000 to: 1757462400 resolution: "60" currencyCode: "USD" ) { t o h l c volume } } ``` Codex takes a `from` / `to` window in unix seconds instead of `limit` + `endTime`. Resolutions run from `1S` to `7D`. For live chart updates, layer in [`onTokenBarsUpdated`](/api-reference/subscriptions/ontokenbarsupdated). See the [Charts recipe](/recipes/charts) for a full Lightweight Charts integration. ### 3. Trade tape, then stream it ```bash Serialized theme={null} curl "https://api.serialized.xyz/v1/token/trades?chain=evm:8453&address=0x4ed4e862860bed51a9570b96d89af5e1b0efefed&limit=50" \ -H "Authorization: $SERIALIZED_API_KEY" ``` ```graphql Codex GraphQL theme={null} query TradeTape { getTokenEvents( query: { address: "0x4ed4e862860bed51a9570b96d89af5e1b0efefed" networkId: 8453 eventType: Swap } limit: 50 ) { items { timestamp transactionHash blockNumber logIndex maker eventDisplayType tradeSource data { ... on SwapEventData { amount0 amount1 priceUsd priceUsdTotal } } } cursor } } ``` ```graphql Codex subscription theme={null} subscription LiveTape { onTokenEventsCreated( input: { tokenAddress: "0x4ed4e862860bed51a9570b96d89af5e1b0efefed", networkId: 8453 } ) { events { timestamp transactionHash maker eventDisplayType data { ... on SwapEventData { priceUsdTotal } } } } } ``` Serialized's `trades` channel and `GET /v1/token/trades` share one shape; Codex's [`onTokenEventsCreated`](/api-reference/subscriptions/ontokeneventscreated) and [`getTokenEvents`](/api-reference/queries/gettokenevents) do too. To backfill after a disconnect, re-query `getTokenEvents` with `timestamp: { from }` set a couple of seconds before your last seen event and dedupe on `transactionHash` + `logIndex`. See the [Events recipe](/recipes/events). ### 4. Wallet positions and PnL Serialized splits this across `/v1/wallet/positions` and `/v1/wallet/pnl`. Codex returns holdings from `balances` and the PnL summary from `detailedWalletStats` in one request. ```bash Serialized theme={null} curl "https://api.serialized.xyz/v1/wallet/positions?chain=evm:8453&wallet=0x95d955179a7cd45aeef394ed39f6a8d8b1bd1e09&limit=50" \ -H "Authorization: $SERIALIZED_API_KEY" curl "https://api.serialized.xyz/v1/wallet/pnl?wallet=0x95d955179a7cd45aeef394ed39f6a8d8b1bd1e09&period=30d" \ -H "Authorization: $SERIALIZED_API_KEY" ``` ```graphql Codex GraphQL theme={null} query WalletOverview { balances( input: { walletAddress: "0x95d955179a7cd45aeef394ed39f6a8d8b1bd1e09" networks: [8453] removeScams: true } ) { items { tokenId shiftedBalance balanceUsd tokenPriceUsd } cursor } detailedWalletStats( input: { walletAddress: "0x95d955179a7cd45aeef394ed39f6a8d8b1bd1e09", networkId: 8453 } ) { statsDay30 { statsUsd { volumeUsd realizedProfitUsd realizedProfitPercentage } statsNonCurrency { swaps wins losses } } wallet { displayName category identityLabels } } } ``` For per-token positions with entry price and realized / unrealized PnL (Serialized's `realizedPnlUsd` and `totalPnlUsd` per row), use [`filterTokenWallets`](/api-reference/queries/filtertokenwallets) with `wallets: [...]`. See [Wallet PnL](/concepts/wallet-pnl) for how Codex computes cost basis, and the [Trader Dashboard recipe](/recipes/wallets/trader-dashboard) for the full screen. ## Real-time data Serialized streams over one WebSocket at `wss://api.serialized.xyz/v1/stream` with three channels (`trades`, `token-updates`, `pool-updates`), an `{"op":"auth"}` handshake, and per-key limits of 5 connections, 20 subscriptions per connection, and 50 watched tokens or pools in total. Token and pool updates are throttled to one event per second per token. Codex gives you the same data with two delivery options, and you can use both at once: * [WebSocket subscriptions](/concepts/subscriptions): persistent connection, updates pushed inline, API key in the connection auth. Best for dashboards, trading UIs, anything user-facing. Growth plans get 300 connections per key, and each connection can carry many subscriptions. * [Webhooks](/concepts/webhooks): Codex calls an HTTP endpoint you control when an event fires. Best for background jobs, alerts, and queue-driven systems. | Serialized channel | Codex subscription | Codex webhook | | :----------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------- | | `trades` | [`onTokenEventsCreated`](/api-reference/subscriptions/ontokeneventscreated) (token-wide or one pair), [`onEventsCreatedByMaker`](/api-reference/subscriptions/oneventscreatedbymaker) (one wallet) | Token swap webhook | | `token-updates` (price, market cap, liquidity, bonding, 24h stats) | [`onPricesUpdated`](/api-reference/subscriptions/onpricesupdated) for price, [`onDetailedTokenStatsUpdated`](/api-reference/subscriptions/ondetailedtokenstatsupdated) for windowed stats, [`onLaunchpadTokenEvent`](/api-reference/subscriptions/onlaunchpadtokenevent) for bonding progress | Price webhook | | `pool-updates` | [`onPairMetadataUpdated`](/api-reference/subscriptions/onpairmetadataupdated), [`onDetailedStatsUpdated`](/api-reference/subscriptions/ondetailedstatsupdated) | | | Polling `/v1/token/ohlcv` for live candles | [`onTokenBarsUpdated`](/api-reference/subscriptions/ontokenbarsupdated), [`onBarsUpdated`](/api-reference/subscriptions/onbarsupdated) | | | Polling `/v1/pulse` or `/v1/screener` | [`onFilterTokensUpdated`](/api-reference/subscriptions/onfiltertokensupdated), [`onLaunchpadTokenEventBatch`](/api-reference/subscriptions/onlaunchpadtokeneventbatch), [`onLatestTokens`](/api-reference/subscriptions/onlatesttokens) | Token launch webhook | | Polling `/v1/token/holders` | [`onHoldersUpdated`](/api-reference/subscriptions/onholdersupdated) | | | Polling `/v1/wallet/positions` | [`onBalanceUpdated`](/api-reference/subscriptions/onbalanceupdated) | | Cadence differs. Serialized throttles token and pool updates to one per second; Codex's `onPricesUpdated` fires once per token per block that contains a trade, and `onTokenEventsCreated` fires per swap. Codex bills one request per delivered message, so scope subscriptions to what you render. See [Rate Limits](/concepts/rate-limits) for connection sizing. ## Gaps Things Serialized does that Codex doesn't, and what to do about them: * **Contract auditing** (`/v1/audit/contract`, `/v1/audit/chains`, and the taxes / `dexPaid` fields on `/v1/token/security`). Serialized reads contract source for honeypot and hidden-tax verdicts. Codex surfaces on-chain safety signals (authorities, `isScam`, holder concentration, sniper / bundler / insider holdings, locked LP) but does not audit source today. A dedicated scanner is in development; keep a security provider for source-level verdicts until then. * **Deployer risk verdicts** (`/v1/token/dev-tokens` aggregate read). Codex lists every token a wallet created via `filterTokens(filters: { creatorAddresses })` and exposes `tokensCreatedCount` / `tokensMigratedCount` on the wallet, but does not score the deployer. * **Wallet transfers** (`/v1/wallet/transfers`). Codex returns swap and token-lifecycle events, not deposits, withdrawals, or plain transfers. Pair with an RPC provider or an Etherscan-family API if transfer history is core to your product. * **Name resolution** (ENS, Basename, `.sol` on `/v1/wallet/profile`). Codex exposes a resolved `displayName` and social handles but does not return the underlying name records separately. * **Wash-trade flags** (`isWash` on trades). No Codex equivalent. Codex exposes `tradeSource` and maker labels instead. * **Pool-level top traders and sparklines** (`/v1/pool/top-traders`, `/v1/pools/sparklines`). Codex ranks traders and builds sparklines per token; use `getBars` on the pool for a pool-scoped series. * **Native coin price list** (`/v1/prices/native`). Query the wrapped native token per network through `getTokenPrices`. ## What you pick up Things Codex offers that Serialized's data API doesn't: * **80+ networks, not 19.** Everything Serialized covers plus Polygon, Optimism, Linea, Sui, Aptos, Starknet, and dozens more, all through the same `networkId` argument. See [Networks](/networks). * **One query, many shapes.** GraphQL lets you combine token metadata, price, holders, recent trades, and chart data into a single request and only pull the fields you render. A Serialized token page hits `/v1/token`, `/v1/token/stats`, `/v1/token/holders`, and `/v1/token/trades`; the Codex equivalent is one request. * **Flat billing.** One request per query response, no per-endpoint credit multipliers. A candle query costs the same as a price query. * **One endpoint for almost any discovery need.** [`filterTokens`](/api-reference/queries/filtertokens) filters and ranks across 100+ attributes and does phrase search. It replaces Pulse, the screener, and search, and its subscription twin [`onFilterTokensUpdated`](/api-reference/subscriptions/onfiltertokensupdated) streams the same re-ranked list live, which Serialized has no equivalent for. * **Multi-timeframe stats in a single call.** [`getDetailedTokenStats`](/api-reference/queries/getdetailedtokenstats) and [`getDetailedPairStats`](/api-reference/queries/getdetailedpairstats) return volume, buys, sells, price change, and unique-maker counts across every window from 5-minute to weekly at once, each with its own change value. * **Streaming without hard caps.** Serialized allows 5 connections and 50 watched tokens per key. Codex Growth plans get 300 connections, each carrying many subscriptions, plus [webhooks](/concepts/webhooks) for server-side delivery. * **Prediction markets.** Polymarket and Kalshi events, markets, trades, and trader analytics via [`filterPredictionEvents`](/api-reference/queries/filterpredictionevents) and related queries. See [Prediction Markets](/prediction-markets). * **Launchpad lifecycle as events.** Serialized surfaces new / bonding / graduated columns; Codex models the full lifecycle (creation, bonding, graduation, migration) as queryable and streamable events across 200+ launchpads. See [Launchpads](/launchpads). * **Wallet discovery by performance.** [`filterWallets`](/api-reference/queries/filterwallets) queries for wallets matching PnL, win-rate, or volume criteria across all networks, not just for a single token. * **Trade source attribution.** `tradeSource` on events and `tradeSourceIds` on wallets tell you which terminal or wallet app originated a swap. * **Liquidity locks.** [`liquidityLocksV2`](/api-reference/queries/liquiditylocksv2) surfaces locked-LP context across major EVM chains and Solana. * **Categories and community notes.** Curated token [categories](/api-reference/queries/categories) and [community notes](/api-reference/queries/getcommunitynotes). * **Built for AI agents.** A [docs MCP server](/agents/docs-mcp), prebuilt [Codex Skills](/agents/codex-skills) for Claude / Cursor / Codex CLI, and pay-per-query access via [MPP](/agents/mpp). ## AI migration prompt Most Serialized integrations span dozens of call sites: a price service here, a chart loader there, a Pulse column, a websocket handler. Hand the prompt below to an IDE agent (Claude Code, Cursor, Codex CLI, or similar), run it from the repo root, and it will discover every Serialized touchpoint, propose a plan, and execute the migration with your approval. Pair this prompt with our [Codex Skills](/agents/codex-skills) and [docs MCP server](/agents/docs-mcp) so the agent can look up Codex queries on demand instead of guessing at field names. ```markdown theme={null} You are migrating this codebase from Serialized (https://docs.serialized.xyz) to Codex (https://docs.codex.io). Serialized and Codex overlap heavily on token, pool, trade, holder, and wallet data, so most call sites have a direct replacement. A few do not, and those need to be surfaced rather than silently dropped. ## Phase 1: Discovery (do this first, do not edit yet) Search the codebase for every Serialized integration point. At minimum, look for: - HTTP calls to `api.serialized.xyz` or `demo.serialized.xyz` (any path under `/v1/...`). - WebSocket connections to `wss://api.serialized.xyz/v1/stream` and messages with `op: "auth"`, `op: "subscribe"`, or `channel` set to `trades`, `token-updates`, or `pool-updates`. - Environment variables and config keys named `SERIALIZED_*`. - Header usage of `Authorization` pointing at Serialized. - Code that builds or switches on `chain` values like `evm:8453` or `solana`, and code that reads the `{ data, meta }` envelope or `meta.nextCursor` / `meta.hasMore`. - Code that treats timestamps as milliseconds (`At`-suffixed fields) or percents as whole numbers. - Tests, fixtures, and mocks that reference any of the above. Produce a Migration Plan with: 1. A grouped list of every call site, organized by Serialized endpoint. 2. The proposed Codex equivalent for each group (use the mapping below). 3. Any call sites you cannot map cleanly, flagged for human review. 4. The order you intend to make changes (shared client/config first, then leaf call sites, then tests). 5. New dependencies, env vars, and config you will introduce. Stop and surface the plan before editing any source files. Wait for confirmation. ## Phase 2: Execution (after the plan is approved) Ground rules: 1. Codex is a GraphQL API at `https://graph.codex.io/graphql`. Auth header is `Authorization: ` for long-lived keys, or `Authorization: Bearer ` for short-lived keys. Serialized's `Authorization: ` header maps directly; the request body changes to GraphQL. 2. Codex ships an official SDK for TypeScript/JavaScript only (`@codex-data/sdk`). Prefer it over hand-rolled HTTP in TS/JS projects. For Python and every other language there is no official SDK: use raw GraphQL over HTTP against `https://graph.codex.io/graphql`. 3. Network is a numeric `networkId` argument, not a `chain` query param. For `evm:` the numeric part is the Codex `networkId` (`evm:1` → 1, `evm:8453` → 8453, `evm:56` → 56); `solana` → 1399811149. Call `getNetworks` once and build a lookup rather than hardcoding. 4. Token IDs in Codex are the string `"
:"` wherever a `tokenId` or `symbol` argument is expected (`filterTokens.tokens`, `getTokenBars.symbol`, `balances.items.tokenId`). Elsewhere pass `{ address, networkId }`. Construct them explicitly. 5. Timestamps: Serialized uses unix milliseconds (`fromAt`, `beforeAt`, `createdAt`, `meta.asOf`); Codex uses unix seconds everywhere (`from`, `to`, `timestamp`, `createdAt`). Divide by 1000 on the way in and multiply on the way out. 6. Numbers: Serialized returns USD as numbers and percents as percent values (`12.42`); Codex returns most USD stats as strings (`priceUSD`, `volume24`, `marketCap`) and percent changes as decimals (`0.1242`). Parse strings and multiply decimals by 100 where the UI expects percents. 7. Responses: Serialized wraps every response in `{ data, meta }`; Codex returns `{ data: { : ... } }` and reports failures in an `errors` array, usually with HTTP 200. Check for `errors` in the body, not just the status code. Retry only when `extensions.retryAfterSeconds` is present. 8. Pagination: Serialized `cursor` + `meta.nextCursor` maps to Codex `cursor` on `getTokenEvents`, `getTokenEventsForMaker`, and `balances`; Serialized `limit`/`offset` on wallet endpoints maps to `limit`/`offset` on `filterTokens` and `filterTokenWallets`. `meta.hasMore` becomes "cursor is non-null" or "results shorter than limit". 9. Collapse Serialized's single/batch endpoint splits. `GET` + `POST` twins of the same concept become one Codex field with an array input and GraphQL aliases. `getTokenPrices` takes at most 25 inputs per call; chunk larger batches. 10. For real-time data, use WebSocket subscriptions when the consumer is a long-lived client (dashboards, trading UIs) and webhooks when the consumer is a server endpoint (alerts, background workers, queues). Rebuild any reconnect logic: Codex needs no `op: "auth"` handshake or `op: "ping"` keepalive; auth travels in the connection init. 11. Preserve existing public function signatures, return shapes, and error semantics wherever possible. Internal helpers can be refactored freely. 12. Update tests as you change code. If a test relied on a Serialized response fixture, replace the fixture with a Codex equivalent rather than deleting the test. 13. When you hit a gap (contract audits, buy/sell tax fields, wallet transfers, ENS/name records, wash-trade flags, pool-level top traders), do not silently drop the feature. Leave the call site intact, add a `TODO(migration):` comment with a one-line note explaining what's missing and what provider could fill it, and list it in your final report. ## Serialized → Codex endpoint mapping Token snapshot, prices, metadata: - `GET|POST /v1/token` → `filterTokens(tokens: ["
:", ...])` for metadata + price + market cap + liquidity + launchpad + 24h stats in one call (up to 200 tokens); or `token` + `getDetailedTokenStats` for the full multi-window picture - `GET|POST /v1/token/price` → `getTokenPrices(inputs: [{ address, networkId }])` (max 25 per call); `marketCapUsd`/`liquidityUsd` come from `filterTokens` - `GET /v1/token/stats` → `getDetailedTokenStats(tokenAddress, networkId, durations: [...])` (windows: min5, hour1, hour4, hour12, day1, week1; Serialized's 6h has no twin, use hour4 or hour12) - `GET|POST /v1/token/metadata` → `token` / `tokens` (`info`, `socialLinks`) - `POST /v1/token/sparklines` → `tokenSparklines`; `POST /v1/pools/sparklines` → `getBars` on the pool at a coarse resolution - `GET /v1/prices/native` → `getTokenPrices` on each network's wrapped native token - `GET /v1/search` → `filterTokens(phrase: "...")` (`$SYMBOL` for exact symbol) Security and deployer: - `GET|POST /v1/token/security` → `token` (`mintable`, `freezable`, `isScam`, `creatorAddress`, `top10HoldersPercent`) + `filterTokens` (`holders`, `sniperHeldPercentage`, `bundlerHeldPercentage`, `insiderHeldPercentage`, `devHeldPercentage`, `potentialScam`) + `liquidityMetadataByToken` / `liquidityLocksV2` (locked and burned LP). `buyTaxBps`/`sellTaxBps`/`transferTaxBps`/`dexPaid` have no Codex field: add a `TODO(migration):` - `GET /v1/token/dev-tokens` → `filterTokens(filters: { creatorAddresses: [""] })` + `detailedWalletStats.wallet.tokensCreatedCount` / `tokensMigratedCount` (no deployer verdict) - `GET /v1/audit/contract`, `GET /v1/audit/chains` → not supported (contract source auditing); add a `TODO(migration):` Holders and traders: - `GET /v1/token/holders` → `holders(input: { tokenId })` for ranked balances; `filterTokenWallets(tokenIds: [...])` for per-holder PnL, volumes, average cost, and labels - `GET /v1/token/top-traders` → `tokenTopTraders(input: { tokenAddress, networkId, tradingPeriod })` (`DAY | WEEK | MONTH | YEAR`); for `all` or other sorts use `filterTokenWallets` with rankings - `GET /v1/pool/top-traders` → `filterTokenWallets` (token-level; no pool-level ranking) Pools and markets: - `GET /v1/token/pools` → `listPairsWithMetadataForToken` - `GET /v1/pool` → `pairMetadata(pairId: ":")` - `GET /v1/pool/data` → `getDetailedPairStats`; `POST /v1/pools/data` → `getDetailedPairsStats(input: [...])` - `GET|POST /v1/pool/ohlcv` → `getBars(symbol: ":", from, to, resolution, quoteToken)` - `GET /v1/pool/trades`, `POST /v1/pools/trades` → `getTokenEvents(query: { address: , networkId })`, batch pools with aliases - `GET /v1/meta/factories` → `filterLaunchpads` (launchpads) + `getExchanges` (DEXs) - `GET /v1/meta/chains` → `getNetworks` (+ `getNetworkStatus` for health) Charts: - `GET|POST /v1/token/ohlcv` → `getTokenBars(symbol: "
:", from, to, resolution, currencyCode)`. Interval map: `1s`→`1S`, `5s`→`5S`, `15s`→`15S`, `30s`→`30S`, `1m`→`1`, `5m`→`5`, `15m`→`15`, `30m`→`30`, `1h`→`60`, `4h`→`240`, `12h`→`720`, `1d`→`1D`, `1w`→`7D`. `3m`, `2h`, `6h`, `1M` have no twin: fetch the next finer resolution and roll up. `quote=usd` → `currencyCode: "USD"`, `quote=native` → `currencyCode: "TOKEN"`. `limit` + `endTime` becomes a `from`/`to` window in seconds. Trades: - `GET /v1/token/trades` → `getTokenEvents(query: { address: , networkId, eventType: Swap, timestamp: { from, to }, maker, ... }, limit, cursor)`. A token address resolves to its top pair; pass the pool address to scope to one pool. - `POST /v1/token/trades` (makers filter) → `getTokenEvents(query: { maker })` for one maker on a token, or `getTokenEventsForMaker` for one wallet across tokens - `GET /v1/pool/trades`, `POST /v1/pools/trades` → `getTokenEvents` with the pool address - `isWash` has no equivalent; `isSniper`/`isProTrader` map to maker labels on events and `filterTokenWallets` labels Wallets: - `GET|POST /v1/wallet/positions` → `balances(input: { walletAddress, networks: [Int!], removeScams })` for holdings; `filterTokenWallets(wallets: [...])` for per-token PnL and average cost. Native EVM balances require traces support. - `GET|POST /v1/wallet/closed-positions` → `filterTokenWallets(wallets: [...])` filtered to `tokenBalanceLive` of zero (`realizedProfitUsd1y`, `amountBoughtUsd1y`, `amountSoldUsd1y`, plus 1d / 1w / 30d variants) - `GET|POST /v1/wallet/trades` → `getTokenEventsForMaker(query: { maker, networkId, tokenAddress? }, limit, cursor)` - `GET|POST /v1/wallet/pnl` → `detailedWalletStats(input: { walletAddress, networkId })` (`statsDay1`, `statsWeek1`, `statsDay30`, `statsYear1`, each with `statsUsd { volumeUsd realizedProfitUsd realizedProfitPercentage }` and `statsNonCurrency { swaps wins losses }`; win rate is `wins / (wins + losses)`) + `walletChart` for the daily curve - `GET /v1/wallet/equity/history` → `walletChart` - `GET|POST /v1/wallet/profile` → `detailedWalletStats.wallet` (`displayName`, `avatarUrl`, `category`, `identityLabels`, social usernames, `ethosScore`, `tradeSourceIds`, `polymarket`); ENS/Basename/.sol records are not returned separately - `GET /v1/wallet/funding` → `detailedWalletStats.wallet.firstFunding` - `GET /v1/wallet/transfers` → not supported (swaps and lifecycle events only); add a `TODO(migration):` Discovery (all collapse into `filterTokens`): - `GET /v1/pulse?view=new` → `filterTokens(filters: { createdAt: { gte }, launchpadCompleted: false }, rankings: [{ attribute: createdAt, direction: DESC }])` - `GET /v1/pulse?view=bonding` → `filterTokens(filters: { launchpadGraduationPercent: { gt: 0, lt: 100 }, launchpadMigrated: false })` - `GET /v1/pulse?view=graduated` → `filterTokens(filters: { launchpadMigrated: true }, rankings: [{ attribute: launchpadMigratedAt, direction: DESC }])` - Pulse range params (`ageMin`, `liquidityMin`, `marketCapMin`, `bondingMin`, `volumeMin`, `txnsMin`, `feesMin`, `factories`) → the matching `filterTokens` range filters (`age`, `liquidity`, `marketCap`, `launchpadGraduationPercent`, `volume*`, `txnCount*`, `totalFees*`, `launchpadProtocol`); `socials` has no filter, read `token.socialLinks` on results - `GET /v1/screener` → `filterTokens` ranked by `trendingScore*`, `volume*`, `marketCap`, or `createdAt` (or `filterPairs` for pool rows) - For any live column or board, use `onFilterTokensUpdated` rather than polling Real-time (Serialized channel → Codex subscription): - `trades` → `onTokenEventsCreated` (token or pair) / `onEventsCreatedByMaker` (wallet) - `token-updates` → `onPricesUpdated` (price), `onDetailedTokenStatsUpdated` (windowed stats), `onLaunchpadTokenEvent` (bonding progress) - `pool-updates` → `onPairMetadataUpdated` / `onDetailedStatsUpdated` - polling candles → `onTokenBarsUpdated` / `onBarsUpdated`; polling Pulse/screener → `onFilterTokensUpdated`, `onLaunchpadTokenEventBatch`, `onLatestTokens`; polling holders → `onHoldersUpdated`; polling positions → `onBalanceUpdated` - Codex bills one request per delivered message; scope subscriptions to what the UI renders Utility: - `GET /v1/usage*` → Codex usage in the dashboard Gaps (flag, do not drop): - `/v1/audit/*`, tax and `dexPaid` fields: contract source auditing not supported; keep a security provider - `/v1/wallet/transfers`: pair with an RPC provider for raw transfers - ENS/Basename/.sol records, `isWash`, pool-level top traders and sparklines, deployer risk verdicts: partial or no equivalent, see mapping notes - Native EVM balances via `balances` are only available on networks with traces enabled When you need details on any Codex field, fetch the reference page at `https://docs.codex.io/api-reference/queries/` (or `subscriptions`, `mutations`) rather than guessing. Before migrating any real-time code, fetch `https://docs.codex.io/concepts/subscriptions` and `https://docs.codex.io/concepts/webhooks` so you pick the right delivery mechanism. ## Phase 3: Final report When the migration is done, produce a single report with: 1. Files changed, grouped by area (client/config, call sites, tests, docs). 2. Every `TODO(migration):` you added, with file path, line, and the reason. 3. New env vars and dependencies, with the line to add to `.env.example` and the package manager command to install. 4. Serialized integrations that were removed entirely, and what replaced them. 5. A short manual-verification checklist the human should run before merging (which features to click through, which endpoints to spot-check, which dashboards to load). Run the project's linter and test suite before declaring the migration complete. If tests fail, fix the underlying integration, do not weaken the test. ``` ## Getting help * Browse the [API Reference](/api-reference/introduction) for the full schema. * Skim the [Recipes](/recipes/discover-tokens) for end-to-end examples that solve specific product problems. * Ask in [our community](https://discord.com/invite/mFpUhT3vAq) if you hit a wall during migration.