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
UsegetTransactionsForAddress 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
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) andlte(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 transactionsfailed: Only failed transactionsany: Both successful and failed (default)
{ "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
{ "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 addressout: Transfers sent by the queried addressany: 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, base58number
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 ontransactionDetails. Signatures mode returns lightweight signature records; full mode returns complete transaction and metadata objects.
- Signatures Response
- Full Transaction Response
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 forslot, 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 asgetSignaturesForAddress 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.
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
ThetokenTransfer 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?
filters object of the request config:
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:Token mint creation
Find the mint creation transaction for a specific token:Funding transactions
Find who funded a specific address:Token transfers
Filter bytokenTransfer to isolate specific token movements.
USDC inflows to an address:
Pagination
When you have more transactions than your limit, use thepaginationToken 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:Best practices
Performance. UsetransactionDetails: "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.Unsupported and specially-routed addresses
Unsupported and specially-routed addresses
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.Workaround: historical token account discovery (before slot 111,491,819)
Workaround: historical token account discovery (before slot 111,491,819)
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 standardgetSignaturesForAddress method, getTransactionsForAddress collapses multi-step workflows into a single call and adds filtering, sorting, and token-account support.
Get full transactions in one call
WithgetSignaturesForAddress, you need two steps:
getTransactionsForAddress, it’s one call:
Get token history in one call
WithgetSignaturesForAddress, you need to first call getTokenAccountsByOwner and then query for every token account:
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.