TonAPI vs Toncenter vs Orbs: RPC для разработчиков 2026

К 2026 году в TON-экосистеме сложилось три mainstream RPC-провайдера, на которых стоит большая часть продакшен-инфраструктуры: TonAPI от Tonkeeper (он же tonapi.io), Toncenter от TON Foundation (toncenter.com), и Orbs TON Access — децентрализованная альтернатива от Orbs Network. У каждого свой профиль сильных и слабых сторон, и выбор «какой использовать» — это не вопрос «лучший», а вопрос «лучший под мою задачу».

Этот гайд сравнивает их по 8 практическим критериям: rate-limits, free tier, latency, completeness, WebSocket support, кросс-чейн интеграция, документация и стоимость продакшен-плана. Для каждого провайдера приведён код одной и той же операции — getAccountBalance — чтобы было видно, как разница в API ощущается в реальных вызовах. В конце — decision tree, который дёргает за нужное звено в зависимости от задачи.

Главное: для большинства приложений в 2026 — TonAPI (богатый indexer, WebSocket, лучшая документация). Для прямого доступа к TVM и runGetMethod — Toncenter v3. Для proxy-уровня без single point of failure — Orbs TON Access. Прод-сетап часто использует два провайдера сразу для отказоустойчивости.

Что такое RPC в TON и почему он не «один»

В EVM-цепях RPC-провайдер — это узел, который принимает JSON-RPC запросы (eth_call, eth_getBalance) и отвечает данными ноды. В TON архитектура другая: основная нода — это валидатор, и она доступна через бинарный ADNL-протокол, а не HTTP. Между разработчиком и валидатором стоит несколько слоёв:

• Лайт-сервер — узел, который держит свежие блоки и отвечает на ADNL-запросы. К нему обращаются @ton/ton, tonweb, tonutils-go.
• HTTP-шлюз — Toncenter и Orbs TON Access. Принимают HTTP-вызовы, оборачивают их в ADNL, шлют лайт-серверу, возвращают результат.
• Индексер — отдельная инфраструктура, которая парсит каждый блок в реляционную базу (Postgres/ClickHouse) и отдаёт богатые запросы: «все jetton-трансферы адреса за год», «история NFT-владельцев», «топ-100 кошельков по балансу». TonAPI и Toncenter v3 — это индексеры.

Соответственно, TonAPI и Toncenter — это HTTP над индексером; Orbs TON Access — это HTTP-прокси к лайт-серверам без индексера. Это фундаментальная разница, из которой растёт большая часть остальных.

Сравнительная таблица — TonAPI vs Toncenter vs Orbs

TonAPI: indexer от Tonkeeper

TonAPI — это HTTP-индексер от команды Tonkeeper. Запущен в 2022, к 2026 году — самый mature по фичам и документации продукт в TON-экосистеме. Используется самим Tonkeeper, Tonviewer, мини-аппами в Telegram, большинством DEX, NFT-маркетплейсами и DeFi-протоколами.

Сильные стороны:

• Высокоуровневые endpoints. Запросить «все jetton-балансы адреса» — один HTTP-вызов. В Toncenter то же самое требует комбинации getAccountTokens + ручной парсинг.
• WebSocket с подпиской на адрес. Получаешь push-уведомление о каждой входящей/исходящей транзакции в реальном времени, без поллинга.
• NFT и jetton метаданные. TonAPI парсит и кеширует off-chain metadata (IPFS, HTTP), отдаёт уже сразу декодированную структуру.
• OpenAPI-спецификация. Можно автогенерировать клиентов на TypeScript, Python, Go, Rust, Java.

Слабые стороны:

• Низкий free-tier rate-limit без ключа — всего 1 req/sec. С ключом 5 req/sec, что мало для серьёзной нагрузки.
• Платный тариф дороже аналогичного Toncenter (TonAPI Pro от $30/мес за 100 req/sec, Toncenter — за 100 req/sec ~$39/мес, но архитектура чуть проще).
• Привязка к Tonkeeper. Если у Tonkeeper упадёт инфраструктура, TonAPI с ней. На практике аптайм >99.9%, но single point of failure есть.

Код: получить баланс TON и список jetton-балансов через TonAPI.

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

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

// 2. Все jetton-балансы — один запрос
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}`);
}

Обратите внимание: метаданные jetton (symbol, decimals, name, image) уже декодированы и отданы инлайном — не нужно дёргать жетон-минтер отдельно. Это и есть «удобство индексера».

Toncenter: канонический шлюз от TON Foundation

Toncenter — официальный HTTP-шлюз от TON Foundation. Существует в двух поколениях: v2 (старый, прямой proxy к лайт-серверу) и v3 (актуальный, включает индексер). В 2026 большинство кода работает с v3, но v2 всё ещё используется для специфичных вызовов вроде sendBoc и низкоуровневых runGetMethod.

Сильные стороны:

• Официальность. Toncenter поддерживает TON Foundation, и его API считается каноном — если в документации TON по интеграции написан пример, то он на Toncenter.
• Прямой доступ к TVM через runGetMethod. Это нужно, когда хочется вызвать произвольный getter контракта и получить сырой результат TVM-стека.
• Бесплатный ключ даёт 10 req/sec — это вдвое больше, чем у TonAPI, и достаточно для среднего проекта без оплаты.
• SSE-подписки. Server-Sent Events для новых транзакций по адресу. Менее богато, чем WebSocket TonAPI, но проще в плане отказоустойчивости (HTTP/2 stream).

Слабые стороны:

• API менее «человеческий». Чтобы получить jetton-балансы, надо сначала запросить getTokenData для каждого минтера, потом обработать ответ.
• runGetMethod через JSON может терять precision. Большие int’ы в JSON приходят как строки, и неаккуратная сериализация в клиенте даёт ошибки — особенно в JavaScript.
• US-based. Серверы Toncenter географически в Северной Америке; для пользователей в Азии и Восточной Европе latency выше, чем у TonAPI.

Код: то же — баланс TON и список jetton-балансов — через Toncenter v3.

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

// 1. Баланс TON
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-балансы — отдельный 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) {
  // Метаданные jetton надо запрашивать отдельно
  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}`);
}

Видно, что для той же задачи у Toncenter получается два уровня запросов вместо одного. С другой стороны, у вас есть прямой контроль над тем, какие данные приходят, без «магического» декодирования индексером.

Orbs TON Access: децентрализованный proxy

Orbs TON Access — это инициатива от Orbs Network (L2-проект на Ethereum), которая запустила сеть из ~25 геораспределённых нод, обслуживающих RPC-запросы к TON без centralised gateway. Это не индексер — Orbs не парсит блокчейн в реляционную БД. Это прокси: вы шлёте HTTP-запрос на ton-access endpoint, он маршрутизируется на одну из нод, нода вызывает лайт-сервер ADNL, возвращает результат.

Сильные стороны:

• Бесплатно и без ключа. Никакой регистрации, копипаст endpoint URL — и работает. Лимит ~50 req/sec на client-side fingerprint, чего хватает почти для всех use-cases.
• Отказоустойчивость. Запросы маршрутизируются на ноды Orbs автоматически: если одна упала, следующий запрос пойдёт на другую. У вас нет single point of failure типа tonapi.io.
• Не требует серверного состояния. Можно использовать прямо из браузера (WebApp, mini-app) — нет проблем с скрытием API-ключа в client-side коде.
• Совместимость с @ton/ton. Есть готовый wrapper @orbs-network/ton-access для популярного TON SDK.

Слабые стороны:

• Нет индексера. «Все jetton-балансы адреса» требует ручного перебора через лайт-сервер (сначала найти все jetton wallets, потом каждый запросить отдельно). Это медленно и упирается в rate-limit.
• История транзакций ограничена. Лайт-серверы держат только окно последних блоков; запросить транзакцию двухмесячной давности у них может не получиться.
• Нет WebSocket / SSE. Для real-time мониторинга нужно поллить.
• Документация минималистичная. Нет полноценного OpenAPI, в основном README на GitHub.

Код: баланс TON через 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-балансы требуют ручного перебора через runGetMethod
// — индексера у Orbs нет, поэтому код намного длиннее.
// Для production-кода: используйте TonAPI или Toncenter для этой задачи.

Orbs хорошо ложится в роль второго провайдера для отказоустойчивости — основной маршрут идёт через TonAPI, fallback переключается на Orbs, если TonAPI ответил 5xx. Это снимает зависимость от single endpoint без необходимости поднимать свой лайт-сервер.

Сравнение по типичным задачам

Задача 1: показать баланс TON и портфель jetton-ов

Победитель: TonAPI. Это его прямой use-case.

Задача 2: вызвать кастомный getter контракта

// Через 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]);

Все три провайдера поддерживают runGetMethod, но Toncenter — наиболее каноничная реализация, и большинство туториалов TON Foundation написаны под него.

Победитель: Toncenter v2/v3.

Задача 3: real-time мониторинг входящих платежей в Telegram-боте

// TonAPI WebSocket — подписка на адрес
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);
  // Получаем уведомления о каждой транзакции на адресе
  if (msg.method === "account_transaction") {
    handleIncomingPayment(msg.params);
  }
};

Toncenter SSE даёт аналогичный результат, но поток событий менее богатый — в TonAPI можно подписаться отдельно на jetton-трансферы, отдельно на NFT, отдельно на mempool.

Победитель: TonAPI.

Задача 4: scan архива транзакций за прошлый год для аналитики

Лайт-серверы (а значит и Orbs) с этой задачей не справляются — у них нет архива. Нужен индексер.

Победитель: Toncenter v3 на free-tier, TonAPI на production-плане (богаче API).

Задача 5: dApp на client-side без backend

Если у вас нет своего бэкенда, прятать API-key в браузерном коде — bad idea: любой пользователь его увидит и зальёт в свой бот. Здесь идеален Orbs, потому что не требует ключа вообще.

Победитель: Orbs TON Access.

Decision tree: какой провайдер выбрать

1. Я делаю Telegram-бота для приёма платежей. → TonAPI (WebSocket подписка на адрес магазина).
2. Я делаю DEX-агрегатор или NFT-маркетплейс. → TonAPI основной + Toncenter fallback. На pro-плане у обоих.
3. Я делаю мини-аппу для Telegram без бэкенда. → Orbs TON Access (нет ключа, безопасно для client-side).
4. Мне нужен прямой доступ к TVM-getter’ам и sendBoc. → Toncenter v2/v3.
5. Мне нужна максимальная отказоустойчивость и я готов писать fallback-логику. → TonAPI primary + Orbs secondary.
6. Я делаю аналитический dashboard с историей за год+. → Toncenter v3 (богатые SQL-подобные фильтры) или TonAPI Pro.
7. Мне нужен self-hosted RPC. → Toncenter — open source, можно поднять у себя. TonAPI имеет community-edition. Orbs работает только как сеть.
8. Я разрабатываю в России и боюсь блокировок. → TonAPI (CF-edge в RU работает быстро) + Orbs (распределённость снижает риск тотальной блокировки).

Платные тарифы: что покупаешь за деньги

Все три имеют коммерческие планы (кроме Orbs, у которого вместо плана — self-host или enterprise-контракт):

• TonAPI Pro — от $30/мес за 100 req/sec, $200/мес за 500 req/sec, кастом для архив-доступа. Включает SLA и приоритетный support.
• Toncenter Pro — от $39/мес за 100 req/sec, выше — кастом. SLA-контракт по запросу.
• Orbs Enterprise — нет публичного прайса, обращайся напрямую в Orbs Network для приватного gateway-deployment.

Если у вас mainstream-приложение с 1000+ DAU, который дёргает 10 req/sec на пика, free tier любого из трёх не хватит. Самое экономичное — TonAPI Pro $30/мес: вместе с WebSocket-функцией это покрывает 80% задач продакшен-dApp.

Что не предлагаем как RPC-провайдер

Несколько имён, которые регулярно попадают в Q&A, но не подходят как основной RPC:

• Tonscan API — это API эксплорера, не general-purpose RPC. Лимиты низкие, для прода не годится.
• TonScan WebSocket — устаревший, заменён TonAPI.
• dTon.io API — был сервис аналитики, к 2026 не поддерживается публично.
• Локальный лайт-сервер через ton-http-api — реальный вариант для self-host, но требует ~500 GB SSD под архив и оперативного обслуживания.

Резюме

TON RPC-стек 2026 года стоит на трёх провайдерах с тремя разными философиями. TonAPI оптимизирован под удобство и богатство данных, Toncenter — под канонический доступ к TVM, Orbs TON Access — под отказоустойчивость без ключей.

Серьёзный продакшен почти всегда использует двух провайдеров одновременно: основной для скорости и фичей, второй для fallback на случай 5xx или throttling. Это снимает риск тотального простоя из-за инцидента у одного из gateway. Локальный лайт-сервер — третий слой защиты, если у вас уже есть инфраструктурная команда; для одиночного разработчика достаточно комбинации TonAPI + Orbs.

Главный совет: не подбирайте провайдера по принципу «самый популярный». Откройте свой код, посмотрите на 5–10 типовых RPC-вызовов, прикиньте, сколько они весят на каждом из трёх — и выберите тот, где код вашего dApp короче, а данные приходят уже в нужном формате. Цена API-ключа в долгосрочной перспективе несравнимо меньше, чем стоимость обработки сырых лайт-сервер-ответов и поддержки своего индексера.