API Reference

TRON nodes expose three built-in API families: HTTP API, gRPC API, and JSON-RPC API. HTTP API and gRPC API are enabled by default, and their ports are configured in the node config.conf file. JSON-RPC API is implemented in java-tron but disabled by default; you must enable it manually in the node.jsonrpc configuration block.

Outside the standard node APIs, TronGrid provides TronGrid V1 API, and Tronscan provides Tronscan API. These APIs are developed and maintained by their respective project teams. They usually provide additional high-performance, practical extension APIs on top of standard node APIs, such as pre-indexed historical data, event search, account aggregation, and transaction aggregation, so that applications can better satisfy different query needs.

📘

Prerequisites

• Accounts
• Transactions

API layers

These APIs ultimately read data from the same TRON chain, but they differ in transport protocol, served height, coverage, and operator. Production systems often combine them: use node HTTP or gRPC for write paths, Solidity interfaces for finalized reads such as deposits and custody balances, and TronGrid V1 API or a self-hosted indexer for historical flows and event search.

Node HTTP API

HTTP API is the standard JSON-over-HTTP interface provided by java-tron nodes. It has two commonly used path families:

FullNode HTTP and Solidity HTTP usually provide matching endpoint names. For example, query latest account state with POST /wallet/getaccount, and query solidified account state with POST /walletsolidity/getaccount.

For example, query latest account state through FullNode HTTP:

curl -X POST https://api.shasta.trongrid.io/wallet/getaccount \
  -H "Content-Type: application/json" \
  -d '{
    "address": "TBRmnXKMEVfQ8XeQA2NroC9cGi77TvPbNb",
    "visible": true
  }'

To query solidified state instead, change the path to /walletsolidity/getaccount.

Write operations use FullNode HTTP, for example:

POST /wallet/createtransaction
POST /wallet/triggersmartcontract
POST /wallet/broadcasttransaction

Solidity HTTP is read-only and is suitable for exchanges, custodial wallets, bridges, and accounting systems that need final state. For deposit crediting, do not credit directly from the latest head state; wait for the transaction's block to be solidified, then query the receipt or block data through /walletsolidity/.

→ FullNode HTTP API reference

→ Solidity HTTP API reference

FullNode and SolidityNode selection guide

FullNode and SolidityNode read the same TRON chain, but they serve different heights and expose different capabilities. Choose the interface by first deciding whether the operation changes chain state, then deciding whether the read result must come from a solidified block.

A broadcast response with result: true only means the node accepted the transaction. It does not mean the transaction has been included or executed successfully. For the complete confirmation path, see Sign and broadcast — the API workflow.

Node gRPC API

gRPC API is provided directly by java-tron nodes and is enabled by default. It exposes the same class of node capabilities as HTTP API, but uses Protocol Buffers and gRPC transport. It is suitable for backend systems that need higher throughput, lower latency, stronger typing, or stable server-side integration.

Both HTTP API and gRPC API include FullNode and Solidity services. Choose the protocol based on your stack: web backends and scripts often start with HTTP; Java, Go, server-side indexers, and high-throughput jobs can use gRPC.

For Java and other JVM backends, you can usually use Trident directly. Trident is the Java SDK for TRON. It wraps node gRPC interfaces, transaction construction, signing, broadcasting, and smart-contract calls, and is suitable for exchanges, custodial wallets, indexers, and batch-processing services. For low-level API details, see the Trident upstream documentation.

→ Calling TRON via gRPC

Node JSON-RPC API

JSON-RPC API can be understood as a lightweight interface set for Ethereum-compatible scenarios. It covers part of the node's EVM-style query and call capabilities and makes it easier to reuse Web3.js, ethers, viem, and other Ethereum tooling. Because TRON and Ethereum differ in their underlying mechanisms, some Ethereum JSON-RPC methods do not have corresponding implementations on TRON, or behave differently.

JSON-RPC API is disabled by default. To use it on a self-hosted node, enable it in config.conf:

node {
  jsonrpc {
    httpFullNodeEnable = true
    httpFullNodePort = 8545
    httpSolidityEnable = true
    httpSolidityPort = 8555
  }
}

A self-hosted node serves JSON-RPC at the root path of the configured port, for example http://<host>:8545/. TronGrid's JSON-RPC gateway uses https://api.trongrid.io/jsonrpc; /jsonrpc is a TronGrid gateway path, not the generic path for self-hosted java-tron nodes.

JSON-RPC is useful when migrating Ethereum tooling. It covers part of the EVM-style interface set and is not a full replacement for node HTTP API or gRPC API. Use HTTP API or gRPC API together with JSON-RPC when your application needs broader node capabilities.

→ JSON-RPC API reference

→ TRON vs Ethereum

Ecosystem APIs

TronGrid V1 API

TronGrid is a commonly used hosted node and indexing service in the TRON ecosystem. In addition to proxying standard node APIs, TronGrid V1 API provides pre-indexed data that native nodes do not directly expose, such as account transaction history, TRC-20 / TRC-721 transfer history, contract events, and internal transaction queries.

TronGrid V1 API usually starts with /v1/, for example:

GET /v1/accounts/{address}/transactions
GET /v1/accounts/{address}/transactions/trc20
GET /v1/contracts/{address}/events

TronGrid is a hosted service. Calls usually require TRON-PRO-API-KEY, and rate limits and quota are configured per key.

→ TronGrid V1 API overview

→ TronGrid node service and extension APIs

Tronscan API

Tronscan API is maintained by Tronscan and is designed for block explorer data, aggregate statistics, account displays, transaction displays, and ecosystem queries. It is not a java-tron built-in API and should not be grouped with FullNode HTTP, gRPC, or JSON-RPC. When using Tronscan API, rely on Tronscan's current public documentation and service limits.

→ TRONSCAN API documentation

Choosing an API

Build and broadcast transactions

Use FullNode HTTP or FullNode gRPC. A typical HTTP flow is:

1. Call /wallet/createtransaction, /wallet/triggersmartcontract, or another construction endpoint to build an unsigned transaction.
2. Sign the transaction locally.
3. Call /wallet/broadcasttransaction to broadcast the signed transaction.

For the full transaction lifecycle, signing notes, and code examples, see Sign and broadcast — the API workflow.

Query solidified data

Use Solidity HTTP or Solidity gRPC. HTTP paths usually start with /walletsolidity/, for example:

POST /walletsolidity/getaccount
POST /walletsolidity/gettransactioninfobyid
POST /walletsolidity/getblockbynum

Solidified blocks usually lag the latest head by about 1 minute. For deposit crediting, custody balances, accounting, and bridge monitoring, use solidified data as the basis for final state.

→ Consensus and DPoS § Block solidification

Reuse Ethereum tooling

Use JSON-RPC API. It is suitable for connecting Web3.js, ethers, viem, and similar tools to TRON, but its coverage is narrower than node HTTP and gRPC. For capabilities not covered by JSON-RPC, combine it with HTTP API or gRPC API.

Query account history and events

If you do not want to run your own indexer, use TronGrid V1 API. It is suitable for account history, TRC-20 transfers, event logs, and internal transactions. High-traffic production environments should plan for API keys, rate limits, pagination, and data latency.

Exchanges and custodial wallets can also scan solidified blocks from SolidityNode and maintain their own local index database.

→ Exchange and custodial wallet integration

Request and address formats

HTTP API and TronGrid V1 API use JSON requests and responses. Most node HTTP APIs support the visible parameter:

{
  "address": "T...",
  "visible": true
}

• visible: true: addresses use Base58Check format, usually starting with T.
• visible: false or omitted: addresses use hex format, usually starting with 41.

JSON-RPC API follows Ethereum JSON-RPC conventions. Values and byte data are usually represented as 0x hex strings. TRON addresses are also converted according to compatibility rules in JSON-RPC.

→ Address and data encoding

Resource budgeting

Every state-changing transaction consumes Bandwidth or Energy. Plain transfers mostly consume Bandwidth, while smart-contract calls mostly consume Energy. For contract calls, fee_limit caps the maximum Energy budget available to the transaction, including staked Energy and Energy that can be covered by burning TRX. It is not simply "the maximum TRX to burn". If the value is too low, the transaction may fail due to insufficient Energy.

→ Resource model

Related resources

• API task map — choose docs and reference APIs by task
• Confirmation semantics — distinguish broadcast success, on-chain inclusion, receipt execution result, and solidified state
• Sign and broadcast — the API workflow — transaction construction, signing, and broadcast lifecycle with examples
• Address and data encoding — Base58 and hex addresses, the visible flag, and ABI encoding for contract calls
• Errors and debugging — common error categories, hex error decoding, and retry strategy
• TronGrid — TronGrid node service and extension API introduction
• RPC and indexer providers — choosing hosted RPC, indexers, or self-hosted nodes
• Query balance and resources — query TRX, TRC-10, TRC-20 balances and resources
• Calling TRON via gRPC — call node APIs over gRPC
• Networks — Mainnet, Shasta, and Nile endpoint addresses