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

Get transaction by version

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.


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

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

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

The writeset payload of the Genesis transaction

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.


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 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.

Payload which runs a script that can run multiple functions

An enum of the possible transaction payloads

An enum representing the different transaction signatures available

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.


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

Enum of the different types of transactions in Aptos
A transaction waiting in mempool

Enum of the different types of transactions in Aptos
A transaction submitted by a user to change the state of the blockchain

Enum of the different types of transactions in Aptos
The genesis transaction

This only occurs at the genesis transaction (version 0)

Enum of the different types of transactions in Aptos
A block metadata transaction

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

Enum of the different types of transactions in Aptos
A state checkpoint transaction

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

Modular Cloud

Learn more about Modular Cloud's Infinite Bazaar hackathon prize.

Hackathon

Modular Cloud's assets, logos, and brand guidelines.

Brand Guidelines

Get started with Modular Cloud's blockchain data APIs today.

Start Here

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

Get blocks by height

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

Get blocks by version

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.

Get account transactions

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.

Get transaction by hash

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.

Get transactions

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.

Get events by creation number

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.

Overview

Move

EVM

Get transaction by version

Path Parameters

Response