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

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

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.

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.

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

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

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

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.

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.

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.

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.
2. Apply hash algorithm SHA3-256 to the hash message bytes.
3. Hex-encode the hash bytes with 0x prefix.

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

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.

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.

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.

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.

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.

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.