Skip to main content

Overview

getTransactionsForAddress is a Helius-exclusive RPC method that returns an address’s transaction history with advanced filtering, flexible sorting, and efficient pagination. It is not part of standard Solana RPC. Unlike getSignaturesForAddress, which only returns signatures and skips associated token accounts, getTransactionsForAddress can return complete transaction data, including a wallet’s associated token account (ATA) activity, in a single call. That makes it the fastest path to a full address history for backfilling, indexing, and analytics. This method returns up to 1,000 full transactions per call.

Flexible sorting

Sort chronologically (oldest first) or reverse (newest first).

Advanced filtering

Filter by time ranges, slots, signatures, status, and token transfers.

Full transaction data

Get complete transaction details in one call, no follow-up getTransaction needed.

Token accounts

Include transactions for an address’s associated token accounts.

When to use this

Use getTransactionsForAddress when you need:
  • Complete wallet token history, including associated token accounts
  • A fast single-call backfill for an indexer or data pipeline
  • Time-based or slot-based transaction analysis and reporting
  • Status filtering to keep only succeeded or only failed transactions
  • Chronological historical replay (oldest-first ordering)
  • Token launch analysis: first mint transactions and early holders
  • Wallet funding history and counterparty discovery
  • Compliance and audit reports for a specific time period
For parsed, transfer-only history (payments, balance reconciliation), use getTransfersByAddress instead.

Network support

Quickstart

1

Get your API key

Obtain your API key from the Helius Dashboard.
2

Query with advanced features

Get all successful transactions for a wallet between two dates, sorted chronologically:
3

Understand the parameters

This example shows the key features:
  • transactionDetails: set to 'full' to get complete transaction data in one call
  • sortOrder: use 'asc' for chronological order (oldest first) or 'desc' for newest first
  • filters.blockTime: set time ranges with gte (greater than or equal) and lte (less than or equal)
  • filters.status: filter to only 'succeeded' or 'failed' transactions
  • filters.tokenAccounts: include transfers, mints, and burns for associated token accounts

Request parameters

string
required
Base-58 encoded public key of the account to query transaction history for
string
default:"signatures"
Level of transaction detail to return:
  • signatures: Basic signature info (faster)
  • full: Complete transaction data (eliminates need for getTransaction calls, supports limit up to 1,000)
string
default:"desc"
Sort order for results:
  • desc: Newest first (default)
  • asc: Oldest first (chronological, great for historical analysis)
number
default:"1000"
Maximum transactions to return:
  • Up to 1000 when transactionDetails: "signatures"
  • Up to 1000 when transactionDetails: "full"
string
Pagination token from previous response (format: "slot:position")
string
default:"finalized"
Commitment level: finalized or confirmed. The processed commitment is not supported.
object
Advanced filtering options for narrowing down results.
object
Filter by slot number using comparison operators: gte, gt, lte, ltExample: { "slot": { "gte": 1000, "lte": 2000 } }
object
Filter by Unix timestamp using comparison operators: gte, gt, lte, lt, eqExample: { "blockTime": { "gte": 1640995200, "lte": 1641081600 } }
object
Filter by transaction signature using comparison operators: gte, gt, lte, ltExample: { "signature": { "lt": "SIGNATURE_STRING" } }
string
Filter by transaction success/failure status:
  • succeeded: Only successful transactions
  • failed: Only failed transactions
  • any: Both successful and failed (default)
Example: { "status": "succeeded" }
string
default:"none"
Filter transactions for related token accounts:
  • none: Only return transactions that reference the provided address (default)
  • balanceChanged: Return transactions that reference either the provided address or modify the balance of a token account owned by the provided address (recommended)
  • all: Return transactions that reference either the provided address or any token account owned by the provided address
Example: { "tokenAccounts": "balanceChanged" }
object
Filter to transactions where the queried address participated in a token transfer matching a counterparty, direction, mint, or raw amount range. All fields are optional and combined with AND semantics.Example: { "tokenTransfer": { "direction": "in", "mint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v" } }
string
Counterparty address. Matches transfers whose other side is this address.
string
default:"any"
Filter by transfer direction relative to the queried address:
  • in: Transfers received by the queried address
  • out: Transfers sent by the queried address
  • any: Incoming and outgoing transfers
string
Token mint to filter on.
object
Amount comparison using the raw on-chain amount, not the UI or decimal-adjusted amount. Supports gt, gte, lt, and lte.
string
Encoding format for transaction data (only applies when transactionDetails: "full"). Same as getTransaction API. Options: json, jsonParsed, base64, base58
number
Set the max transaction version to return. If omitted, only legacy transactions will be returned. Set to 0 to include all versioned transactions.
number
The minimum slot that the request can be evaluated at

Metering

Successful responses are metered by what is returned:

Response

The response shape depends on transactionDetails. Signatures mode returns lightweight signature records; full mode returns complete transaction and metadata objects.

Response fields

The transactionIndex field is exclusive to getTransactionsForAddress. Other similar endpoints like getSignaturesForAddress, getTransaction, and getTransactions do not include this field. In full mode, meta is the complete transaction metadata object — identical in shape to what getTransaction returns. It includes preTokenBalances and postTokenBalances, so you can compute token balance changes (for example, to detect swaps) directly from the response without any follow-up calls.

Filters

You can use comparison operators for slot, blockTime, and signature, plus the special status, tokenAccounts, and tokenTransfer filters. Combining multiple filters narrows the result to their intersection.

Comparison operators

These operators work like database queries to give you precise control over your data range.

Enum filters

Combined filter examples:

Associated token accounts

On Solana, a wallet doesn’t hold tokens directly. Instead, the wallet owns token accounts, and those token accounts hold the tokens. When someone sends you USDC, it goes to your USDC token account, not your main wallet address. This method is unique because it can query complete token history, including a wallet’s associated token accounts (ATAs). Native RPC methods such as getSignaturesForAddress do not include ATAs. The tokenAccounts filter controls this behavior:
  • none (default): Only returns transactions that directly reference the wallet address. Use this when you only care about direct wallet interactions.
  • balanceChanged (recommended): Returns transactions that reference the wallet address or modify the balance of a token account owned by the wallet. This filters out spam and unrelated operations like fee collections or delegations, giving you a clean view of meaningful wallet activity.
  • all: Returns all transactions that reference the wallet address or any token account owned by the wallet.
The tokenAccounts filter does not support transactions prior to December 2022. It depends on token transfer metadata introduced to Solana on slot 111,491,819. To cover earlier activity, see the historical token account workaround.

Token transfer filter

The tokenTransfer filter narrows results to transactions where the queried address participated in a token transfer matching specific criteria: a particular counterparty, mint, direction, or amount range. Use it to answer questions like:
  • When did this wallet receive USDC from a specific counterparty?
  • Show every outgoing transfer above 1,000 tokens.
  • When did this wallet ever touch this specific mint?
The filter is an optional field inside the filters object of the request config:
All fields inside tokenTransfer are optional. Combining multiple fields is treated as AND. Amount range operators: You can combine amount operators, such as { "gte": 1000000, "lte": 5000000 } for a closed range. tokenTransfer composes with the other top-level filters (slot, blockTime, status, and tokenAccounts); the final result is the intersection.

Examples

Time-based analytics

Generate monthly transaction reports:
Process for analytics:

Token mint creation

Find the mint creation transaction for a specific token:
For liquidity pool creation, query the pool address:
This finds the exact moment a token mint or liquidity pool was created, including the creator address and initial parameters.

Funding transactions

Find who funded a specific address:
Then analyze the transaction data to find SOL transfers:
The first few transactions often reveal the funding source and can help identify related addresses or funding patterns.

Token transfers

Filter by tokenTransfer to isolate specific token movements. USDC inflows to an address:
Large outgoing transfers to a specific counterparty:
Combined with slot range and status:

Pagination

When you have more transactions than your limit, use the paginationToken from the response to fetch the next page. The token is a simple string in the format "slot:position" that tells the API where to continue from. Use the pagination token from each response to fetch the next page:

Multiple addresses

You cannot query multiple addresses in a single request. Each address query counts as a separate API request and is metered accordingly. To fetch transactions for multiple addresses, query each address within the same time or slot window, then merge and sort:
For larger history scans, iterate through time or slot windows (e.g., 1000 slots at a time) and repeat this pattern.

Best practices

Performance. Use transactionDetails: "signatures" when you don’t need full transaction data. Use reasonable page sizes for better response times, and filter by time ranges or specific slots for more targeted queries. Filtering. Start with broad filters and narrow down progressively. Use time-based filters for analytics and reporting workflows, and combine multiple filters for precise queries that target specific transaction types or time periods. Pagination. Store pagination tokens when you need to resume large queries later. Monitor pagination depth for performance planning, and use ascending order when you need to replay historical events in chronological order. Error handling. Handle rate limits gracefully with exponential backoff. Validate addresses before making requests, and cache results when appropriate to reduce API usage.

Limitations and edge cases

A small set of addresses route to legacy archival, are limited to slot-scan fallback, or return empty. Token-account discovery before slot 111,491,819 also requires a workaround. Expand the sections below for the full details.
Routed to old archival. Requests for these addresses are routed to our old archival system.Slot-scan fallback. Requests for these addresses are forwarded to our new archival system, and are queryable through a slot-by-slot scan approach (max 100 slots). However, this data is not indexed.Returns empty (is_reserved_address). Requests are forwarded to our new archival system, however the data is not indexed, and queries return empty.
For addresses with token account activity before slot 111,491,819, the tokenAccounts filter cannot determine ownership because the owner field in token balance metadata didn’t exist yet. To get complete results, you can discover those token accounts manually by parsing early transaction instructions, then query getTransactionsForAddress in parallel for each one.

How is this different from getSignaturesForAddress?

If you’re familiar with the standard getSignaturesForAddress method, getTransactionsForAddress collapses multi-step workflows into a single call and adds filtering, sorting, and token-account support.

Get full transactions in one call

With getSignaturesForAddress, you need two steps:
With getTransactionsForAddress, it’s one call:

Get token history in one call

With getSignaturesForAddress, you need to first call getTokenAccountsByOwner and then query for every token account:
With getTransactionsForAddress you only need to set filters.tokenAccounts:

Additional capabilities

Chronological sorting

Sort transactions from oldest to newest with sortOrder: 'asc'.

Time-based filtering

Filter by time ranges using blockTime filters.

Status filtering

Get only successful or failed transactions with the status filter.

Simpler pagination

Use paginationToken instead of confusing before/until signatures.

Next steps

Indexing guide

Use getTransactionsForAddress to backfill and sync a Solana index.

getTransfersByAddress

Parsed, transfer-only history for payments and reconciliation.

API reference

Full request and response schema for getTransactionsForAddress.

Historical data overview

Compare all Solana historical data methods.