Skip to main content
Every object returned by API v2 includes a @type field that identifies the object’s structure. These values originate from two sources:
  1. Tonlib types such as raw.fullAccountState and tvm.cell come from the tonlib TL schema, the type definition language used by the C++ library powering this API.
  2. Extended types, which are prefixed with ext., are added by TON Center to provide parsed representations with additional decoded fields that are not available in the base tonlib schema.
The @type field acts as a discriminator: when a response can return different object shapes, the @type value indicates which fields to expect. This pattern is useful for type-safe deserialization in statically typed languages.

TL primitive types

The TL schema maps to JSON types as follows:

Account state

When querying account information, the account_state field uses @type to indicate which kind of contract is deployed. The TL schema defines these as variants of AccountState:

Account information

Full account queries return one of these top-level types:

Address types

Block identifiers

Block data

These types are returned by block query endpoints. The TL definitions:

Transactions and messages

Message body types

The msg_data field on messages uses @type to indicate how to interpret the body:

TVM types

Used as input and output for smart contract get methods: runGetMethod, runGetMethodStd.

Stack entries

Each stack entry wraps a value with a type tag:

Value types

Get method result

Fees

Configuration

Libraries

Token types (TON Center extensions)

These types are not in the base tonlib TL schema. They are added by TON Center to provide parsed Jetton and NFT data via the getTokenData endpoint.

DNS record types

DNS entries use @type to indicate the record type stored at a domain:

Payment channel types

Restricted wallet types

Utility types

TON Center extensions.

Reference

For background on the TL-B format used across the TON ecosystem, see the TL-B overview. Types prefixed with ext. are TON Center extensions not present in the upstream TL schema.