Skip to main content

getTransaction

Returns transaction details for a confirmed transaction

Common use cases
Transaction Confirmation VerificationMonitor transaction status after sendTransaction by fetching full transaction details including confirmation slot, block time, and execution success/failure. Use commitment: "confirmed" for fast feedback or commitment: "finalized" for irreversible certainty. Essential workflow: send tx → poll getSignatureStatuses → getTransaction for complete metadata.
Block Explorer Transaction DisplayRetrieve human-readable transaction data for explorer UIs showing instruction details, account interactions, and token transfers. Use encoding: "jsonParsed" to get decoded instruction names and parameters, plus maxSupportedTransactionVersion: 0 to support versioned transactions with address lookup tables.
Transaction Debugging and AnalysisInspect failed transactions to diagnose errors by examining pre/post balances, compute units consumed, log messages, and inner instructions. Transaction meta object includes err field with error details, fee charged, and logMessages array showing program execution trace for debugging smart contract interactions.
Historical Transaction ArchivalFetch and store historical transaction data for audit trails, tax reporting, or portfolio tracking. Query recent signatures with getSignaturesForAddress, then retrieve full transaction details. Note: Transactions older than node's ledger history return null - requires archival RPC nodes for complete historical data.
Real-Time Transaction MonitoringSubscribe to transaction events via signatureSubscribe (WebSocket) or onLogs, then fetch complete transaction details with getTransaction when signature appears. Common pattern for DEX monitoring, NFT mint tracking, or wallet activity feeds where log filtering identifies relevant transactions before full retrieval.

Parameters​

signature (string, required)

Transaction signature, as base-58 encoded string

config (object, optional)

Configuration object containing the following fields:

Fields:

  • commitment (string): The commitment describes how finalized a block is at that point in time. See Configuring State Commitment.
    • processed is not supported.
  • maxSupportedTransactionVersion (number): Currently, the only valid value for this parameter is 0. Setting it to 0 allows you to fetch all transactions, including both Versioned and legacy transactions. This parameter determines the maximum transaction version that will be returned in the response. If you request a transaction with a higher version than this value, an error will be returned. If you omit this parameter, only legacy transactions will be returned—any versioned transaction will result in an error.
  • encoding (string): Encoding for the returned Transaction
    • jsonParsed encoding attempts to use program-specific state parsers to return more human-readable and explicit data in the transaction.message.instructions list.
    • If jsonParsed is requested but a parser cannot be found, the instruction falls back to regular JSON encoding (accounts, data, and programIdIndex fields).

Request​

curl https://solana-mainnet.api.syndica.io/api-key/YOUR_API_KEY \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getTransaction",
  "params": [
    "5Pj5fCupXLUePYn18JkY8SrRaWFiUctuDTRwvUy2ML9yvkENLb1QMYbcBGcBXRrSVDjp7RjUwk9a3rLC6gpvtYpZ",
    {
      "commitment": "confirmed",
      "maxSupportedTransactionVersion": 0,
      "encoding": "json"
    }
  ]
}'
Network Selection

Replace mainnet with devnet in the URL to query devnet instead.

Response​

{
  "jsonrpc": "2.0",
  "result": {
    "blockTime": 1746479684,
    // !collapse(1:30) collapsed
    "meta": {
      "computeUnitsConsumed": 150,
      "err": null,
      "fee": 5000,
      "innerInstructions": [],
      "loadedAddresses": {
        "readonly": [],
        "writable": []
      },
      "logMessages": [
        "Program 11111111111111111111111111111111 invoke [1]",
        "Program 11111111111111111111111111111111 success"
      ],
      "postBalances": [
        989995000,
        10000000,
        1
      ],
      "postTokenBalances": [],
      "preBalances": [
        1000000000,
        0,
        1
      ],
      "preTokenBalances": [],
      "rewards": [],
      "status": {
        "Ok": null
      }
    },
    "slot": 378917547,
    // !collapse(1:29) collapsed
    "transaction": {
      "message": {
        "accountKeys": [
          "7BvfixZx7Rwywf6EJFgRW6acEQ2FLSFJr4n3kLLVeEes",
          "6KtbxYovphtE3eHjPjr2sWwDfgaDwtAn2FcojDyzZWT6",
          "11111111111111111111111111111111"
        ],
        "header": {
          "numReadonlySignedAccounts": 0,
          "numReadonlyUnsignedAccounts": 1,
          "numRequiredSignatures": 1
        },
        "instructions": [
          {
            "accounts": [
              0,
              1
            ],
            "data": "3Bxs4NN8M2Yn4TLb",
            "programIdIndex": 2,
            "stackHeight": null
          }
        ],
        "recentBlockhash": "23dwTHxFhSzqohXhdni5LwpuSRpgN36YvVMCAM2VXQSf"
      },
      "signatures": [
        "5Pj5fCupXLUePYn18JkY8SrRaWFiUctuDTRwvUy2ML9yvkENLb1QMYbcBGcBXRrSVDjp7RjUwk9a3rLC6gpvtYpZ"
      ]
    },
    "version": "legacy"
  },
  "id": 1
}

Response Fields​

blockTime (i64 | null)

Estimated production time, as Unix timestamp (seconds since the Unix epoch) of when the transaction was processed. null if not available

meta (object | null)

Transaction status metadata object or null.

slot (u64)

The slot this transaction was processed in

transaction (object | [string,encoding])

Transaction object, either in JSON format or encoded binary data, depending on encoding parameter

version ("legacy" | number | undefined)

Transaction version. Undefined if maxSupportedTransactionVersion is not set in request params.

FAQ and Troubleshooting​

Why does getTransaction return null even though the transaction succeeded?

The transaction signature predates the RPC node's ledger history cutoff. Standard RPC nodes only retain recent ledger data (varies by node, typically weeks). Solutions: (1) Query an archival RPC node with full history, (2) For recent transactions, ensure using commitment: "confirmed" or higher as processed-level transactions aren't queryable, (3) Verify signature hasn't been finalized yet if query is immediate after sendTransaction.

Why am I getting error -32015 'Transaction version (0) is not supported by the requesting client'?

The transaction uses versioned transaction format (v0 with address lookup tables) but request is missing maxSupportedTransactionVersion parameter. Add "maxSupportedTransactionVersion": 0 to your request config. This parameter is required for any transaction using v0 format. Legacy transactions (pre-v0) work without this parameter but mixed blocks require it.

What's the difference between encoding options (json, jsonParsed, base64, base58)?

json returns structured transaction with instruction data as base58/base64 strings - most efficient for programmatic parsing. jsonParsed attempts to decode known program instructions into human-readable format (e.g., "transfer" instead of raw bytes) - ideal for UIs but not all programs supported. base64/base58 return raw binary transaction - use for re-broadcasting or compact storage. Default is json. Note: jsonParsed falls back to json for unparseable instructions.

Why am I getting JSON parse error (-32700) with getTransaction?

Common causes: (1) Missing quotes around encoding value - use "encoding": "json" not "encoding: "json", (2) Passing encoding as string instead of config object in second parameter - both ["signature", "json"] and ["signature", {"encoding": "json"}] are valid but must be properly formatted, (3) Invalid JSON structure in request body. Validate JSON syntax with linter before sending RPC requests.

How long should I wait before calling getTransaction after sendTransaction?

getTransaction requires commitment: "confirmed" minimum (cannot query processed-level transactions). On healthy network, transactions confirm in 400ms-2s. Recommended pattern: (1) sendTransaction returns signature immediately, (2) Poll getSignatureStatuses with commitment: "confirmed" every 500ms-1s until confirmed/finalized, (3) Once confirmed status detected, call getTransaction to fetch full details. Don't repeatedly call getTransaction for polling - use getSignatureStatuses or signatureSubscribe instead for status monitoring.

sendTransaction
Submits signed transaction to cluster and returns signature. Primary precursor to getTransaction - typical workflow is sendTransaction to broadcast, then poll getSignatureStatuses for confirmation status, then getTransaction to fetch full transaction details including logs, balances, and execution results.

getSignatureStatuses
Polls transaction confirmation status and errors without fetching full transaction data. More efficient than getTransaction for confirmation monitoring - use getSignatureStatuses to detect when transaction reaches desired commitment level, then call getTransaction once to retrieve complete details if needed.

getBlock
Retrieves block containing multiple transactions at specified slot. Similar maxSupportedTransactionVersion requirement for versioned transactions. Use getBlock when processing entire blocks for indexing, then extract signatures and optionally call getTransaction for individual transaction details not included in block response.

signatureSubscribe
WebSocket subscription for real-time transaction confirmation notifications. More efficient than polling getTransaction or getSignatureStatuses - subscribe after sendTransaction, receive notification when confirmed, then optionally call getTransaction to fetch full metadata. Preferred for monitoring multiple transactions simultaneously.

getSignaturesForAddress
Returns list of transaction signatures for a specific address, ordered by slot. Common precursor to getTransaction when analyzing account history - fetch signature list with getSignaturesForAddress, then call getTransaction for each signature to retrieve full transaction details for historical analysis or auditing.

External Resources​