Helius Exclusive Feature -
getTransactionsForAddress is only available through Helius RPC nodes and is not part of standard Solana RPC. This endpoint requires a Developer plan or higher and costs 100 credits per request.Overview
getTransactionsForAddress provides powerful transaction history queries with advanced filtering, flexible sorting, and efficient pagination.
Key Features
Flexible sorting
Sort chronologically (oldest first) or reverse (newest first)
Advanced filtering
Filter by time ranges, slots, signatures, and transaction status
Full transaction data
Get complete transaction details in one call
Simple pagination
Easy pagination with slot:position tokens
Common Use Cases
This method is particularly useful for several scenarios. Token Launch Analysis helps track first mint transactions and early token holders for new projects. Wallet Funding History allows you to identify funding sources and transaction patterns for specific addresses. Transaction Analysis lets you filter by success/failure status to focus on completed transactions and exclude failed attempts. The API also supports Audit & Compliance workflows by generating transaction reports for specific time periods with status filtering. Analytics Dashboards can leverage the historical replay functionality to build comprehensive transaction analytics. Finally, Portfolio Tracking applications can access complete successful transaction history for DeFi portfolio management.Quick Start
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 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
Request Parameters
Base-58 encoded public key of the account to query transaction history for
Level of transaction detail to return:
signatures: Basic signature info (faster)full: Complete transaction data (eliminates need for getTransaction calls, requires limit ≤ 100)
Sort order for results:
desc: Newest first (default)asc: Oldest first (chronological, great for historical analysis)
Maximum transactions to return:
- Up to 1000 when
transactionDetails: "signatures" - Up to 100 when
transactionDetails: "full"
Pagination token from previous response (format:
"slot:position")Commitment level:
finalized, confirmed, or processedAdvanced filtering options for narrowing down results.
Filter by slot number using comparison operators:
gte, gt, lte, ltExample: { "slot": { "gte": 1000, "lte": 2000 } }Filter by Unix timestamp using comparison operators:
gte, gt, lte, lt, eqExample: { "blockTime": { "gte": 1640995200, "lte": 1641081600 } }Filter by transaction signature using comparison operators:
gte, gt, lte, ltExample: { "signature": { "lt": "SIGNATURE_STRING" } }Filter by transaction success/failure status:
succeeded: Only successful transactionsfailed: Only failed transactionsany: Both successful and failed (default)
{ "status": "succeeded" }Encoding format for transaction data (only applies when
transactionDetails: "full"). Same as getTransaction API. Options: json, jsonParsed, base64, base58Set the max transaction version to return. If omitted, only legacy transactions will be returned. Set to
0 to include all versioned transactions.The minimum slot that the request can be evaluated at
Filter Operators
When using filters, you can use comparison operators forslot, blockTime, or signature, plus a special status filter. These operators work like database queries to give you precise control over your data range.
Comparison Operators
| Operator | Full Name | Description | Example |
|---|---|---|---|
gte | Greater Than or Equal | Include values ≥ specified value | slot: { gte: 100 } |
gt | Greater Than | Include values > specified value | blockTime: { gt: 1641081600 } |
lte | Less Than or Equal | Include values ≤ specified value | slot: { lte: 2000 } |
lt | Less Than | Include values < specified value | blockTime: { lt: 1641168000 } |
eq | Equal | Include values exactly equal (only blockTime) | blockTime: { eq: 1641081600 } |
Status Filter
| Filter | Description | Values |
|---|---|---|
status | Filter transactions by success/failure | succeeded, failed, or any |
Response Format
- Signatures Response
- Full Transaction Response
Practical Examples
Time-Based Analytics
Generate monthly transaction reports:Token Mint Creation
Find the mint creation transaction for a specific token:Use Case: Find the exact moment when a token mint or liquidity pool was created, including the creator address and initial parameters.
Funding Transactions
Find who funded a specific address:The first few transactions often reveal the funding source and can help identify related addresses or funding patterns.
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.
How to Paginate
Use the pagination token from each response to fetch the next page:Best Practices
Performance
For optimal performance, usetransactionDetails: "signatures" when you don’t need full transaction data. Implement reasonable page sizes better response times, and consider filtering by time ranges or specific slots for more targeted queries.
Filtering
Start with broad filters and narrow down progressively to find the data you need. Use time-based filters for analytics and reporting workflows. You can combine multiple filters for precise queries that target specific transaction types or time periods.Pagination
Store pagination keys when you need to resume large queries later. Monitor pagination depth for performance planning, and use ascending order for scenarios where you need to replay historical events in chronological order.Error Handling
Handle rate limits gracefully with exponential backoff strategies. Always validate addresses before making requests, and cache results when appropriate to reduce API usage and improve application performance.How is this different from getSignaturesForAddress?
If you’re familiar with the standardgetSignaturesForAddress method, here are the key differences:
Get Full Transactions in One Call
WithgetSignaturesForAddress, you need two steps:
getTransactionsForAddress, it’s one call:
Additional Capabilities
Chronological sorting
Sort transactions from oldest to newest with
sortOrder: 'asc'Time-based filtering
Filter by time ranges using
blockTime filtersStatus filtering
Get only successful or failed transactions with
status filterSimpler pagination
Use
paginationToken instead of confusing before/until signatures