Skip to main content
The Enhanced Transactions API is a legacy product in maintenance mode. It still works and these pages remain available, but it is not receiving new parser types or feature work. Its successor is Parsed Events, which decodes instructions through the IDL catalog and is in closed beta. You can also use getTransactionsForAddress for transaction history and backfill, and the Wallet API for human-readable wallet data.

Overview

The Transaction History endpoint returns human-readable transaction history for any Solana address. Instead of dealing with raw instruction data and account lists, you get structured information about:
  • What happened in the transaction (transfers, swaps, NFT activities).
  • Which accounts were involved.
  • How much SOL or how many tokens were transferred.
  • Associated metadata (token mint addresses, token names, token symbols, and more).
Send a GET request to /v0/addresses/{address}/transactions. Under the hood, this endpoint is powered by the getTransactionsForAddress RPC method.

When to use this

  • You are displaying an address’s transaction history to users (wallets, portfolio trackers, explorers).
  • You want pre-parsed, human-readable history without writing your own decoder.
  • You need to filter history by transaction type, time range, or slot range.
  • You need a wallet’s complete token history, including associated token accounts (ATAs) — see below.
For new builds, getTransactionsForAddress is the modern, Helius-native path with server-side filtering and token-account lookups.

Quickstart

1

Get your API key

Sign up at dashboard.helius.dev and copy your API key.
2

GET the address transactions endpoint

Retrieve transaction history for any Solana address.
3

Filter and paginate

Narrow results with the type, time, and slot filters below, then page through high-volume addresses with signature cursors.

Network support

Request parameters

Time-based filtering

Slot-based filtering

Filtering notes:
  • Time parameters use Unix timestamps (seconds since epoch); slot parameters use Solana slot numbers.
  • You cannot combine time-based and slot-based filters in the same request.
  • Use sort-order=asc for ascending (oldest first) or sort-order=desc for descending (newest first).
  • Use time or slot filters to reduce the search space when you know the approximate period, and pair them with limit to control page size.

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 rather than your main wallet address. This endpoint is unique because it can query a wallet’s complete token history, including associated token accounts (ATAs). Native RPC methods such as getSignaturesForAddress do not include ATAs. The token-accounts 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 token-accounts filter relies on the owner field in token balance metadata, which was not available before slot 111,491,819 (~December 2022). Transactions involving token accounts active before this slot may be missing from balanceChanged and all results. See the getTransactionsForAddress tutorial for a workaround with a full code example.

Filters

Filter by transaction type

Get only specific transaction types, such as NFT sales, token transfers, or swaps:
For the full list of supported transaction types, see the Transaction History API reference.

Runtime type filtering

Type filtering happens at runtime: the API searches transactions sequentially until it finds at least 50 matching items. If it cannot find any matches within the search window, it returns an error with a signature to continue the search from. This is expected behavior, not a failure.
When no matching transactions are found within the current search window, the API returns an error response like this:
To continue, use the signature from the error message with the appropriate parameter (before-signature for descending, after-signature for ascending) on your next request.
Key points:
  • The API searches through up to 50 transactions at a time when using type filters.
  • If no matches are found, use the signature from the error message to continue searching.
  • Use before-signature when searching in descending order (default, newest first).
  • Use after-signature when searching in ascending order (oldest first) — required for chronological searches.
  • Implement a maximum retry limit to prevent infinite loops.

Examples

The following scenarios cover time and slot ranges, sort order, ATAs, and combined filters.
Get transactions within a specific time window:
Get transactions within a specific slot range:
Get transactions in ascending order (oldest first):
Combine type filtering with a time range and custom sort order:

Pagination

For high-volume addresses, page through results using the last signature in each batch as the cursor:
To paginate within a time range, keep the time filters on every request and advance the before-signature cursor each loop:

Next steps

getTransactionsForAddress

The modern, Helius-native replacement for transaction history and backfill.

Wallet API

REST endpoints for human-readable wallet data: balances, history, and transfers.

Parse Transactions

Parse one or more transaction signatures into human-readable data.

Getting Data overview

Compare every Helius option for querying Solana data.