What is a TON endpoint and how do I choose one?

TON endpoints are the standard way for wallets, bots, and backend services to talk to The Open Network. They are HTTP or JSON-RPC bridge endpoints that read blockchain data, query smart contracts, and submit signed messages. Because TON nodes speak ADNL rather than HTTP, the endpoint layer is usually built on the reference ton-http-api implementation.

This page explains what a TON endpoint is, how it differs from an EVM RPC endpoint, which mainnet and testnet endpoint options are common, and how to test an endpoint before you rely on it.

TON endpoint decision checklist

Work through this checklist before you commit to a TON endpoint. It only takes a few minutes and prevents most integration issues.

• Mainnet or testnet? Use testnet for development and staging; point production at mainnet.
• API version? Choose v2 for direct liteserver access or v3 if you need indexed queries for traces, jettons, and NFTs.
• Method coverage? Confirm the endpoint supports the methods your wallet or bot needs.
• Authentication? Understand whether you need an API key and how rate limits are applied.
• Streaming? If you react to transactions in real time, check for SSE or WebSocket support.
• Redundancy? Plan for provider outages and test fallback endpoints.
• Cost model? Compare shared public endpoints with RPC pricing and dedicated nodes.

TON RPC vs EVM RPC: why the endpoint shape is different

Many developers arrive with an Ethereum mental model. They expect methods like eth_blockNumber, eth_call, and eth_getLogs. TON is not EVM-compatible.

TON's core component is the TVM (TON Virtual Machine), and nodes use the ADNL binary protocol for communication. An HTTP endpoint is an intermediate service. It receives HTTP requests, uses tonlib to talk to a liteserver, and returns JSON. You can use TON Center's public service, run your own ton-http-api, or use a hosted RPC provider that has already deployed TON infrastructure.

This architecture also explains the method names. The most common methods are getAddressInformation, getTransactions, runGetMethod, estimateFee, and sendBoc. There are no eth_ methods and no web3_clientVersion calls. When someone says 'TON endpoint', they usually mean the HTTP API address, not a JSON-RPC node in the Ethereum sense.

Mainnet and testnet endpoint options

For a quick start, TON Center is the reference API. Its public v2 endpoints are:

Both are public and rate-limited. TON Center also offers a v3 API with an indexer, plus a Streaming API v2 over SSE and WebSocket.

Hosted providers like OnFinality give you a managed endpoint so you do not have to run a TON node. Check the TON network page for mainnet details and the TON testnet page for staging. You can also see the full supported networks list.

How to test a TON endpoint

The fastest way to verify an endpoint is with a simple curl request. Replace EQD... with a real address.

curl 'https://toncenter.com/api/v2/getAddressInformation?address=EQD...' -H 'Accept: application/json'

A successful response looks like this:

{
  "ok": true,
  "result": {
    "@type": "raw.fullAccountState",
    "balance": "123456789",
    "state": "active"
  }
}

After the request succeeds, test a read-only smart contract call with runGetMethod, then test estimateFee before you attempt to broadcast a transaction.

TON API methods you will use most

Here are the methods you are most likely to need in a wallet or bot:

• getAddressInformation – returns balance, state, code hash, and other account details.
• getTransactions – returns recent transaction history for an address.
• runGetMethod – calls a get-method on a smart contract (read-only, no fees).
• estimateFee – estimates fees for an external message.
• sendBoc – submits a signed external message (a Bag of Cells) to the network.
• detectAddress – normalizes addresses between raw and user-friendly formats.
• getTokenData – reads jetton (token) metadata and balances.

If your use case needs rich historical queries, TON Center API v3 adds indexed access to traces, jettons, and NFTs. A typical wallet, however, can be built with v2 and the methods above.

Choosing between public, hosted, and dedicated TON endpoints

Public endpoints are attractive for prototypes. For anything running continuously, check what happens when you exceed a rate limit. Many public endpoints return a 429 response with no retry guidance, which can be fine for a local demo but risky for a service.

Use the table below to evaluate any TON endpoint, including your own self-hosted instance.

Common TON endpoint pitfalls

Even after you have an endpoint, TON integration trips up developers in a few ways.

• Assuming EVM JSON-RPC. Do not send eth_ methods to a TON endpoint. Use TON-specific methods instead.
• Using the wrong address format. TON supports base64 user-friendly addresses and raw workchain:hex addresses. Normalize with detectAddress before querying.
• Hitting rate limits. 429 responses mean the endpoint is throttling you. Add retry with backoff and use an API key when possible.
• Mixing mainnet and testnet. A testnet address queried on mainnet will return uninitialized account state or empty data. Verify the network in your configuration.
• Forgetting that sendBoc requires a signed external message. You must construct and sign a Bag of Cells; you cannot simply send a private key or a raw hex transaction.
• Using v2 for deep historical queries. getTransactions only returns what the liteserver has. For transaction history, traces, or NFTs, use an indexed API such as TON Center v3.
• Ignoring proof requirements. If you need trustless verification, HTTP APIs may not return proof bundles. In that case, connect to a liteserver with tonlib or use a service that provides proofs.

Next steps with OnFinality

Once you know the endpoint shape, test it in your app's development environment. For production, decide whether a shared public endpoint is sufficient or whether you need more control.

OnFinality offers TON RPC API access as part of its network coverage and dedicated node infrastructure for teams that want a private endpoint. Before you deploy, check the TON network page for current endpoint information and the TON testnet page for staging. You can also review RPC pricing to understand the trade-offs between shared and dedicated setups.

Whichever endpoint you choose, keep the decision checklist in mind: verify network, method coverage, rate limits, and streaming support before you write production code.

Key Takeaways

• A TON endpoint is an HTTP/JSON-RPC bridge to TON's liteservers. It uses TON-specific methods, not EVM methods.
• TON Center API v2 is the reference implementation; v3 adds indexed queries for rich history.
• Test endpoints with curl before integrating, and check rate limits and authentication.
• Use mainnet and testnet endpoints deliberately; mixing them causes confusing errors.
• For production, consider a hosted or dedicated TON endpoint from OnFinality instead of relying on public free endpoints.

Frequently Asked Questions

What is a TON endpoint?

A TON endpoint is an HTTP API address that lets applications read TON data, query smart contracts, and send transactions without speaking ADNL directly.

Is TON compatible with Ethereum JSON-RPC?

No. TON uses the TVM and ADNL protocol. An HTTP API such as TON Center exposes methods like getAddressInformation and sendBoc, not eth_ methods.

What is the difference between TON API v2 and v3?

v2 queries a liteserver directly through ton-http-api. v3 uses an indexed database to support richer queries for transactions, traces, jettons, and NFTs.

How do I choose a TON endpoint provider?

Check mainnet/testnet coverage, method support, rate limits, authentication, streaming capability, and whether you need indexed history or a dedicated node. Compare plans on RPC pricing.