Account data

A simplified version of the onchain Account resource

Account signature scheme

The account signature scheme allows you to have two types of accounts:

1. A single Ed25519 key account, one private key
2. A k-of-n multi-Ed25519 key account, multiple private keys, such that k-of-n must sign a transaction.
3. A single Secp256k1Ecdsa key account, one private key

A hex encoded 32 byte Aptos account address.

This is represented in a string as a 64 character hex string, sometimes
shortened by stripping leading 0s, and adding a 0x.

For example, address 0x0000000000000000000000000000000000000000000000000000000000000001 is represented as 0x1.


This is the generic struct we use for all API errors, it contains a string
message and an Aptos API specific error code.

A code providing VM error details when submitting transactions to the VM

These codes provide more granular error information beyond just the HTTP
status code of the response.

A Block with or without transactions

This contains the information about a transactions along with
associated transactions if requested

The transactions in the block in sequential order

Final state of resources changed by the transaction

The VM status of the transaction, can tell useful information in a failure

A block metadata transaction

This signifies the beginning of a block, and contains information
about the specific block

The indices of the proposers who failed to propose

Secondary signer accounts of the request for Multi-agent

Entry function id is string representation of a entry function defined on-chain.

Format: `{address}::{module name}::{function name}`

Both `module name` and `function name` are case-sensitive.


Payload which runs a single entry function

A more API-friendly representation of the on-chain `aptos_types::aggregate_signature::AggregateSignature`.

A more API-friendly representation of the on-chain `aptos_types::jwks::ProviderJWKs`.

A more API-friendly representation of the on-chain `aptos_types::jwks::QuorumCertifiedUpdate`.

Fee payer signature for fee payer transactions

This allows you to have transactions across multiple accounts and with a fee payer

The associated signatures, in the same order as the secondary addresses

Struct holding the outputs of the estimate gas API

The deprioritized estimate for the gas unit price

The current estimate for the gas unit price

The prioritized estimate for the gas unit price

The writeset payload of the Genesis transaction

The genesis transaction

This only occurs at the genesis transaction (version 0)

Representation of a successful healthcheck

All bytes (Vec<u8>) data is represented as hex-encoded string prefixed with `0x` and fulfilled with
two hex digits per byte.

Unlike the `Address` type, HexEncodedBytes will not trim any zeros.


The struct holding all data returned to the client by the
index endpoint (i.e., GET "/").  Only for responding in JSON

Git hash of the build of the API endpoint.  Can be used to determine the exact
software version used by the API endpoint.

The JWK type that can be converted from/to `JWKMoveStruct` but easier to use in rust.

Generic type params associated with the Move function

Whether the function can be called as an entry function directly in a transaction

Whether the function is a view function or not

Parameters associated with the move function

Move abilities tied to the generic type param and associated with the function that uses it

Move module id is a string representation of Move module.

Format: `{address}::{module name}`

`address` should be hex-encoded 32 byte account address that is prefixed with `0x`.

Module name is case-sensitive.


Whether the struct is marked with the #[event] annotation

Whether the struct is a native struct of Move

Move abilities tied to the generic type param and associated with the type that uses it

String representation of a MoveStructTag (on-chain Move struct type). This exists so you
can specify MoveStructTags as path / query parameters, e.g. for get_events_by_event_handle.

It is a combination of:
  1. `move_module_address`, `module_name` and `struct_name`, all joined by `::`
  2. `struct generic type parameters` joined by `, `

Examples:
  * `0x1::coin::CoinStore<0x1::aptos_coin::AptosCoin>`
  * `0x1::account::Account`

Note:
  1. Empty chars should be ignored when comparing 2 struct tag ids.
  2. When used in an URL path, should be encoded by url-encoding (AKA percent-encoding).

See [doc](https://aptos.dev/concepts/accounts) for more details.


This is a JSON representation of some data within an account resource. More specifically,
it is a map of strings to arbitrary JSON values / objects, where the keys are top level
fields within the given resource.

To clarify, you might query for 0x1::account::Account and see the example data.

Move `bool` type value is serialized into `boolean`.

Move `u8`, `u16` and `u32` type value is serialized into `integer`.

Move `u64`, `u128` and `u256` type value is serialized into `string`.

Move `address` type value (32 byte Aptos account address) is serialized into a HexEncodedBytes string.
For example:
  - `0x1`
  - `0x1668f6be25668c1a17cd8caf6b8d2f25`

Move `vector` type value is serialized into `array`, except `vector<u8>` which is serialized into a
HexEncodedBytes string with `0x` prefix.
For example:
  - `vector<u64>{255, 255}` => `["255", "255"]`
  - `vector<u8>{255, 255}` => `0xffff`

Move `struct` type value is serialized into `object` that looks like this (except some Move stdlib types, see the following section):
  ```json
  {
    field1_name: field1_value,
    field2_name: field2_value,
    ......
  }
  ```

For example:
  `{ "created": "0xa550c18", "role_id": "0" }`

**Special serialization for Move stdlib types**:
  - [0x1::string::String](https://github.com/aptos-labs/aptos-core/blob/main/language/move-stdlib/docs/ascii.md)
    is serialized into `string`. For example, struct value `0x1::string::String{bytes: b"Hello World!"}`
    is serialized as `"Hello World!"` in JSON.


String representation of an on-chain Move type tag that is exposed in transaction payload.
    Values:
      - bool
      - u8
      - u16
      - u32
      - u64
      - u128
      - u256
      - address
      - signer
      - vector: `vector<{non-reference MoveTypeId}>`
      - struct: `{address}::{module_name}::{struct_name}::<{generic types}>`

    Vector type value examples:
      - `vector<u8>`
      - `vector<vector<u64>>`
      - `vector<0x1::coin::CoinStore<0x1::aptos_coin::AptosCoin>>`

    Struct type value examples:
      - `0x1::coin::CoinStore<0x1::aptos_coin::AptosCoin>
      - `0x1::account::Account`

    Note:
      1. Empty chars should be ignored when comparing 2 struct tag ids.
      2. When used in an URL path, should be encoded by url-encoding (AKA percent-encoding).


Multi agent signature for multi agent transactions

This allows you to have transactions across multiple accounts

A Ed25519 multi-sig signature

This allows k-of-n signing for a transaction

The public keys for the Ed25519 signature

Signature associated with the public keys in the same order

The number of signatures required for a successful transaction

A multisig transaction that allows an owner of a multisig account to execute a pre-approved
transaction as the multisig account.

A placeholder to represent the absence of account signature

Move type `0x1::jwks::RSA_JWK` in rust.
See its doc in Move for more details.

Table Item request for the GetTableItemRaw API

Payload which runs a script that can run multiple functions

Representation of a StateKey as a hex string. This is used for cursor based pagination.


A request to submit a transaction

This requires a transaction and a signature of it

Table Item request for the GetTableItem API

Enum of the different types of transactions in Aptos

An enum of the possible transaction payloads

An enum representing the different transaction signatures available

Information telling which batch submission transactions failed

The index of which transaction failed, same as submission order

Batch transaction submission result

Tells which transactions failed

A string containing a 128-bit unsigned integer.

We represent u128 values as a string to ensure compatibility with languages such
as JavaScript that do not parse u128s in JSON natively.


A string containing a 256-bit unsigned integer.

We represent u256 values as a string to ensure compatibility with languages such
as JavaScript that do not parse u256s in JSON natively.


A string containing a 64-bit unsigned integer.

We represent u64 values as a string to ensure compatibility with languages such
as JavaScript that do not parse u64s in JSON natively.


Move type `0x1::jwks::UnsupportedJWK` in rust.
See its doc in Move for more details.

A transaction submitted by a user to change the state of the blockchain

An event from a transaction with a version

View request for the Move View Function API

Write a new module or update an existing one

Write a resource or update an existing one

A final state change of a transaction on a resource or module

A writeset payload, used only for genesis

Aptos Labs

The Aptos Node API is a RESTful API for client applications to interact with the Aptos blockchain.

Apache 2.0

Aptos Node API

Get the latest ledger information, including data such as chain ID,
role type, ledger versions, epoch, etc.

By default this endpoint just checks that it can get the latest ledger
info and then returns 200.

If the duration_secs param is provided, this endpoint will return a
200 if the following condition is true:

`server_latest_ledger_info_timestamp >= server_current_time_timestamp - duration_secs`

Threshold in seconds that the server can be behind to be considered healthy

If not provided, the healthcheck will always succeed

duration_secs

Return the authentication key and the sequence number for an account
address. Optionally, a ledger version can be specified. If the ledger
version is not specified in the request, the latest ledger version is used.

Address of account with or without a `0x` prefix

address

Ledger version to get state of account

If not provided, it will be the latest version

ledger_version

Event types are globally identifiable by an account `address` and
monotonically increasing `creation_number`, one per event type emitted
to the given account. This API returns events corresponding to that
that event type.

Hex-encoded 32 byte Aptos account, with or without a `0x` prefix, for
which events are queried. This refers to the account that events were
emitted to, not the account hosting the move module that emits that
event type.

Creation number corresponding to the event stream originating
from the given account.

creation_number

Starting sequence number of events.

If unspecified, by default will retrieve the most recent events

start

Max number of events to retrieve.

If unspecified, defaults to default page size

limit

This API uses the given account `address`, `eventHandle`, and `fieldName`
to build a key that can globally identify an event types. It then uses this
key to return events emitted to the given account matching that event type.

Name of struct to lookup event handle e.g. `0x1::account::Account`

event_handle

Name of field to lookup event handle e.g. `withdraw_events`

field_name

Starting sequence number of events.

If unspecified, by default will retrieve the most recent

Retrieves an individual module from a given account and at a specific ledger version. If the
ledger version is not specified in the request, the latest ledger version is used.

The Aptos nodes prune account state history, via a configurable time window.
If the requested ledger version has been pruned, the server responds with a 410.

module_name

Retrieves all account modules' bytecode for a given account at a specific ledger version.
If the ledger version is not specified in the request, the latest ledger version is used.

The Aptos nodes prune account state history, via a configurable time window.
If the requested ledger version has been pruned, the server responds with a 410.

Cursor specifying where to start for pagination

This cursor cannot be derived manually client-side. Instead, you must
call this endpoint once without this query parameter specified, and
then use the cursor returned in the X-Aptos-Cursor header in the
response.

Max number of account modules to retrieve

If not provided, defaults to default page size.

Retrieves an individual resource from a given account and at a specific ledger version. If the
ledger version is not specified in the request, the latest ledger version is used.

The Aptos nodes prune account state history, via a configurable time window.
If the requested ledger version has been pruned, the server responds with a 410.

Name of struct to retrieve e.g. `0x1::account::Account`

resource_type

Retrieves all account resources for a given account and a specific ledger version.  If the
ledger version is not specified in the request, the latest ledger version is used.

The Aptos nodes prune account state history, via a configurable time window.
If the requested ledger version has been pruned, the server responds with a 410.

Max number of account resources to retrieve

If not provided, defaults to default page size.

Retrieves on-chain committed transactions from an account. If the start
version is too far in the past, a 410 will be returned.

If no start version is given, it will start at version 0.

To retrieve a pending transaction, use /transactions/by_hash.

Account sequence number to start list of transactions

If not provided, defaults to showing the latest transactions

Max number of transactions to retrieve.

If not provided, defaults to default page size

This endpoint allows you to get the transactions in a block
and the corresponding block information.

Transactions are limited by max default transactions size.  If not all transactions
are present, the user will need to query for the rest of the transactions via the
get transactions API.

If the block is pruned, it will return a 410

block_height

If set to true, include all transactions in the block

If not provided, no transactions will be retrieved

with_transactions

This endpoint allows you to get the transactions in a block
and the corresponding block information given a version in the block.

Transactions are limited by max default transactions size.  If not all transactions
are present, the user will need to query for the rest of the transactions via the
get transactions API.

If the block has been pruned, it will return a 410

Ledger version to lookup block information for.

version

Gives an estimate of the gas unit price required to get a transaction on chain in a
reasonable amount of time. The gas unit price is the amount that each transaction commits to
pay for each unit of gas consumed in executing the transaction. The estimate is based on
recent history: it gives the minimum gas that would have been required to get into recent
blocks, for blocks that were full. (When blocks are not full, the estimate will match the
minimum gas unit price.)

The estimation is given in three values: de-prioritized (low), regular, and prioritized
(aggressive). Using a more aggressive value increases the likelihood that the transaction
will make it into the next block; more aggressive values are computed with a larger history
and higher percentile statistics. More details are in AIP-34.

Provides a UI that you can use to explore the API. You can also
retrieve the API directly at `/spec.yaml` and `/spec.json`.

Get a table item at a specific ledger version from the table identified by {table_handle}
in the path and the "key" (TableItemRequest) provided in the request body.

This is a POST endpoint because the "key" for requesting a specific
table item (TableItemRequest) could be quite complex, as each of its
fields could themselves be composed of other structs. This makes it
impractical to express using query params, meaning GET isn't an option.

The Aptos nodes prune account state history, via a configurable time window.
If the requested ledger version has been pruned, the server responds with a 410.

table_handle

Get a table item at a specific ledger version from the table identified by {table_handle}
in the path and the "key" (RawTableItemRequest) provided in the request body.

The `get_raw_table_item` requires only a serialized key comparing to the full move type information
comparing to the `get_table_item` api, and can only return the query in the bcs format.

The Aptos nodes prune account state history, via a configurable time window.
If the requested ledger version has been pruned, the server responds with a 410.

Retrieve on-chain committed transactions. The page size and start ledger version
can be provided to get a specific sequence of transactions.

If the version has been pruned, then a 410 will be returned.

To retrieve a pending transaction, use /transactions/by_hash.

Ledger version to start list of transactions

If not provided, defaults to showing the latest transactions

This endpoint accepts transaction submissions in two formats.

To submit a transaction as JSON, you must submit a SubmitTransactionRequest.
To build this request, do the following:

1. Encode the transaction as BCS. If you are using a language that has
native BCS support, make sure of that library. If not, you may take
advantage of /transactions/encode_submission. When using this
endpoint, make sure you trust the node you're talking to, as it is
possible they could manipulate your request.
2. Sign the encoded transaction and use it to create a TransactionSignature.
3. Submit the request. Make sure to use the "application/json" Content-Type.

To submit a transaction as BCS, you must submit a SignedTransaction
encoded as BCS. See SignedTransaction in types/src/transaction/mod.rs.
Make sure to use the `application/x.aptos.signed_transaction+bcs` Content-Type.

This allows you to submit multiple transactions.  The response has three outcomes:

1. All transactions succeed, and it will return a 202
2. Some transactions succeed, and it will return the failed transactions and a 206
3. No transactions succeed, and it will also return the failed transactions and a 206

To submit a transaction as JSON, you must submit a SubmitTransactionRequest.
To build this request, do the following:

1. Encode the transaction as BCS. If you are using a language that has
native BCS support, make sure to use that library. If not, you may take
advantage of /transactions/encode_submission. When using this
endpoint, make sure you trust the node you're talking to, as it is
possible they could manipulate your request.
2. Sign the encoded transaction and use it to create a TransactionSignature.
3. Submit the request. Make sure to use the "application/json" Content-Type.

To submit a transaction as BCS, you must submit a SignedTransaction
encoded as BCS. See SignedTransaction in types/src/transaction/mod.rs.
Make sure to use the `application/x.aptos.signed_transaction+bcs` Content-Type.

Look up a transaction by its hash. This is the same hash that is returned
by the API when submitting a transaction (see PendingTransaction).

When given a transaction hash, the server first looks for the transaction
in storage (on-chain, committed). If no on-chain transaction is found, it
looks the transaction up by hash in the mempool (pending, not yet committed).

To create a transaction hash by yourself, do the following:
1. Hash message bytes: "RawTransaction" bytes + BCS bytes of [Transaction](https://aptos-labs.github.io/aptos-core/aptos_types/transaction/enum.Transaction.html).
2. Apply hash algorithm `SHA3-256` to the hash message bytes.
3. Hex-encode the hash bytes with `0x` prefix.

txn_hash

Retrieves a transaction by a given version. If the version has been
pruned, a 410 will be returned.

txn_version

This endpoint accepts an EncodeSubmissionRequest, which internally is a
UserTransactionRequestInner (and optionally secondary signers) encoded
as JSON, validates the request format, and then returns that request
encoded in BCS. The client can then use this to create a transaction
signature to be used in a SubmitTransactionRequest, which it then
passes to the /transactions POST endpoint.

To be clear, this endpoint makes it possible to submit transaction
requests to the API from languages that do not have library support for
BCS. If you are using an SDK that has BCS support, such as the official
Rust, TypeScript, or Python SDKs, you do not need to use this endpoint.

To sign a message using the response from this endpoint:
- Decode the hex encoded string in the response to bytes.
- Sign the bytes to create the signature.
- Use that as the signature field in something like Ed25519Signature, which you then use to build a TransactionSignature.

The output of the transaction will have the exact transaction outputs and events that running
an actual signed transaction would have.  However, it will not have the associated state
hashes, as they are not updated in storage.  This can be used to estimate the maximum gas
units for a submitted transaction.

To use this, you must:
- Create a SignedTransaction with a zero-padded signature.
- Submit a SubmitTransactionRequest containing a UserTransactionRequest containing that signature.

To use this endpoint with BCS, you must submit a SignedTransaction
encoded as BCS. See SignedTransaction in types/src/transaction/mod.rs.

If set to true, the max gas value in the transaction will be ignored
and the maximum possible gas will be used

estimate_max_gas_amount

If set to true, the gas unit price in the transaction will be ignored
and the estimated value will be used

estimate_gas_unit_price

If set to true, the transaction will use a higher price than the original
estimate.

estimate_prioritized_gas_unit_price

Same as /transactions/by_hash, but will wait for a pending transaction to be committed. To be used as a long
poll optimization by clients, to reduce latency caused by polling. The "long" poll is generally a second or
less but dictated by the server; the client must deal with the result as if the request was a normal
/transactions/by_hash request, e.g., by retrying if the transaction is pending.

Execute the Move function with the given parameters and return its execution result.

The Aptos nodes prune account state history, via a configurable time window.
If the requested ledger version has been pruned, the server responds with a 410.