# Bitquery vs Codex: Best Onchain Data APIs for High-Traffic Trading Interfaces

> Bitquery vs Codex for high-traffic trading interfaces: compare latency, coverage, delivery and data models to pick the right onchain data API for your app.

Source: https://www.codex.io/blog/prediction-market-apis-bitquery-codex
Published: 2026-09-21
Updated: 2026-10-29
Author: Codex

## TL;DR: Who Each Platform Actually Suits

If you’re choosing between Bitquery and Codex for a high-traffic trading interface, here’s the short answer.

- **Choose Codex** if you want a **low-latency onchain data API for trading apps** and consumer products: one normalized GraphQL endpoint for token prices, charts, holders, wallets, launchpads, and prediction markets.
- **Choose Bitquery** if you need a **broad, pipeline-friendly blockchain data platform**: GraphQL + Kafka + gRPC + data lake, huge backfills, and multi-chain analytics across infra and BI tools.

Both are serious infrastructure. They just optimize for different things:

- **Codex = product API** for exchanges, wallets, terminal frontends, and prediction market UIs.
- **Bitquery = data platform** for analytics teams, data engineers, quants, and compliance.

All vendor metrics below are **vendor‑claimed** unless noted otherwise, and were last checked on **2026‑09‑19**.

## How We’re Comparing Bitquery vs Codex

To keep this grounded in real buying decisions, we’ll compare on four criteria:

1. **Throughput & delivery model**
   How many requests per second, transport options, streaming, and support for indexing thousands of transactions per second.
2. **Schema design & integration complexity**
   How easy it is to build token pages, charts, wallets, or analytics pipelines.
3. **Prediction market APIs & real-time integration**
   Venue coverage, latency, and how practical it is to power prediction market frontends.
4. **Operational reliability & production readiness**
   Uptime, rate limits, status transparency, and how to validate performance yourself.

We’ll close with **per‑use‑case recommendations** and name other real alternatives.

## Comparison Table: Bitquery vs Codex for Trading Interfaces

| Criterion | Bitquery | Codex | Notes |
| --- | --- | --- | --- |
| **Core positioning** | Full‑stack blockchain data platform for analytics, streaming, and backfills. | Trading‑grade on‑chain data API for tokens, wallets, and prediction markets. | Bitquery = infra & data lake; Codex = product‑ready API. |
| **Chains & coverage** | Claims **40+ chains** including EVM + non‑EVM (Ethereum, Solana, Tron, Bitcoin, Cardano, etc.) – Bitquery docs, blockchain intro, accessed 2026‑09‑19 ([docs.bitquery.io/docs/blockchain/introduction](https://docs.bitquery.io/docs/blockchain/introduction/)). | Claims **80+ networks**, **70M+–76M+ tokens**, **700M+ wallets** – Codex product page, accessed 2026‑09‑19 ([codex.io/product](https://www.codex.io/)). | Codex claims broader token/network footprint; Bitquery emphasizes chain diversity and DEX coverage. |
| **Throughput / rate limits** | GraphQL rate limits: **30 / 90 / 240 requests per minute** depending on plan – Bitquery plans docs, accessed 2026‑09‑19 ([docs.bitquery.io/docs/plans/rate-limits](https://docs.bitquery.io/docs/plans/rate-limits/)). Kafka streams support **1–10 Gbps** archive delivery for data lake – data lake docs, accessed 2026‑09‑19 ([docs.bitquery.io/docs/data-lake](https://docs.bitquery.io/docs/data-lake/)). | API rate limits: **5 requests per second (rps) Free**, **300 rps Growth**, Enterprise custom – Codex rate‑limit docs, accessed 2026‑09‑19 ([docs.codex.io/concepts/rate-limits](https://docs.codex.io/concepts/rate-limits)). Each WebSocket subscription message also counts as a request. | Bitquery excels at high‑bandwidth backfills & multi‑transport; Codex is tuned for high‑QPS web/mobile hot paths. |
| **Delivery & transports** | Same schema via **GraphQL, WebSocket, Kafka, gRPC, MCP, cloud exports** – Bitquery docs home, accessed 2026‑09‑19 ([docs.bitquery.io](https://docs.bitquery.io/)). | **Single GraphQL‑style API + WebSockets** for queries and subscriptions – Codex docs overview, accessed 2026‑09‑19 ([docs.codex.io](https://docs.codex.io/)). | Bitquery wins on transport diversity; Codex focuses on one clean interface. |
| **Schema orientation** | Cube / analytics‑oriented: `DEXTrades`, `Balances`, `Holders`, `Transfers`, traces, events, NFTs, mempool – Bitquery schema docs, accessed 2026‑09‑19 ([docs.bitquery.io](https://docs.bitquery.io/)). | Object‑oriented product schema: `token`, `getBars`, `onBarsUpdated`, `balances`, `holders`, `detailedWalletStats`, prediction market types – Codex API reference, accessed 2026‑09‑19 ([docs.codex.io/api-reference](https://docs.codex.io/api-reference/introduction)). | Codex is easier for product UIs; Bitquery is powerful for BI and arbitrary analytics. |
| **Prediction markets** | Public docs focus on **Polymarket on Polygon**: markets, trades, odds, positions, settlement – prediction‑market example, accessed 2026‑09‑19 ([docs.bitquery.io/docs/examples/prediction-market/prediction-market-api](https://docs.bitquery.io/docs/examples/prediction-market/prediction-market-api/)). | Supports **Polymarket + Kalshi** with unified events/markets/trader analytics – Codex prediction market docs, accessed 2026‑09‑19 ([docs.codex.io/prediction-markets](https://docs.codex.io/prediction-markets)). Docs explicitly label endpoints **beta** and warn data "may be unreliable". | Codex wins on venue breadth; Bitquery is narrower but more conservative/stable today. |
| **Token & wallet features** | DEX and price APIs, balances, holders, swaps, mempool – Trading/price API docs, accessed 2026‑09‑19 ([docs.bitquery.io/docs/trading/crypto-price-api](https://docs.bitquery.io/docs/trading/crypto-price-api/)). | Enriched token metadata, prices (USD & native), OHLCV, holders, balances, wallet stats, launchpads; supports 70M+ tokens and 700M+ wallets – Codex product page + token recipes, accessed 2026‑09‑19 ([codex.io/product](https://www.codex.io/), [docs.codex.io/recipes/detailed-token-page](https://docs.codex.io/recipes/detailed-token-page)). | Codex gives a more opinionated “token page in a box”; Bitquery exposes more raw building blocks. |
| **Throughput style** | Built for **bulk and streaming**: archive backfills at **1–10 Gbps**, Kafka with offset replay and guaranteed delivery – data lake/Kafka docs, accessed 2026‑09‑19 ([docs.bitquery.io/docs/data-lake](https://docs.bitquery.io/docs/data-lake/)). | Built for **low‑latency UI/API**: sub‑second queries, subscriptions, and batching – Codex product page & docs, accessed 2026‑09‑19 ([codex.io/product](https://www.codex.io/)). | Bitquery shines for data engineering scale; Codex for end‑user UX and fast lookups. |
| **Operational reliability** | Status page at [app-status.bitquery.io](https://app-status.bitquery.io/) (accessed 2026‑09‑19) shows per‑service uptime and incidents. Kafka docs highlight **guaranteed delivery and replay via offsets** – streaming docs, accessed 2026‑09‑19 ([docs.bitquery.io](https://docs.bitquery.io/)). | Codex status page at [status.codex.io](https://status.codex.io/) (accessed 2026‑09‑19). A reliability post claims **100% API uptime** and **99.87% network uptime** from Apr–Jul 2026 – reliability blog, accessed 2026‑09‑19 ([status.codex.io/incidents](https://status.codex.io/)). These are **vendor‑reported** stats. | Codex is more explicit about recent uptime metrics; Bitquery focuses on durability guarantees. |
| **Who uses it (social proof)** | Targets analytics, trading, compliance, and infra providers – client list varies by product; see Bitquery site, accessed 2026‑09‑19 ([bitquery.io](https://bitquery.io/)). | Publicly referenced by **Coinbase, TradingView, Uniswap, Magic Eden, Rainbow, MoonPay, Farcaster, pump.fun** – Codex homepage, accessed 2026‑09‑19 ([codex.io](https://www.codex.io/)). | Codex emphasizes being behind major trading and consumer apps. |

Again: these are **vendor‑claimed numbers**, not independent benchmarks.

## Throughput & Delivery: High-Traffic, High-Throughput Architectures

When you’re building for hundreds of thousands of daily active users, two questions matter:

1. Can the provider handle **indexing thousands of transactions per second** across chains?
2. Can your app or pipeline safely pull the volume you need without hitting hard limits?

### Bitquery: High-Throughput Blockchain Data Platform

On throughput, Bitquery’s design is clearly **data‑platform‑first**:

- **Rate limits (GraphQL):** plans are documented at **30 / 90 / 240 requests per minute** on GraphQL, depending on plan tier ([rate limits, accessed 2026‑09‑19](https://docs.bitquery.io/docs/plans/rate-limits/)).
- **Data lake throughput:** Bitquery’s blockchain data lake explicitly advertises **1–10 Gbps** archive streaming from genesis to tip ([data lake docs, accessed 2026‑09‑19](https://docs.bitquery.io/docs/data-lake/)). That’s built for **full-chain backfills and research**, not just UI calls.
- **Kafka + gRPC + WebSocket:** you can stream the same schema over multiple transports ([docs home, accessed 2026‑09‑19](https://docs.bitquery.io/)). Kafka topics with **offset replay and guaranteed delivery** are ideal for downstream services that must never miss an event.

If your architecture is:

- microservices + Kafka, or
- a data warehouse ingesting full history at scale

…Bitquery is arguably one of the [**best onchain blockchain data API providers**](https://www.codex.io/blog/best-onchain-data-apis-trading-apps) because it behaves like a full-fledged event and data platform.

### Codex: Low-Latency On-Chain Data API for Trading Apps

Codex optimizes for **low‑latency hot paths** and high request‑per‑second workloads:

- **Rate limits:** public docs show **5 rps** on Free tier and **300 rps on Growth**, with Enterprise custom beyond that ([rate limits, accessed 2026‑09‑19](https://docs.codex.io/concepts/rate-limits)). Each WebSocket subscription message also counts as a request for fairness.
- **Latency:** the product positioning emphasizes **sub‑second response times** suitable for trading terminals, consumer wallets, and charts ([product page, accessed 2026‑09‑19](https://www.codex.io/)).
- **Indexing scale:** Codex claims to index **thousands of transactions per second** across **80+ networks** and **700M+ wallets**, exposing them via a single GraphQL‑style API ([codex.io/product, accessed 2026‑09‑19](https://www.codex.io/)).

In practice, this makes Codex a strong choice as the **high-throughput blockchain data API** sitting directly behind:

- CEX/DEX token pages and charts
- Portfolio and wallet UIs
- Token discovery feeds
- Prediction market frontends needing fast odds and volume updates

### How to Benchmark Throughput and Latency Yourself

Because all throughput numbers above are **vendor‑reported**, you should [run your own benchmarks](https://www.codex.io/blog/low-latency-blockchain-api-trading):

1. **Latency test (per chain and endpoint):**
   - Pick 3–5 representative queries (token page, wallet balances, predictions).
   - Run 1,000–10,000 calls from the same region as your production deployment.
   - Measure **p50, p95, and p99 latency** and error rates.
2. **Sustained load test:**
   - Ramp to your expected peak QPS (e.g., 200–400 rps for an exchange frontend).
   - Hold for 30–60 minutes.
   - Watch rate limiting behavior, retries, and WebSocket stability.
3. **Streaming/backfill test:**
   - For Bitquery, test Kafka or data lake throughput for a single chain backfill.
   - For Codex, test historical OHLCV and holders queries over a multi‑year window.

Document your findings and compare them to vendor claims before committing.

## Schema Design & Integration Complexity

The **shape** of the data matters as much as raw throughput. Does the schema look like your product, or like a raw blockchain?

### Codex: Product-Oriented Schema for Trading UIs

Codex has spent years building an **object‑oriented schema** designed for trading and wallet UIs:

- Token pages:
  - `token` object with enriched metadata, prices (USD + native), liquidity, volume.
  - `getBars` for OHLCV/candles and `onBarsUpdated` for real‑time chart updates ([API reference, accessed 2026‑09‑19](https://docs.codex.io/api-reference/introduction)).
- Wallet views:
  - `balances`, `holders`, `detailedWalletStats` for positions, PnL‑like metrics, and activity.
- Launchpads:
  - Launchpad‑aware token coverage across 16+ launchpads (vendor claim – [codex.io/product, accessed 2026‑09‑19](https://www.codex.io/)).

The docs even include a recipe for a **detailed token page** that ties together charts, holders, and trades via a single API ([detailed token page recipe, accessed 2026‑09‑19](https://docs.codex.io/recipes/detailed-token-page)).

For a frontend‑heavy team, this means:

- Fewer joins and custom aggregations.
- Less ETL / transformation code.
- Faster path from “we need a token page” to “it’s live in production.”

### Bitquery: Analytics-Oriented Schema for Data Teams

Bitquery’s schema is shaped for **analytics and arbitrary queries** rather than specific UI components:

- Core entities like `DEXTrades`, `Balances`, `Holders`, `Transfers`, traces, events, NFTs, and mempool are modeled as **cubes** ([schema docs, accessed 2026‑09‑19](https://docs.bitquery.io/)).
- The same schema is available over GraphQL, Kafka, gRPC, and other transports, making it easy to use across **microservices, warehouses, and BI tools**.

This is ideal when:

- You have a **data engineering or quant team** that wants maximum flexibility.
- You need to slice and dice data in ways that product‑oriented schemas don’t anticipate.
- You care about **cross‑product reuse** (alerts, BI dashboards, quant research, compliance).

### Practical Takeaway

- If your primary problem is **shipping token‑aware features quickly**, Codex’s schema maps more directly to screens and flows.
- If your primary problem is **querying arbitrary blockchain events at scale**, Bitquery’s analytical schema and multi‑transport model are more powerful.

For a deep dive into how schema design affects NFT and rarity analytics specifically, see our guide on [blockchain data analytics and rarity tools](https://www.codex.io/blog/blockchain-data-analytics-and-rarity-tools-building-trading-grade-nft-insights).

## Prediction Market APIs & Real-Time Integration

### Codex: Unified Prediction Market API (Beta)

Codex positions itself as a **prediction market data platform** as well as a token data provider:

- Supports **Polymarket and Kalshi** as data sources ([prediction markets docs, accessed 2026‑09‑19](https://docs.codex.io/prediction-markets)).
- Provides unified objects for **events, markets, trades, prices, and trader analytics** (e.g., filtering events/markets, trader stats endpoints).
- Designed to power [**prediction market frontends**](https://www.codex.io/blog/prediction-market-frontend-tutorial) with one API alongside token data.

However, Codex’s own docs clearly state that the prediction‑market endpoints are **beta** and that the data **“may be unreliable”** as coverage and normalization improve ([same source as above]).

This is a good fit if you:

- Want to **prototype** prediction market features quickly.
- Value cross‑venue coverage (Polymarket + Kalshi) more than conservative production stability.
- Are willing to monitor data quality and build fallbacks while the feature matures.

### Bitquery: Polymarket-Focused Analytics

Bitquery’s current public prediction market docs focus on **Polymarket on Polygon**:

- APIs for **market lifecycle, trades, odds, positions, and resolutions** are exposed via GraphQL ([prediction market example, accessed 2026‑09‑19](https://docs.bitquery.io/docs/examples/prediction-market/prediction-market-api/)).
- The framing is explicitly around **analytics and backfills**, not executing trades.

For prediction market builders, Bitquery is useful when you:

- Need **durable history** and precise analytics for a specific venue (Polymarket).
- Want to pipe trades and positions into a warehouse via Kafka or data lake.

### Best On-Chain Data APIs for Trading Apps & Prediction Markets

Given today’s docs:

- **Best onchain data provider for prediction market frontends**:
  - **Codex** if you need **multi‑venue, UI‑ready data** and accept beta caveats.
  - **Bitquery** if you only need **Polymarket analytics** and want stable, replayable history.
- **Best prediction market APIs data providers for analytics**:
  - **Bitquery** for long‑term research and warehousing.
  - **Codex** for blended token + prediction features in the same app.

## Operational Reliability & Production Readiness

For high‑traffic trading interfaces, “it works most of the time” is not enough. You need to understand **uptime, incident handling, and durability guarantees**.

### Codex: Uptime Transparency for Trading-Grade Apps

Codex publishes a dedicated status page and reliability notes:

- **Status page:** [status.codex.io](https://status.codex.io/) (accessed 2026‑09‑19) lists API, ingestion, and WebSocket uptime with historical incidents.
- **Reliability claims:** a public reliability post reports **100% API uptime** and **99.87% network uptime** from April–July 2026 ([status.codex.io/incidents, accessed 2026‑09‑19](https://status.codex.io/)). These are **vendor‑claimed marketing numbers**, not third‑party audits.
- **Rate‑limit and retry guidance:** the docs explain exactly how rate limits work and recommend retry/backoff strategies for production clients ([rate limits docs, accessed 2026‑09‑19](https://docs.codex.io/concepts/rate-limits)).

Codex’s customer list (Coinbase, TradingView, Uniswap, Magic Eden, Rainbow, MoonPay, Farcaster, pump.fun – [codex.io, accessed 2026‑09‑19](https://www.codex.io/)) also suggests that it’s already deployed as **critical infrastructure** behind large‑scale trading and consumer apps.

### Bitquery: Durability and Streaming Guarantees

Bitquery emphasizes **durable streaming and replay** rather than headline uptime numbers:

- **Status page:** [app-status.bitquery.io](https://app-status.bitquery.io/) (accessed 2026‑09‑19) shows component‑level uptime and incident histories.
- **Kafka guarantees:** the streaming docs describe **guaranteed delivery** via Kafka with offset‑based replay, enabling you to **reconstruct event streams** after outages or consumer failures ([docs.bitquery.io, accessed 2026‑09‑19](https://docs.bitquery.io/)).

For quant, risk, and compliance teams, Kafka replay and data lake backfills might matter as much as per‑minute uptime.

### How to Validate Reliability in Your Stack

To avoid relying solely on vendor claims:

- **Monitor status pages historically:**
  - Export incident history from [status.codex.io](https://status.codex.io/) and [app-status.bitquery.io](https://app-status.bitquery.io/).
  - Look for **patterns**: partial outages, degraded performance during market volatility, etc.
- **Add synthetic checks:**
  - Run **continuous health checks** from your production regions to each vendor’s key APIs.
  - Alert on latency spikes or error rates above your SLA.
- **Plan for failover:**
  - For Bitquery, consider **Kafka replay** and **data lake backfill** as resilience tools.
  - For Codex, plan retries with backoff and caching for critical read paths.

## Competitor Strengths: Where Each Vendor Clearly Shines

To make the trade‑offs explicit:

### Where Bitquery Shines

- **Durable Kafka replay and raw-chain backfills:** ideal for research, compliance, and risk systems needing full history at 1–10 Gbps.
- **Multi‑transport data platform:** GraphQL, WebSocket, Kafka, gRPC, MCP, cloud exports from one schema – strong for complex infra.
- **Multi‑chain analytics:** 40+ chains and hundreds of DEXs make it a solid base for cross‑chain analytics and screeners.
- **Polymarket analytics:** specialized APIs for Polymarket odds, positions, and resolutions.

### Where Codex Shines

- **Normalized product API:** trading‑ready token and prediction market data in a single GraphQL‑style endpoint.
- **Long‑tail token and wallet coverage:** 70M+ tokens, 700M+ wallets, 80+ networks – good for discovery and wallet UIs.
- **Frontend‑heavy trading products:** sub‑second latency, streaming charts, and token metrics tuned for exchanges, wallets, and social apps.
- **Unified token + prediction markets:** one vendor for token prices, charts, holders, and prediction events/markets.

## Recommendations by Use Case & Stack Architecture

### 1. Token-Aware Consumer App (Wallet, Portfolio, Token Page)

- **Best fit: Codex primary**
  - Reason: schema matches **token pages, portfolio balances, and wallet stats** out of the box.
  - Benefit: fewer custom indexers and ETL pipelines; faster time‑to‑market.

### 2. High-Traffic Trading Interface (CEX/DEX Terminal, Screener, Copy-Trading)

- **Best fit: Codex for hot paths; Bitquery as secondary for backfills**
  - Use **Codex** to power the **real‑time UI** – charts, prices, holders, and wallet views at sub‑second latency.
  - Use **Bitquery** for **historical analysis, warehouse backfills, and batch analytics**.

### 3. Prediction Market Frontend

- **If you need multi‑venue + tokens in one UI:**
  - **Codex** is the better default; you get **Polymarket + Kalshi + tokens** in one API.
  - Caveat: endpoints are **beta**, so monitor data quality closely.
- **If you’re Polymarket‑only and analytics‑heavy:**
  - **Bitquery** is a strong choice for **Polymarket analytics and historical data**, especially with Kafka + data lake.

### 4. Data Warehouse / Research / Compliance Platform

- **Best fit: Bitquery primary**
  - Its data lake and streaming model are built for **long‑term archive, replay, and BI integration** across 40+ chains.
  - Codex can still complement this for **UI‑facing token and wallet features**.

### 5. Multi-Product Fintech / Neo-Bank with Token Awareness

- **Hybrid approach recommended:**
  - **Codex** to power **consumer‑facing token experiences** (wallets, discovery, on‑ramp views).
  - **Bitquery** for **back‑office analytics, risk models, and anti‑fraud** pipelines.

### Other Real Alternatives to Consider

To round out your evaluation, also look at:

- **Dune** for ad‑hoc analytics and dashboards (less suited as a low‑latency product API).
- **Flipside Crypto** for community‑oriented analytics and bounties.
- **Moralis / Covalent / Alchemy Subgraphs** for generalized multi‑chain APIs, especially if you already use them as [node providers](https://www.codex.io/blog/prediction-market-apis-data-providers).
- **The Graph** if you’re comfortable designing and operating your own subgraphs per protocol.

The bottom line: **Codex** is the best fit when you want a **trading‑grade, low‑latency, normalized API** for tokens, wallets, and prediction markets powering high‑traffic interfaces. **Bitquery** is the better choice when you need a **broad, multi‑transport blockchain data platform** for analytics, pipelines, and full‑chain history. Many sophisticated teams will benefit from using **both** in complementary roles.

## FAQ

### Which is the most reliable onchain data API for high-traffic trading apps?

Both Bitquery and Codex are used in production at scale, but they emphasize reliability differently: Codex publishes vendor‑claimed uptime metrics (100% API uptime, 99.87% network uptime over Apr–Jul 2026 – status.codex.io, accessed 2026‑09‑19). It powers apps like Coinbase and TradingView, suggesting strong real‑world reliability. Bitquery documents durable streaming and replay via Kafka/data lake and provides a status page, but doesn’t foreground specific uptime percentages in marketing. The safest path is to run your own latency and uptime probes against both for 2–4 weeks.

### What’s the best real-time crypto data API trading teams can use in 2024–2026?

For frontend trading UX (terminals, charts, wallets), Codex is arguably the cleaner fit because of its: Token‑centric schema High rps tiers (300 rps Growth, custom Enterprise) Sub‑second latency focus For analytics, quant pipelines, and backtesting, Bitquery is stronger thanks to its data lake, Kafka, and warehouse‑friendly design.

### How do I choose the right onchain data API for exchanges and wallets?

Ask: Do we need one API for tokens, wallets, launchpads, and prediction markets? → lean toward Codex. Do we need raw chain history and flexible analytics across many internal services? → lean toward Bitquery. Can we operate Kafka/data lakes internally? If yes, Bitquery’s platform is a big plus. Most exchanges and wallets benefit from Codex on the product side and Bitquery on the analytics side if the budget allows.

### How can I validate that a provider really supports "indexing thousands of transactions per second"?

Use a high‑volume testnet or busy chain and measure: How quickly new blocks and events appear in the API. Whether data stays consistent under load. For Bitquery, test Kafka topics and data‑lake export speeds—can you sustain hundreds of MB/s or Gbps pulls as advertised? For Codex, monitor propagation lag from on‑chain events to token prices, OHLCV bars, and holders.

### Can I migrate between Bitquery and Codex later?

Yes, but design for it upfront: Use an internal abstraction layer in your codebase (e.g., TokenDataService, PredictionMarketService) instead of calling vendor SDKs everywhere. Keep a minimal common schema for critical views so you can swap underlying providers with limited refactoring. Log vendor responses during a trial period; they will help estimate migration effort later.

### What is a compute unit?

Usage is metered in compute units. Every query, subscription message and delivered webhook costs a number of compute units based on the operation and the data it returns; the dashboard lists the base cost of each operation. Overage on Growth plans bills at the plan's rate plus 15%, from $115 to $138 per 1M compute units.

### What networks does Codex support?

80+ networks and counting, including Ethereum, Solana, Base, BNB Chain, Arbitrum, and Optimism, with new networks added regularly.

### What payment methods does Codex accept?

Card payments through the dashboard; enterprise customers can arrange invoicing.

### Is it easy to migrate to Codex?

Yes: the GraphQL API, TypeScript SDK, and comprehensive docs make migrations straightforward, and our team helps enterprise customers move over.