The FullNode HTTP API is TRON's core API service, providing endpoints for broadcasting transactions, querying on-chain data, and interacting with smart contracts.

Transaction Flow

Sending a transaction via the HTTP API generally involves three steps:

Build a Transaction object using the relevant API
Sign the Transaction object offline using an SDK
Broadcast the signed transaction using BroadcastTransaction API

Address Format

All APIs support a visible parameter to specify the address encoding format used in both requests and responses:

visible=true: addresses are Base58Check-encoded (typically prefixed with T)
visible=false: addresses are HEX-encoded (typically prefixed with 41)

The default value of visible is false.

Multi-Signature

All APIs that create or modify on-chain state accept a Permission_id parameter to specify which permission set to use, enabling multi-signature workflows.

Request Method

Supported request methods vary by API — some APIs accept only POST, others only GET. Refer to the individual API documentation for details. Note that when using POST, all parameters must be passed as JSON in the HTTP request body; other encoding formats are not supported.

Response Format

TRON nodes define their data structures using Protocol Buffer (proto3). When accessed via the HTTP API, these structures are serialized and returned as JSON. There is one aspect of this serialization behavior worth paying close attention to.

Proto3 Default Value Omission

Under the proto3 specification, fields whose values equal the default for their types are omitted from JSON output by default to minimize payload size. A missing field in the response, therefore, does not necessarily indicate an error or incomplete data from the node; it simply signifies that the field holds its default value. Note that certain APIs may still explicitly include default-valued fields for compatibility or readability; refer to the documentation for each API for its specific behavior.

📘
Parsing Rule
Any field absent from a JSON response should be treated as carrying the proto3 default value for its type.

Default values by type:

Field Type	Default Value	Behavior in JSON
`int32` / `int64`	`0`	Typically omitted
`bool`	`false`	Typically omitted
`string`	`""`	Typically omitted
`bytes`	empty	Typically omitted
`enum`	First defined value (index `0`)	Typically omitted
`repeated`	`[]`	Typically omitted

Example: `frozenV2` in a `GetAccount` Response

When calling /wallet/getaccount API, the frozenV2 field — which contains the account's staking details under Stake 2.0 — may appear as follows, with default-valued fields omitted:

"frozenV2": [
  { "amount": 20000000000 },
  { "type": "ENERGY", "amount": 20400000000 },
  { "type": "TRON_POWER" }
]

With default values applied, this should be interpreted as:

"frozenV2": [
  { "type": "BANDWIDTH",  "amount": 20000000000 },
  { "type": "ENERGY",     "amount": 20400000000 },
  { "type": "TRON_POWER", "amount": 0            }
]

First entry: type is absent → defaults to BANDWIDTH (index 0 in the ResourceCode enum)
Third entry: amount is absent → defaults to 0

Client Handling

Using an official protobuf JSON parser: when deserializing JSON into the matching generated protobuf message with a protobuf-aware JSON parser, absent fields are typically interpreted using protobuf default values. — no additional handling required.
Parsing raw JSON directly: absent fields must be handled manually by applying the appropriate default value. Example implementations:

// JavaScript / TypeScript
function parseFrozenV2(entries) {
  return entries.map(entry => ({
    type:   entry.type   ?? "BANDWIDTH",
    amount: entry.amount ?? 0,
  }));
}

# Python
def parse_frozen_v2(entries):
    for entry in entries:
        yield {
            "type":   entry.get("type", "BANDWIDTH"),
            "amount": entry.get("amount", 0),
        }

// Java
public Map<String, Object> parseFrozenV2Entry(JSONObject json) {
    String type   = json.has("type")   ? json.getString("type")  : "BANDWIDTH";
    long   amount = json.has("amount") ? json.getLong("amount")  : 0L;
    return Map.of("type", type, "amount", amount);
}

Common Mistake

Take the type field in a GetAccount response as an example. For a standard user account, type is Normal — the first value defined in the enum (index 0) — so the field is omitted from the response entirely. Interpreting its absence as an unknown account type or a malformed response is incorrect: a missing type field unambiguously indicates the account is a standard user account (Normal).

Security

📘
XSS Protection
Although TRON has avoided XSS by setting the Content-Type of HTTP APIs to application/json, there are a few APIs that don't have input validation. To better protect user data security, we recommend that you correctly encode any data from APIs before they use it in any UI, especially when parameter "visible = true".
For comprehensive XSS prevention guidance, refer to the OWASP XSS Prevention Cheat Sheet.