What is a Hedera mirror node?

Consensus nodes process transactions and establish their ordering and results. Mirror nodes consume the resulting data. A mirror node does not sign a transaction for your account or vote on its outcome.

An application can submit a transaction, receive its result and later read indexed data from a mirror node. Those steps have different timing and error conditions.

Common NFT queries include the owner of a serial, a collection's NFTs, an account's holdings and a serial's recorded transfer history. The REST API provides endpoints for these jobs.

Some responses contain lists split across pages. Others include encoded fields that need interpretation. Read the documented response rather than treating a JSON object as a complete portfolio or a finished NFT description.

A mirror node needs to ingest and index network data. A recent transaction can be confirmed before a particular provider's view reflects it.

An immediate empty response or missing result is therefore not enough to conclude that a submitted transaction failed. Keep the transaction ID and use the appropriate receipt or historical lookup for the operation.

Use the endpoint for the network you intend to query. The public endpoints documented by Hedera are useful for learning, but the operator guidance describes throttling and does not offer them as an unlimited production service.

For a production application, check the provider's coverage, retention, limits and service terms. Cache data where appropriate and tell users when a result is unavailable rather than showing a made-up zero.

A REST response is data returned by that provider. It is not automatically a cryptographic proof independently verified by your application. Nor does a token transfer automatically identify a sale or its commercial terms.

Try a read-only NFT query and compare the result with the same serial on SentX.

References: Hedera mirror nodes and documented mirror services.