> ## 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. # Migrer de getSignaturesForAddress + getTransaction vers getTransactionsForAddress > Remplacez la boucle getSignaturesForAddress + getTransaction par un seul appel getTransactionsForAddress — correspondance des paramètres, code avant/après et pagination. ## Pourquoi migrer ? La manière standard de récupérer l'historique des transactions d'une adresse sur Solana nécessite deux étapes : appeler `getSignaturesForAddress` pour lister les signatures, puis appeler `getTransaction` une fois par signature pour récupérer les détails. Pour 1 000 transactions, cela représente 1 001 requêtes HTTP. [`getTransactionsForAddress`](/docs/fr/rpc/gettransactionsforaddress) est une méthode RPC exclusive à Helius qui regroupe les deux étapes en un seul appel. Elle renvoie jusqu'à 1 000 transactions complètes par requête, avec filtrage, tri bidirectionnel et prise en charge des comptes de jetons que les méthodes standard n'ont pas. | | `getSignaturesForAddress` + `getTransaction` | `getTransactionsForAddress` | | ------------------------------------------- | -------------------------------------------- | ------------------------------------------- | | Requêtes pour 1 000 transactions | 1 001 | 1 | | Crédits pour 1 000 transactions complètes | \~1 001 (1 crédit par appel) | 100 (10 crédits par 100 transactions) | | Historique du compte de jeton associé (ATA) | Non inclus | Inclus via `filters.tokenAccounts` | | Filtres de plage de temps et de slot | Non | Oui | | Filtre de statut (réussi/échoué) | Non | Oui | | Ordre de tri | Le plus récent en premier uniquement | Le plus récent ou le plus ancien en premier | | Pagination | `before`/`until` signatures | `paginationToken` | Résultat : environ 10 fois moins de crédits, 1 000 fois moins d'allers-retours, et pas de lotissement côté client, de gestion des limites de taux ou de logique de réessai pour la diffusion `getTransaction`. ## Avant et après Voici la même tâche — récupérer les 1 000 dernières transactions pour une adresse avec tous les détails — dans les deux modèles : ```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: 1 }] }) }); 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: 1, limit: 1000 } ] }) }); const { result } = await response.json(); const transactions = result.data; // Full transactions, same shape as getTransaction ``` `getTransactionsForAddress` ne fait pas partie du RPC standard de Solana, donc `@solana/web3.js` n'a pas de `Connection` d'aide pour cela. Appelez-le avec une requête JSON-RPC brute comme indiqué ci-dessus — cela fonctionne sur le même point de terminaison Helius que le reste de votre trafic RPC. ## Correspondance des paramètres Chaque option de l'ancien flux en deux étapes a un équivalent direct. La plupart des noms restent inchangés — seule la pagination fonctionne différemment. ### De getSignaturesForAddress | Ancienne option | Nouvel équivalent | | ---------------- | ------------------------------------------------------------------------------------------ | | `limit` | `limit` — même maximum de 1 000 | | `before` | `paginationToken` du précédent réponse | | `until` | `filters.signature.gt` | | `commitment` | `commitment` — `confirmed` ou `finalized` uniquement; `processed` n'est pas pris en charge | | `minContextSlot` | `minContextSlot` — inchangé | ### De getTransaction | Ancienne option | Nouvel équivalent | | -------------------------------- | ----------------------------------------------------------------- | | `encoding` | `encoding` — s'applique lorsque `transactionDetails` est `"full"` | | `maxSupportedTransactionVersion` | `maxSupportedTransactionVersion` — inchangé | | `commitment` | `commitment` — même règle que ci-dessus | Deux fonctionnalités n'ont pas d'équivalent ancien : * `filters` — affinez les résultats par `blockTime`, `slot`, `status`, `tokenTransfer`, ou `tokenAccounts` côté serveur au lieu de tout récupérer et de filtrer dans votre code. * `sortOrder: "asc"` — résultats chronologiques (le plus ancien en premier), que les méthodes standard ne peuvent pas retourner sans récupérer tout l'historique et le renverser. ## Étapes de migration `getTransactionsForAddress` est exclusif à Helius. Il fonctionne sur `https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY` (et devnet) — le même point de terminaison que vos appels existants utilisent déjà si vous êtes client Helius. Aucun changement de clé API ou de plan n'est nécessaire. Supprimez l'appel `getSignaturesForAddress` et la boucle `getTransaction`. Faites une seule demande `getTransactionsForAddress` avec `transactionDetails: "full"`, en reportant vos valeurs `encoding`, `maxSupportedTransactionVersion`, et `commitment` comme indiqué dans la [correspondance des paramètres](#correspondance-des-paramètres). Si vous avez seulement besoin de signatures (par exemple, pour alimenter un pipeline existant), utilisez plutôt `transactionDetails: "signatures"` — cela coûte 10 crédits au total par appel. L'enveloppe de réponse change de trois manières : * Les résultats se trouvent dans `result.data` (un tableau), pas directement dans `result`. * Chaque entrée en mode complet est `{ slot, transactionIndex, blockTime, transaction, meta }`. Les objets `transaction` et `meta` ont la même forme que ce que renvoie `getTransaction`, donc votre code de parsing est inchangé. * Les entrées en mode signatures correspondent à la sortie `getSignaturesForAddress` (`signature`, `slot`, `err`, `memo`, `blockTime`, `confirmationStatus`) plus un nouveau champ `transactionIndex`. Une différence de comportement à garder : avec l'ancien modèle, un appel `getTransaction` pouvait retourner `null` pour une signature. Avec `getTransactionsForAddress`, chaque entrée dans `result.data` est une transaction complète — supprimez tout traitement des nulls pour les détails manquants. Remplacez la boucle de curseur `before` pour `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: 1, limit: 1000, ...(paginationToken && { paginationToken }) } ] }) }); const { result } = await response.json(); allTransactions.push(...result.data); paginationToken = result.paginationToken; } while (paginationToken); ``` La boucle se termine lorsque `paginationToken` est `null` — plus besoin de comparer des listes de signatures ou de suivre la dernière signature vous-même. Si vous utilisiez `until` pour arrêter à une signature connue, remplacez-le par `filters.signature: { gt: "KNOWN_SIGNATURE" }`. Si vous l'utilisiez pour arrêter à un moment donné, `filters.blockTime` ou `filters.slot` est généralement plus approprié. L'ancien modèle manque entièrement l'activité du compte de jeton associé (ATA) à moins que vous n'appeliez également `getTokenAccountsByOwner` et récupériez des signatures pour chaque compte de jeton. Pour l'inclure, ajoutez un filtre : ```json theme={"system"} { "filters": { "tokenAccounts": "balanceChanged" } } ``` `balanceChanged` renvoie les transactions qui référencent le portefeuille ou modifient le solde de tout compte de jeton qu'il possède, filtrant le spam. Voir [comptes de jetons associés](/docs/fr/rpc/gettransactionsforaddress#comptes-de-jetons-associés) pour les options `none`/`balanceChanged`/`all` et l'avertissement pré-2022. Pour une adresse d'exemple, récupérez l'historique des deux manières et comparez les ensembles de signatures. Avec `filters.tokenAccounts` désactivé (configuration par défaut `none`), `getTransactionsForAddress` renvoie les mêmes transactions que `getSignaturesForAddress` pour la même plage. Déployez ensuite et supprimez l'ancien chemin de code. ## Différences de comportement à revoir La plupart des migrations sont un remplacement simple, mais vérifiez les points suivants avant de livrer : * **Engagement.** `processed` n'est pas pris en charge ; utilisez `confirmed` ou `finalized`. Si votre ancien code interrogeait l'historique récent à `processed`, basculez à `confirmed`. * **Mesure.** Les réponses de transactions complètes coûtent 10 crédits par 100 transactions renvoyées (minimum de 10 crédits) ; les réponses de seules signatures coûtent 10 crédits au total. L'ancien modèle coûtait 1 crédit par appel — moins cher par requête, mais bien plus cher par transaction récupérée. Les réponses échouées sont gratuites. Voir [mesure](/docs/fr/rpc/gettransactionsforaddress#métrique). * **Support réseau.** Mainnet a une rétention illimitée. Devnet est supporté avec 2 semaines de rétention. Testnet n'est pas supporté. * **Adresses réservées.** Un petit ensemble d'adresses système (Programme de vote, Programme système, sysvars) se dirige vers des chemins archivaux ou retourne vide. Si vous indexez celles-ci, revoyez [limitations et cas particuliers](/docs/fr/rpc/gettransactionsforaddress#limitations-et-cas-particuliers). * **Adresses multiples.** Comme l'ancien flux, une requête couvre une adresse. Interrogez les adresses en parallèle et fusionnez ; voir [adresses multiples](/docs/fr/rpc/gettransactionsforaddress#adresses-multiples). ## Questions fréquemment posées ### Est-ce que getTransactionsForAddress est une méthode RPC standard de Solana ? Non. C'est une méthode exclusive à Helius disponible sur les points de terminaison RPC de Helius. Le RPC standard de Solana et d'autres fournisseurs n'offrent que `getSignaturesForAddress` et `getTransaction`. Vos autres appels RPC ne sont pas affectés — la méthode se trouve sur le même point de terminaison avec toute la surface RPC standard. ### Ai-je encore besoin de getTransaction après la migration ? Seulement pour des recherches ponctuelles où vous avez déjà une signature et aucun contexte d'adresse, comme vérifier une transaction spécifique qu'un utilisateur a collée. Pour tout historique basé sur l'adresse — compléments, indexation, flux d'activité du portefeuille — `getTransactionsForAddress` remplace les deux méthodes. ### Est-ce que cela fonctionne avec @solana/web3.js ? La méthode n'est pas dans la classe `Connection`, mais elle fonctionne avec n'importe quel client HTTP contre votre URL RPC Helius. Utilisez `fetch` (ou l'équivalent dans votre langage) avec un corps JSON-RPC standard, comme indiqué dans les exemples ci-dessus. Vous pouvez continuer à utiliser `Connection` pour tout le reste. ### Est-ce que ça renverra les mêmes transactions que getSignaturesForAddress ? Oui. Avec les paramètres par défaut (`filters.tokenAccounts: "none"`), cela renvoie les transactions qui référencent l'adresse interrogée — le même ensemble que `getSignaturesForAddress`. Paramétrer `tokenAccounts` à `balanceChanged` ou `all` en renvoie plus : cela ajoute l'activité des comptes de jetons associés au portefeuille, que la méthode standard ne peut pas voir. ### Combien cela coûte-t-il comparé à l'ancien modèle ? Récupérer 1 000 transactions complètes coûte 100 crédits avec `getTransactionsForAddress` contre environ 1 001 crédits (et 1 001 requêtes) avec `getSignaturesForAddress` + `getTransaction`. Les réponses avec seulement des signatures coûtent 10 crédits au total par appel. Voir [crédits Helius](/docs/fr/billing/credits) pour la tarification complète. ## Laissez un agent IA faire la migration Si vous utilisez Claude Code, Cursor ou un autre agent de codage, collez l'invite ci-dessous dans la session de l'agent de votre dépôt. Il trouve l'ancien modèle dans votre base de code et le réécrit. ````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: 1, // 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. ```` L'invite est autonome — l'agent n'a pas besoin d'accès à cette page. Pour des documents prêts pour les agents, la recherche MCP et les compétences, voir [Helius pour agents IA](/docs/fr/agents/overview). ## Prochaines étapes Tutoriel complet couvrant les filtres, le tri, la pagination et les comptes de jetons. Schéma complet des requêtes et réponses. Utilisez getTransactionsForAddress pour compléter et synchroniser un index Solana. Comparez toutes les méthodes de données historiques de Solana.