> ## Documentation Index > Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Migrate from getSignaturesForAddress + getTransaction to getTransactionsForAddress > Replace the getSignaturesForAddress + getTransaction loop with a single getTransactionsForAddress call. Includes parameter mapping, before/after code, pagination changes, and a copy-paste AI agent prompt that automates the migration. ## Why migrate? The standard way to fetch an address's transaction history on Solana takes two steps: call `getSignaturesForAddress` to list signatures, then call `getTransaction` once per signature to fetch the details. For 1,000 transactions, that is 1,001 HTTP requests. [`getTransactionsForAddress`](/docs/rpc/gettransactionsforaddress) is a Helius-exclusive RPC method that collapses both steps into one call. It returns up to 1,000 full transactions per request, with filtering, bidirectional sorting, and token-account support that the standard methods don't have. | | `getSignaturesForAddress` + `getTransaction` | `getTransactionsForAddress` | | -------------------------------------- | -------------------------------------------- | ------------------------------------- | | Requests for 1,000 transactions | 1,001 | 1 | | Credits for 1,000 full transactions | \~1,001 (1 credit per call) | 100 (10 credits per 100 transactions) | | Associated token account (ATA) history | Not included | Included via `filters.tokenAccounts` | | Time and slot range filters | No | Yes | | Status filter (succeeded/failed) | No | Yes | | Sort order | Newest first only | Newest or oldest first | | Pagination | `before`/`until` signatures | `paginationToken` | The result: roughly 10x fewer credits, 1,000x fewer round trips, and no client-side batching, rate-limit handling, or retry logic for the `getTransaction` fan-out. ## Before and after Here is the same task — fetch the last 1,000 transactions for an address with full details — in both patterns: ```javascript Before (two methods) theme={"system"} const rpcUrl = 'https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY'; // Step 1: Get signatures (1 request) const sigResponse = await fetch(rpcUrl, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'getSignaturesForAddress', params: ['YOUR_ADDRESS_HERE', { limit: 1000 }] }) }); const { result: signatures } = await sigResponse.json(); // Step 2: Get transaction details (1,000 additional requests) const transactions = await Promise.all( signatures.map(async (sig) => { const txResponse = await fetch(rpcUrl, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'getTransaction', params: [sig.signature, { maxSupportedTransactionVersion: 0 }] }) }); const { result } = await txResponse.json(); return result; }) ); ``` ```javascript After (one method) theme={"system"} const response = await fetch('https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'getTransactionsForAddress', params: [ 'YOUR_ADDRESS_HERE', { transactionDetails: 'full', maxSupportedTransactionVersion: 0, limit: 1000 } ] }) }); const { result } = await response.json(); const transactions = result.data; // Full transactions, same shape as getTransaction ``` `getTransactionsForAddress` is not part of standard Solana RPC, so `@solana/web3.js` has no `Connection` helper for it. Call it with a raw JSON-RPC request as shown above — it works on the same Helius endpoint as the rest of your RPC traffic. ## Parameter mapping Every option from the old two-step flow has a direct equivalent. Most names carry over unchanged — only pagination works differently. ### From getSignaturesForAddress | Old option | New equivalent | | ---------------- | ---------------------------------------------------------------------------- | | `limit` | `limit` — same 1,000 maximum | | `before` | `paginationToken` from the previous response | | `until` | `filters.signature.gt` | | `commitment` | `commitment` — `confirmed` or `finalized` only; `processed` is not supported | | `minContextSlot` | `minContextSlot` — unchanged | ### From getTransaction | Old option | New equivalent | | -------------------------------- | ---------------------------------------------------------- | | `encoding` | `encoding` — applies when `transactionDetails` is `"full"` | | `maxSupportedTransactionVersion` | `maxSupportedTransactionVersion` — unchanged | | `commitment` | `commitment` — same rule as above | Two capabilities have no old equivalent at all: * `filters` — narrow results by `blockTime`, `slot`, `status`, `tokenTransfer`, or `tokenAccounts` server-side instead of fetching everything and filtering in your code. * `sortOrder: "asc"` — chronological (oldest-first) results, which the standard methods can't return without fetching the entire history and reversing it. ## Migration steps `getTransactionsForAddress` is Helius-exclusive. It works on `https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY` (and devnet) — the same endpoint your existing calls already use if you're a Helius customer. No API key or plan changes are needed. Delete the `getSignaturesForAddress` call and the `getTransaction` loop. Make a single `getTransactionsForAddress` request with `transactionDetails: "full"`, carrying over your `encoding`, `maxSupportedTransactionVersion`, and `commitment` values as shown in the [parameter mapping](#parameter-mapping). If you only need signatures (for example, to feed an existing pipeline), use `transactionDetails: "signatures"` instead — it costs 10 credits flat per call. The response envelope changes in three ways: * Results live in `result.data` (an array), not directly in `result`. * Each full-mode entry is `{ slot, transactionIndex, blockTime, transaction, meta }`. The `transaction` and `meta` objects are identical in shape to what `getTransaction` returns, so your parsing code carries over unchanged. * Signatures-mode entries match `getSignaturesForAddress` output (`signature`, `slot`, `err`, `memo`, `blockTime`, `confirmationStatus`) plus a new `transactionIndex` field. One behavioral difference to keep: with the old pattern, a `getTransaction` call could return `null` for a signature. With `getTransactionsForAddress`, every entry in `result.data` is a complete transaction — remove any null-handling for missing details. Swap the `before` cursor loop for `paginationToken`: ```javascript theme={"system"} let paginationToken = null; const allTransactions = []; do { const response = await fetch('https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'getTransactionsForAddress', params: [ 'YOUR_ADDRESS_HERE', { transactionDetails: 'full', maxSupportedTransactionVersion: 0, limit: 1000, ...(paginationToken && { paginationToken }) } ] }) }); const { result } = await response.json(); allTransactions.push(...result.data); paginationToken = result.paginationToken; } while (paginationToken); ``` The loop ends when `paginationToken` is `null` — no more comparing signature lists or tracking the last signature yourself. If you used `until` to stop at a known signature, replace it with `filters.signature: { gt: "KNOWN_SIGNATURE" }`. If you used it to stop at a point in time, `filters.blockTime` or `filters.slot` is usually a cleaner fit. The old pattern misses associated token account (ATA) activity entirely unless you also called `getTokenAccountsByOwner` and fetched signatures for every token account. To include it, add one filter: ```json theme={"system"} { "filters": { "tokenAccounts": "balanceChanged" } } ``` `balanceChanged` returns transactions that reference the wallet or change the balance of any token account it owns, filtering out spam. See [associated token accounts](/docs/rpc/gettransactionsforaddress#associated-token-accounts) for the `none`/`balanceChanged`/`all` options and the pre-2022 caveat. For a sample address, fetch history both ways and compare the signature sets. With `filters.tokenAccounts` unset (the default `none`), `getTransactionsForAddress` returns the same transactions as `getSignaturesForAddress` for the same range. Then deploy and remove the old code path. ## Behavior differences to review Most migrations are a drop-in replacement, but check these before shipping: * **Commitment.** `processed` is not supported; use `confirmed` or `finalized`. If your old code polled recent history at `processed`, switch to `confirmed`. * **Metering.** Full-transaction responses cost 10 credits per 100 returned transactions (10-credit minimum); signatures-only responses cost 10 credits flat. The old pattern cost 1 credit per call — cheaper per request, but far more expensive per transaction fetched. Failed responses are free. See [metering](/docs/rpc/gettransactionsforaddress#metering). * **Network support.** Mainnet has unlimited retention. Devnet is supported with 2 weeks of retention. Testnet is not supported. * **Reserved addresses.** A small set of system addresses (Vote Program, System Program, sysvars) route to fallback archival paths or return empty. If you index those, review [limitations and edge cases](/docs/rpc/gettransactionsforaddress#limitations-and-edge-cases). * **Multiple addresses.** Like the old flow, one request covers one address. Query addresses in parallel and merge; see [multiple addresses](/docs/rpc/gettransactionsforaddress#multiple-addresses). ## Frequently asked questions ### Is getTransactionsForAddress a standard Solana RPC method? No. It is a Helius-exclusive method available on Helius RPC endpoints. Standard Solana RPC and other providers only offer `getSignaturesForAddress` and `getTransaction`. Your other RPC calls are unaffected — the method lives on the same endpoint alongside the full standard RPC surface. ### Do I still need getTransaction after migrating? Only for one-off lookups where you already have a signature and no address context, such as verifying a specific transaction a user pasted in. For any address-based history — backfills, indexing, wallet activity feeds — `getTransactionsForAddress` replaces both methods. ### Does it work with @solana/web3.js? The method isn't in the `Connection` class, but it works with any HTTP client against your Helius RPC URL. Use `fetch` (or your language's equivalent) with a standard JSON-RPC body, as shown in the examples above. You can keep using `Connection` for everything else. ### Will it return the same transactions as getSignaturesForAddress? Yes. With default settings (`filters.tokenAccounts: "none"`), it returns transactions that reference the queried address — the same set as `getSignaturesForAddress`. Setting `tokenAccounts` to `balanceChanged` or `all` returns more: it adds activity from the wallet's associated token accounts, which the standard method cannot see. ### How much does it cost compared to the old pattern? Fetching 1,000 full transactions costs 100 credits with `getTransactionsForAddress` versus roughly 1,001 credits (and 1,001 requests) with `getSignaturesForAddress` + `getTransaction`. Signatures-only responses cost 10 credits flat per call. See [Helius credits](/docs/billing/credits) for full pricing. ## Let an AI agent do the migration If you use Claude Code, Cursor, or another coding agent, paste the prompt below into your repository's agent session. It finds the old pattern in your codebase and rewrites it. ````markdown theme={"system"} Migrate this codebase from the two-step Solana transaction history pattern (getSignaturesForAddress followed by getTransaction) to the single Helius RPC method getTransactionsForAddress. ## Background getTransactionsForAddress is a Helius-exclusive JSON-RPC method served on standard Helius RPC endpoints (https://mainnet.helius-rpc.com/?api-key=...). It returns up to 1,000 full transactions per call, replacing one getSignaturesForAddress call plus one getTransaction call per signature. Docs: https://www.helius.dev/docs/rpc/gettransactionsforaddress.md ## Step 1: Find the old pattern Search for: - getSignaturesForAddress calls (via @solana/web3.js Connection, raw JSON-RPC, or another SDK) whose signatures are then passed to getTransaction / getParsedTransaction / getTransactions - Pagination loops using `before` or `until` signature cursors - getTokenAccountsByOwner calls used only to fetch per-token-account signature history Leave standalone getTransaction calls (single-signature lookups with no address context) unchanged. ## Step 2: Rewrite each call site Replace the two-step flow with one raw JSON-RPC request (web3.js has no Connection helper for this method): ```javascript const response = await fetch(HELIUS_RPC_URL, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'getTransactionsForAddress', params: [ address, // base-58 string { transactionDetails: 'full', // or 'signatures' if only signatures were used maxSupportedTransactionVersion: 0, // carry over from the old getTransaction options encoding: 'json', // carry over ('json', 'jsonParsed', 'base64', 'base58') limit: 1000, // up to 1,000 // paginationToken: '...', // from the previous response, for page 2+ // sortOrder: 'desc', // 'desc' (default, newest first) or 'asc' // filters: { ... } // optional, see mapping below } ] }) }); const { result } = await response.json(); // result.data -> array of transactions // result.paginationToken -> string cursor, or null when done ``` Parameter mapping: - limit -> limit - before: -> paginationToken (preferred) or filters: { signature: { lt: } } - until: -> filters: { signature: { gt: } } - commitment -> commitment ('confirmed' or 'finalized' only; if the old code used 'processed', use 'confirmed') - minContextSlot -> minContextSlot - encoding / maxSupportedTransactionVersion (from getTransaction) -> same names, top level of the config object Response shape: - Full mode: each entry is { slot, transactionIndex, blockTime, transaction, meta }. transaction and meta are identical in shape to getTransaction results, so existing parsing code carries over. Entries are never null - remove null-handling that existed for missing getTransaction results. - Signatures mode: entries match getSignaturesForAddress output ({ signature, slot, err, memo, blockTime, confirmationStatus }) plus transactionIndex. Pagination: loop while result.paginationToken is non-null, passing it back as paginationToken. Remove manual last-signature tracking. If the old code fetched signatures for the wallet's token accounts too (getTokenAccountsByOwner + per-account getSignaturesForAddress), replace all of it with one call using filters: { tokenAccounts: 'balanceChanged' } and delete the merge/dedupe logic. ## Step 3: Constraints and cleanup - The endpoint must be a Helius RPC URL; other providers do not serve this method. Do not change endpoints for other RPC calls. - Remove now-unused batching, throttling, and retry helpers that existed only for the getTransaction fan-out. - One request covers one address; keep parallel queries for multi-address code. - Preserve the surrounding code style and error handling conventions. ## Step 4: Verify - Run the project's type checks and tests. - Do NOT make any RPC calls yourself. Instead, write a standalone script (e.g. scripts/verify-gtfa-migration.mjs) that fetches history for one address both ways - the old getSignaturesForAddress + getTransaction flow and the new getTransactionsForAddress call with default filters - and prints whether the signature sets match, listing any differences. Read the RPC URL from an environment variable and the address from a CLI argument; never hardcode an API key. - Tell the user how to run it, for example: HELIUS_RPC_URL="https://mainnet.helius-rpc.com/?api-key=..." \ node scripts/verify-gtfa-migration.mjs
- Summarize every call site changed and flag any you were unsure about. ```` The prompt is self-contained — the agent doesn't need access to this page. For agent-ready docs, MCP search, and skills, see [Helius for AI agents](/docs/agents/overview). ## Next steps Full tutorial covering filters, sorting, pagination, and token accounts. Complete request and response schema. Use getTransactionsForAddress to backfill and sync a Solana index. Compare all Solana historical data methods.