tonapi.io Alternatives in 2026 for TON Developers

The first request went through, the hundredth came back 429 — and now you're hunting for a tonapi alternative

It's three in the morning and you're deploying a bot that watches incoming USDT payments to your users' wallets. Locally, it ran beautifully. In production — five minutes after launch — the logs are wall-to-wall with the same line: HTTP 429 Too Many Requests. Balances update in fits and starts, users are messaging "where's my money". Sound familiar? The public API hit its ceiling right as your traffic started to grow. That's the moment the search begins: you need a tonapi alternative that can survive production — and "tonapi alternative 2026" is exactly what you end up typing into the search bar.

Without a key, tonapi.io's public limit is roughly 1 request per second, and any loop like "fetch balances for a list of wallets" or "pull transaction history" slams into it instantly.

Let's clear up the folklore first, so you don't chase something that doesn't exist. The TON community loves to joke about "error 228" — it's a meme number, not an API error code. Neither tonapi nor toncenter will ever return a "228". The real rate-limit code is 429, and that's the one you need to catch and handle. If you're googling "tonapi 228", what you actually need is a 429 fix — we've covered that in detail in /blog/tonapi-429-fix.

Below is an honest breakdown of where tonapi.io tops out, who else is on the market, and why more and more teams are accessing TON not through raw REST but through MCP.

What tonapi.io is and where it tops out

tonapi.io is a public HTTP API for TON (indexed REST on top of a node). You send a request, you get JSON back: balance, transactions, account state, jetton and NFT data. Zero infrastructure on your side. For a prototype — perfect.

The ceiling starts where production starts:

• Shared rate limit. Without a key it's ~1 rps, then 429. With a key the limit is higher, but it's still shared infrastructure. That's not a ban and not an outage — it's exactly how rate limiting on a shared resource is supposed to work.
• Raw REST. You get JSON and write all the code yourself: converting raw units via decimals, computing the jetton wallet address, assembling a swap transaction. The API doesn't "do" actions — it only reads.
• Read-only. No swaps, cross-chain, or wallet generation out of the box — that was never its job.

For a dashboard, that's plenty. For an agent that needs to do something on TON — it isn't.

Why developers are looking for a tonapi alternative in 2026

The three reasons that come up most often:

1. The limits bite exactly when your project takes off. With ten users, 1 rps is fine. A thousand show up — and 429s rain down. That's the design of a public endpoint, not a bug. For the options, see toncenter alternatives for 2026.
2. The integration layer has changed. Increasingly, it's not your backend hitting TON directly but an AI agent — Claude, Cursor, ChatGPT/Codex. To an agent, a REST endpoint is just documentation — something you have to feed it, that it then has to parse without mixing up the parameters. An agent's native interface isn't REST — it's tools over MCP.
3. You need actions, not just data. A GRAM⇄jetton swap, a cross-chain exchange, wallet creation. tonapi doesn't cover any of that — you end up gluing several SDKs together.

The analogy is simple. A public API is a city bus: free, runs on a schedule, but at rush hour it's packed solid and lurches along. For production you need either your own lane or a fundamentally different vehicle.

Who to consider: public APIs, liteservers, indexers, and MCP

An honest map of the options for 2026:

• Public HTTP APIs (tonapi.io, toncenter). Quick start, indexed data. The downside — a shared rate limit, 429, read-only.
• Public liteservers from the global config (ADNL). Native node access, but the servers are shared and throttled: under load they often reply not ready or time out over ADNL, and they don't keep deep history.
• Your own liteserver / archive node / indexer. Maximum control and depth, but you pay in hardware, sync time, and devops hours. It's an infrastructure project, not self-serve.
• An MCP server for TON. Tools instead of raw REST: the agent calls get_balance or build_swap_tx instead of hand-parsing JSON. For the protocol itself, see MCP for TON: where to start.

TONNode: TON access through MCP, not raw REST

TONNode (website: tonnode.io) is a hosted MCP server for TON. MCP (Model Context Protocol) is the standard AI agents (Claude, Cursor, ChatGPT/Codex, and any MCP client) use to call tools. The difference from tonapi is in how the problem is framed: instead of "give me JSON, I'll figure it out", you hand the agent a set of typed tools and it decides which one to call.

A practical example. To get an address's USDT balance over raw REST you need to: find the USDT jetton master address, compute the owner's jetton wallet address, call its get-method, grab decimals (6 for USDT), and convert the raw units. Through TONNode it's a single get_jetton_balance call — the jetton wallet is computed on-chain for you. Full case study: USDT balance on TON in one call.

An important note on honesty: TONNode is not pay-per-request, not a REST/indexed API, not SSE/WebSocket streams, and not webhooks. The archive node is still syncing, so we don't promise deep history as a ready-made service. What exists today is exactly what's described below, with nothing tacked on.

16 tools: read + swap + cross-chain + wallet

Exactly 16 tools, four groups. All sixteen are available on every plan.

Read (8):

• get_masterchain_info — masterchain head
• get_balance — GRAM balance
• get_account_state — status, flags, last transaction
• get_transactions — transaction history
• run_get_method — any read-only contract get-method
• get_jetton_balance — jetton/USDT balance; the jetton wallet address is computed on-chain for you
• get_jetton_info — jetton metadata: name, symbol, decimals, supply (decimals is what you need to convert raw units: USDT=6, most jettons 9)
• parse_address — converts and validates EQ/UQ/raw formats, works offline

Swap (2):

• get_swap_quote — a firm DEX quote for GRAM⇄jetton via the Omniston protocol (STON.fi + DeDust liquidity)
• build_swap_tx — an unsigned swap transaction, ready for TonConnect

Cross-chain (5):

• get_crosschain_quote — cross-chain swap quote
• build_crosschain_swap_tx — an unsigned HTLC escrow transaction + a secret
• track_crosschain_swap — the deal's phases on both networks
• disclose_crosschain_secret — reveal the secret for settlement after verifying readiness on-chain
• build_crosschain_refund — recover funds from escrow if a swap stalls

Atomic HTLC escrow, TON is always the source. Destination networks: Ethereum, Arbitrum, Base, BNB Chain, Polygon, Avalanche. TRON is not supported yet.

Wallet (1):

• generate_wallet — creates a wallet of version v3r2 / v4 / v5r1 / highload_v3; returns the mnemonic, keys, and address

That same "USDT balance" — the one that sets off the whole painful manual call chain — is a single tool here. And you can hand the agent tasks in plain language:

Check the USDT balance on wallet EQC… and show the last 5 transactions

Get a firm quote for swapping 100 GRAM to USDT and build the unsigned transaction

The agent breaks the first prompt into get_jetton_balance + get_transactions, the second into get_swap_quote + build_swap_tx. The swap result gets signed by the user's wallet — without a single line of parsing code on your side.

Non-custodial: the server never signs and never holds keys

The key difference, and the reason to keep reading. The swap, cross-chain, and wallet tools are strictly non-custodial:

• The server never signs transactions and never holds funds or private keys.
• build_swap_tx, build_crosschain_swap_tx, and the rest return unsigned TonConnect messages. The user's wallet signs them — the server only ever sees a message that's ready for signing.
• The wallet from generate_wallet is handed to you in full (mnemonic + keys + address) and nothing stays on the server.

In other words, TONNode prepares the transaction, but only the key's owner can press "sign".

To compare fairly: the official @ton/mcp from the TON Foundation is a custodial agent wallet (split-key: the operator key lives with the agent, the owner key with the user). It signs on its own, can spend autonomously, and handles NFT/DNS. It has real strengths. The difference is simple: it's custodial and TON-only; TONNode is non-custodial and does cross-chain. Detailed comparison: tonnode.io/mcp/vs-official.

How to connect: free locally, or a hosted key

Free and local. The @tonnode/mcp package is open source (MIT), lives on npm and GitHub (tonnode/mcp), and speaks TON's native ADNL protocol with no HTTP middlemen. The full read set, right away:

{
  "mcpServers": {
    "ton": {
      "command": "npx",
      "args": ["-y", "@tonnode/mcp"]
    }
  }
}

Hosted key — when you need guaranteed throughput under your own key:

{
  "mcpServers": {
    "ton": {
      "type": "http",
      "url": "https://mcp.tonnode.io/mcp",
      "headers": { "Authorization": "Bearer tn_live_…" }
    }
  }
}

Plans (all 16 tools everywhere — you only pay for throughput):

Plan	Price	Limit
Hobby	free forever	60 requests/min
Pro	$29/mo	300 requests/min
Scale	$199/mo	1200 requests/min

The free Hobby key is issued right after sign-in, no card required. You can pay for a paid plan in GRAM or USDT on TON via TonConnect, or in BTC/ETH/SOL and others through an xRocket invoice in Telegram; the key is issued automatically once the payment settles. (GRAM is Toncoin, renamed in June 2026; the network is still called TON.)

Which one to pick for your use case

• A prototype or one-off script where reads are enough. Public tonapi.io / toncenter, or a local npx -y @tonnode/mcp — free and sufficient. Keep the 429 in mind and don't build production on it.
• An agent that reads TON (balances, transactions, USDT, get-methods). Run @tonnode/mcp locally — free, the full read set, zero infrastructure.
• Production under load + swaps/cross-chain/wallet generation. A TONNode hosted key: a guaranteed limit, non-custodial unsigned transactions, atomic cross-chain to 6 EVM networks.
• You need an autonomous agent wallet with NFT/DNS. Look at the official @ton/mcp — with the custodial caveat in mind. TONNode's NFT/DNS tools are on the roadmap, deep archive history is still syncing, and a dedicated liteserver is set up manually on request — if that's critical for you, get in touch.

The short version: a 429 is the signal that you've outgrown the bus, and the best tonapi alternative under load isn't yet another shared REST endpoint — it's guaranteed throughput over MCP. Start with the free read set locally, and when you hit the limit, get a key that guarantees it.

Get a free Hobby key (no card) → tonnode.io/dashboard?plan=hobby

See all the tools at tonnode.io/mcp · pricing at tonnode.io/pricing