aws_sdk_managedblockchainquery

Module types

Source
Expand description

Data structures used by operation inputs/outputs.

Modules§

  • builders
    Builders
  • error
    Error types that Amazon Managed Blockchain Query can respond with.

Structs§

  • AddressIdentifierFilter

    This is the container for the unique public address on the blockchain.

  • AssetContract

    This container contains information about an contract.

  • BatchGetTokenBalanceErrorItem

    Error generated from a failed BatchGetTokenBalance request.

  • BatchGetTokenBalanceInputItem

    The container for the input for getting a token balance.

  • BatchGetTokenBalanceOutputItem

    The container for the properties of a token balance output.

  • BlockchainInstant

    The container for time.

  • ConfirmationStatusFilter

    The container for the ConfirmationStatusFilter that filters for the finality of the results.

  • ContractFilter

    The contract or wallet address by which to filter the request.

  • ContractIdentifier

    Container for the blockchain address and network information about a contract.

  • ContractMetadata

    The metadata of the contract.

  • ListFilteredTransactionEventsSort

    Lists all the transaction events for an address on the blockchain.

    This operation is only supported on the Bitcoin blockchain networks.

  • ListTransactionsSort

    The container for determining how the list transaction result will be sorted.

  • OwnerFilter

    The container for the owner information to filter by.

  • OwnerIdentifier

    The container for the owner identifier.

  • TimeFilter

    This container is used to specify a time frame.

  • TokenBalance

    The balance of the token.

  • TokenFilter

    The container of the token filter like the contract address on a given blockchain network or a unique token identifier on a given blockchain network.

    You must always specify the network property of this container when using this operation.

  • TokenIdentifier

    The container for the identifier for the token including the unique token ID and its blockchain network.

    Only the native tokens BTC and ETH, and the ERC-20, ERC-721, and ERC 1155 token standards are supported.

  • Transaction

    There are two possible types of transactions used for this data type:

    • A Bitcoin transaction is a movement of BTC from one address to another.

    • An Ethereum transaction refers to an action initiated by an externally owned account, which is an account managed by a human, not a contract. For example, if Bob sends Alice 1 ETH, Bob's account must be debited and Alice's must be credited. This state-changing action occurs within a transaction.

  • TransactionEvent

    The container for the properties of a transaction event.

  • TransactionOutputItem

    The container of the transaction output.

  • ValidationExceptionField

    The resource passed is invalid.

  • VoutFilter

    This container specifies filtering attributes related to BITCOIN_VOUT event types

Enums§

  • ConfirmationStatus
    When writing a match expression against ConfirmationStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • ErrorType
    When writing a match expression against ErrorType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • ExecutionStatus
    When writing a match expression against ExecutionStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • ListFilteredTransactionEventsSortBy
    When writing a match expression against ListFilteredTransactionEventsSortBy, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • ListTransactionsSortBy
    When writing a match expression against ListTransactionsSortBy, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • QueryNetwork
    When writing a match expression against QueryNetwork, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • QueryTokenStandard
    When writing a match expression against QueryTokenStandard, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • QueryTransactionEventType
    When writing a match expression against QueryTransactionEventType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • ResourceType
    When writing a match expression against ResourceType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • SortOrder
    When writing a match expression against SortOrder, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • ValidationExceptionReason
    When writing a match expression against ValidationExceptionReason, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.