TonAPI vs Toncenter vs Orbs: TON RPC providers compared

By 2026 the TON ecosystem has settled on three mainstream RPC providers carrying most production traffic: TonAPI by Tonkeeper (tonapi.io), Toncenter by TON Foundation (toncenter.com), and Orbs TON Access — the decentralised alternative from Orbs Network. Each has a distinct profile of strengths and weaknesses, and the choice is not “which is best” but “which is best for my workload”.

This guide compares them across eight practical criteria — rate-limits, free tier, latency, completeness, WebSocket support, cross-chain integration, documentation, and production pricing. For each provider you will see code for the same operation — getAccountBalance — so you can feel the API ergonomics in real calls. At the end, a decision tree that points to a provider based on the task.

TL;DR: for most apps in 2026 — TonAPI (rich indexer, WebSocket, best docs). For direct TVM access and runGetMethod — Toncenter v3. For a proxy layer with no single point of failure — Orbs TON Access. Production rigs typically run two providers in parallel for redundancy.

What is RPC in TON and why is it never “just one thing”

On EVM chains an RPC provider is a node that accepts JSON-RPC calls (eth_call, eth_getBalance) and returns node data. TON architecture is different: the actual node is a validator, reachable through the binary ADNL protocol rather than HTTP. Between you and a validator sit several layers:

• Lite-server — a node holding fresh blocks and answering ADNL queries. @ton/ton, tonweb, tonutils-go talk to lite-servers.
• HTTP gateway — Toncenter and Orbs TON Access. They accept HTTP, wrap calls into ADNL, ask a lite-server, return the response.
• Indexer — separate infrastructure that pre-parses every block into a relational database (Postgres/ClickHouse) and answers richer queries: “all jetton transfers for this address last year”, “NFT ownership history”, “top 100 wallets by balance”. TonAPI and Toncenter v3 are indexers.

Hence: TonAPI and Toncenter are HTTP on top of an indexer; Orbs TON Access is HTTP proxy to lite-servers without an indexer. That single architectural fact drives most of the differences that follow.

Comparison table — TonAPI vs Toncenter vs Orbs

TonAPI: the Tonkeeper indexer

TonAPI is an HTTP indexer from the Tonkeeper team. Launched in 2022, by 2026 it is the most mature product in the TON ecosystem by features and documentation. Powers Tonkeeper itself, Tonviewer, Telegram mini-apps, most DEXes, NFT marketplaces and DeFi protocols.

Strengths:

• High-level endpoints. “All jetton balances for this address” is one HTTP call. On Toncenter the same takes getAccountTokens plus manual parsing.
• WebSocket address subscription. Push notifications for every incoming or outgoing transaction in real time, no polling needed.
• NFT and jetton metadata baked in. TonAPI parses and caches off-chain metadata (IPFS, HTTP) and returns it already decoded.
• OpenAPI spec. Auto-generate clients in TypeScript, Python, Go, Rust, Java.

Weaknesses:

• Low keyless rate-limit — only 1 req/sec. With a free key, 5 req/sec, still tight for serious load.
• Pricier paid tier than Toncenter for equivalent throughput (TonAPI Pro from $30/mo at 100 req/sec; Toncenter ~$39/mo).
• Tied to Tonkeeper. If Tonkeeper’s infra goes down, TonAPI goes with it. In practice uptime is >99.9%, but the single point of failure exists.

Code: get TON balance and jetton balances via TonAPI.

const TONAPI_BASE = "https://tonapi.io/v2";
const address = "EQAbc...";

// 1. TON balance
const account = await fetch(`${TONAPI_BASE}/accounts/${address}`)
  .then((r) => r.json());
console.log("TON balance:", Number(account.balance) / 1e9);

// 2. All jetton balances — single request
const jettons = await fetch(`${TONAPI_BASE}/accounts/${address}/jettons`)
  .then((r) => r.json());
for (const j of jettons.balances) {
  const sym = j.jetton.symbol;
  const dec = j.jetton.decimals;
  const amt = Number(j.balance) / Math.pow(10, dec);
  console.log(`${sym}: ${amt}`);
}

Notice the jetton metadata (symbol, decimals, name, image) is already decoded and returned inline — you do not query the jetton master separately. That is the value an indexer adds.

Toncenter: the canonical gateway from TON Foundation

Toncenter is the official HTTP gateway maintained by TON Foundation. Exists in two generations: v2 (legacy, direct lite-server proxy) and v3 (current, includes the indexer). Most 2026 code is on v3, but v2 is still used for low-level calls like sendBoc and raw runGetMethod.

Strengths:

• Canonical. Toncenter is the reference HTTP gateway, and integration examples in the official TON docs target it.
• Direct TVM access via runGetMethod. Lets you call any contract getter and receive a raw TVM stack response.
• Keyed free tier at 10 req/sec — twice TonAPI’s, enough for many mid-size projects to never pay.
• SSE subscriptions. Server-Sent Events for new transactions per address. Less rich than TonAPI WebSocket, but simpler to operate (HTTP/2 stream).

Weaknesses:

• API is less “human”. Getting jetton balances requires getTokenData per master, then your own decoding.
• runGetMethod over JSON can lose precision. Big integers come back as strings, and naive client deserialisation produces bugs — especially in JavaScript.
• US-based servers. Latency from Asia and Eastern Europe is higher than TonAPI’s EU-edge.

Code: same task — TON balance and jetton balances — via Toncenter v3.

const TONCENTER_BASE = "https://toncenter.com/api/v3";
const API_KEY = process.env.TONCENTER_API_KEY;
const address = "EQAbc...";

// 1. TON balance
const acc = await fetch(
  `${TONCENTER_BASE}/account?address=${address}`,
  { headers: { "X-API-Key": API_KEY ?? "" } }
).then((r) => r.json());
console.log("TON balance:", Number(acc.balance) / 1e9);

// 2. Jetton balances — separate endpoint
const jettons = await fetch(
  `${TONCENTER_BASE}/jetton/wallets?owner_address=${address}`,
  { headers: { "X-API-Key": API_KEY ?? "" } }
).then((r) => r.json());

for (const w of jettons.jetton_wallets) {
  // Master metadata must be fetched separately
  const master = await fetch(
    `${TONCENTER_BASE}/jetton/masters?address=${w.jetton}`,
    { headers: { "X-API-Key": API_KEY ?? "" } }
  ).then((r) => r.json());
  const m = master.jetton_masters[0];
  const dec = m.jetton_content?.data?.decimals ?? 9;
  const amt = Number(w.balance) / Math.pow(10, Number(dec));
  console.log(`${m.jetton_content?.data?.symbol}: ${amt}`);
}

Two layers of requests where TonAPI had one. The upside: you get explicit control over what data flows where, with no implicit decoding from the indexer.

Orbs TON Access: the decentralised proxy

Orbs TON Access is an initiative from Orbs Network (an L2 project on Ethereum) that runs ~25 geo-distributed nodes serving TON RPC traffic without a centralised gateway. It is not an indexer — Orbs does not parse the chain into a relational DB. It is a proxy: your HTTP request hits the ton-access endpoint, routes to one of the nodes, the node calls a lite-server over ADNL, returns the result.

Strengths:

• Free and keyless. No registration — paste the endpoint URL and you are running. ~50 req/sec per client fingerprint covers almost all use cases.
• Resilience. Requests round-robin across Orbs nodes; if one is down, the next call hits another. No single point of failure like tonapi.io.
• No server state required. Safe to call directly from the browser (WebApp, mini-app) — no API key to hide in client-side code.
• @ton/ton integration. A ready wrapper @orbs-network/ton-access slots into the popular TON SDK.

Weaknesses:

• No indexer. “All jetton balances for this address” requires manual walking via lite-server (find all jetton wallets first, then query each), which is slow and hits rate limits fast.
• Limited transaction history. Lite-servers only retain a recent block window; a transaction from two months back may not be reachable.
• No WebSocket or SSE. Real-time monitoring requires polling.
• Minimal documentation. No proper OpenAPI, mostly README on GitHub.

Code: TON balance via Orbs + @ton/ton SDK.

import { getHttpEndpoint } from "@orbs-network/ton-access";
import { TonClient, Address } from "@ton/ton";

const endpoint = await getHttpEndpoint();
const client = new TonClient({ endpoint });

const address = Address.parse("EQAbc...");
const balance = await client.getBalance(address);
console.log("TON balance:", Number(balance) / 1e9);

// Jetton balances need manual walking via runGetMethod
// — Orbs has no indexer, so the code is much longer.
// For production code, use TonAPI or Toncenter for that task.

Orbs fits the role of second provider for redundancy — the primary path goes through TonAPI, with a fallback flip to Orbs when TonAPI returns 5xx. This removes single-endpoint dependence without needing to run your own lite-server.

Per-task comparison

Task 1: show TON balance and a jetton portfolio

Winner: TonAPI. This is its primary use case.

Task 2: call a custom contract getter

// Through Toncenter v2
const res = await fetch(`https://toncenter.com/api/v2/runGetMethod`, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    address: "EQAbc...",
    method: "get_total_supply",
    stack: [],
  }),
}).then((r) => r.json());
console.log("Total supply:", res.result.stack[0]);

All three support runGetMethod, but Toncenter is the most canonical implementation and most TON Foundation tutorials target it.

Winner: Toncenter v2/v3.

Task 3: real-time monitoring of incoming payments in a Telegram bot

// TonAPI WebSocket — subscribe to address
const ws = new WebSocket("wss://tonapi.io/v2/websocket");

ws.onopen = () => {
  ws.send(
    JSON.stringify({
      id: 1,
      jsonrpc: "2.0",
      method: "subscribe_account",
      params: ["EQAbc..."],
    })
  );
};

ws.onmessage = (event) => {
  const msg = JSON.parse(event.data);
  // Get notifications for every transaction at the address
  if (msg.method === "account_transaction") {
    handleIncomingPayment(msg.params);
  }
};

Toncenter SSE gives a similar result, but with a thinner event stream — TonAPI lets you subscribe separately to jetton transfers, NFTs and mempool.

Winner: TonAPI.

Task 4: scan a year of transactions for analytics

Lite-servers (and thus Orbs) cannot do this — no archive. You need an indexer.

Winner: Toncenter v3 on the free tier, TonAPI on the paid tier (richer API).

Task 5: dApp running entirely client-side with no backend

Hiding an API key in client-side code is a bad idea — any user can lift it and burn your quota. Orbs is perfect here since it requires no key.

Winner: Orbs TON Access.

Decision tree: which provider for which task

1. I am building a Telegram bot that accepts payments. TonAPI (WebSocket subscription on the shop address).
2. I am building a DEX aggregator or NFT marketplace. TonAPI primary plus Toncenter fallback. Pro plan on both.
3. I am building a Telegram mini-app with no backend. Orbs TON Access (no key, safe client-side).
4. I need raw TVM getter access and sendBoc. Toncenter v2/v3.
5. I want maximum redundancy and I am ready to write fallback logic. TonAPI primary plus Orbs secondary.
6. I am building an analytics dashboard with a year of history. Toncenter v3 (rich SQL-like filters) or TonAPI Pro.
7. I want self-hosted RPC. Toncenter — open source, self-hostable. TonAPI has a community edition. Orbs only runs as a network.
8. I am developing for Russian users and worried about throttling. TonAPI (CF edge inside RU is fast) plus Orbs (decentralisation reduces total-block risk).

Paid plans: what does the money buy

All three offer commercial plans (except Orbs, which sells self-hosted or enterprise contracts instead):

• TonAPI Pro — from $30/mo for 100 req/sec, $200/mo for 500 req/sec, custom for archive depth. Includes SLA and priority support.
• Toncenter Pro — from $39/mo for 100 req/sec, custom above that. SLA on request.
• Orbs Enterprise — no public pricing, contact Orbs Network for a private gateway deployment.

If you have a mainstream dApp with 1000+ DAU peaking at 10 req/sec, the free tier of any of the three will not cut it. The most economical option is TonAPI Pro at $30/mo — bundled with WebSocket, it covers 80% of production dApp needs out of the box.

What does not count as an RPC provider

A few names that come up in Q&A but should not be your primary RPC:

• Tonscan API — explorer API, not a general-purpose RPC. Low limits, not for production.
• TonScan WebSocket — deprecated, superseded by TonAPI.
• dTon.io API — was an analytics service, no public support by 2026.
• Local lite-server via ton-http-api — a real option for self-hosting, but needs ~500 GB SSD for archive and active maintenance.

Wrap-up

The 2026 TON RPC stack rests on three providers with three different philosophies. TonAPI is optimised for convenience and data richness, Toncenter for canonical TVM access, Orbs TON Access for keyless resilience.

Serious production almost always runs two providers at once — primary for speed and features, secondary for fallback on 5xx or throttling. That removes the risk of a total outage when one gateway has a bad day. A local lite-server is the third defensive layer if you already have infra people; a solo developer can ship safely on the TonAPI plus Orbs combination.

The main advice: do not pick by popularity. Open your code, look at the 5–10 typical RPC calls you make, estimate how each weighs on the three providers — and choose the one where your dApp code is shorter and the response arrives in the shape you need. The cost of an API key is small over months; the cost of hand-rolling raw lite-server responses and running your own indexer is not.