> ## 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. # Von Enhanced Transactions zu Parsed Events migrieren > Wechsel von der Enhanced Transactions API zu Parsed Events — Endpunkt- und Parameterzuordnung, Antwortfeldzuordnung, Vorher/Nachher-Code und eine KI-Agenten-Eingabeaufforderung. ## Warum migrieren? Die [Enhanced Transactions API](/docs/de/enhanced-transactions/overview) ist ein Legacy-Produkt im Wartungsmodus: Sie funktioniert noch, erhält jedoch keine neuen Parser-Typen oder Funktionsarbeiten mehr. Ihr Nachfolger ist [Parsed Events](/docs/de/parsed-events), das Anweisungen durch den IDL-Katalog decodiert, der auch [Parsed Streams](/docs/de/parsed-streams) antreibt. Der Unterschied liegt darin, wie Transaktionen decodiert werden. Enhanced Transactions klassifiziert eine Transaktion in eine feste Liste von Ereignistypen (`TRANSFER`, `SWAP`, `NFT_SALE`, ...) und gibt eine vorgefertigte Zusammenfassung für die Typen zurück, die es kennt. Parsed Events decodiert **jede Anweisung** gegen die eigene IDL des Programms — mehr als 3.600 Programme — in benannte Argumente und benannte Konten und erstellt darauf basierend die Zusammenfassung: | | Enhanced Transactions | Parsed Events | | ------------------------- | ---------------------------------------------------- | ---------------------------------------------------------------- | | Decodiermodell | Festgelegte Ereignistypen, kuratierte Parser | IDL-Katalog, 3.600+ Programme | | Anweisungsdetails | Nur Ereigniszusammenfassung | Jede Anweisung, decodierte Argumente und Konten, CPIs einbezogen | | Programme ohne Parser | Generische `UNKNOWN` Ausgabe | Rohdaten und Konten immer pro Anweisung zurückgegeben | | Abfrageschnittstelle | REST | REST und GraphQL | | Paginierung | Signatur-Cursor, Laufzeit-Suchfehler zur Bearbeitung | `paginationToken` (Signatur-Cursor weiterhin verfügbar) | | Decodierte Programmfehler | Nein | Ja (`decodedError`) | | Rohtransaktionsnutzlast | Nein | Optional (`includeRawTransaction`) | | Status | Legacy, Wartungsmodus | Offene Beta, aktive Entwicklung | Parsed Events befindet sich in der offenen Beta in kostenpflichtigen Plänen. Die API kann sich noch ändern, bevor sie allgemein verfügbar ist; Enhanced Transactions funktioniert währenddessen weiterhin, sodass Sie in Ihrem eigenen Tempo migrieren können. ## Endpunktzuordnung Beide Parsed Events-Methoden sind `POST` Anfragen an `https://mainnet.helius-rpc.com`, authentifiziert mit demselben `api-key` Abfrageparameter, den Sie bereits verwenden: | Enhanced Transactions | Parsed Events | | ------------------------------------------ | -------------------------------------------- | | `POST /v0/transactions` | `POST /v1/parsed-events/transactions` | | `GET /v0/addresses/{address}/transactions` | `POST /v1/parsed-events/transaction-history` | Der Verlauf-Endpunkt verschiebt alle Eingaben von Abfragezeichenfolgenparametern in einen JSON-Body. Anforderungsinhalte lehnen unbekannte Felder ab, sodass Tippfehler laut scheitern, anstatt stillschweigend ignoriert zu werden. ## Vorher und Nachher Die gleiche Aufgabe — Analysierten Verlauf für eine Wallet abrufen — in beiden APIs: ```javascript Before (Enhanced Transactions) theme={"system"} const walletAddress = "M2mx93ekt1fmXSVkTrUL9xVFHkmME8HTUi5Cyc5aF7K"; const url = `https://mainnet.helius-rpc.com/v0/addresses/${walletAddress}/transactions?api-key=YOUR_API_KEY&limit=100&sort-order=desc`; const response = await fetch(url); const transactions = await response.json(); // flat array of enriched transactions for (const tx of transactions) { console.log(tx.signature, tx.type, tx.description); } ``` ```javascript After (Parsed Events) theme={"system"} const url = "https://mainnet.helius-rpc.com/v1/parsed-events/transaction-history?api-key=YOUR_API_KEY"; const response = await fetch(url, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ address: "M2mx93ekt1fmXSVkTrUL9xVFHkmME8HTUi5Cyc5aF7K", limit: 100, sortOrder: "desc", }), }); const page = await response.json(); // { data: [...], paginationToken } for (const item of page.data) { if (item.parserStatus !== "OK") continue; console.log(item.signature, item.parsed.summary?.type, item.parsed.summary?.description); } ``` ## Parameterzuordnung ### Transaktionen parsen `POST /v0/transactions` → `POST /v1/parsed-events/transactions` | Alt | Neu | | --------------------- | ------------------------------------------------------------------------------------------ | | `transactions` (Body) | `transactions` — unverändert | | `commitment` | `commitment` — `confirmed` (Standard) oder `finalized`; `processed` wird nicht unterstützt | Neue Optionen ohne alte Entsprechung: `includeRawTransaction` gibt die ursprüngliche Solana-Transaktionsnutzlast zusammen mit dem analysierten Ergebnis zurück. ### Transaktionsverlauf `GET /v0/addresses/{address}/transactions` → `POST /v1/parsed-events/transaction-history`. Jeder Abfrageparameter wird zu einem JSON-Body-Feld: | Alter Abfrageparameter | Neues Body-Feld | | ---------------------- | ----------------- | | `{address}` (Pfad) | `address` | | `limit` | `limit` | | `before-signature` | `beforeSignature` | | `after-signature` | `afterSignature` | | `sort-order` | `sortOrder` | | `commitment` | `commitment` | | `gt-time` | `time.gt` | | `gte-time` | `time.gte` | | `lt-time` | `time.lt` | | `lte-time` | `time.lte` | | `gt-slot` | `slot.gt` | | `gte-slot` | `slot.gte` | | `lt-slot` | `slot.lt` | | `lte-slot` | `slot.lte` | Drei Standardwerte ändern sich im Laufe der Zeit: * `limit` standardmäßig auf 100 statt 10. * `commitment` standardmäßig auf `confirmed` statt `finalized`; `processed` wird nicht unterstützt. * `sortOrder` behält die gleichen `asc`/`desc` Werte mit `desc` als Standard bei. Zum Paging verwenden Sie bevorzugt `paginationToken` aus der vorherigen Antwort über `beforeSignature` — siehe [Paginierung vereinfachen](#migrationsschritte) unten. Der alte `type` Parameter hat kein Pendant bei Parsed Events — es gibt keinen serverseitigen Transaktionstypenfilter. Filtern Sie clientseitig nach `parsed.summary.type` (`swap`, `transfer`, `add_liquidity`, ...) oder nach den decodierten Anweisungen selbst, was präziser ist als die alten festen Typen. Für typenspezifische Echtzeit-Feeds filtert [Parsed Streams](/docs/de/parsed-streams) serverseitig auf Anweisungsebene. ## Zuordnung der Antwortfelder Enhanced Transactions gibt ein flaches Array angereicherter Transaktionen zurück. Parsed Events verpackt jedes Ergebnis in einen Umschlag — `{ signature, parserStatus, parsed }` — und Verlauf-Antworten verpacken das Array in ein Seitenobjekt mit `paginationToken`. Die analysierten Felder werden wie folgt zugeordnet: | Altes Feld | Neues Feld | | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | `description` | `parsed.summary.description` — `summary` ist `null`, wenn keine transaktionsebene Zusammenfassung zutrifft | | `type` (`TRANSFER`, `SWAP`, ...) | `parsed.summary.type` (`transfer`, `swap`, ...) — ein kleinerer Satz; Details pro Anweisung verschoben zu `parsed.instructions[]` | | `source` (`SYSTEM_PROGRAM`, `JUPITER`, ...) | `parsed.summary.parsedData.protocol`, oder pro Anweisung als `instructions[].programName` | | `events` (`events.swap`, `events.nft`, ...) | `parsed.summary.parsedData` — strukturierte Nutzlast nach Zusammenfassungstyp geordnet | | `fee` / `feePayer` | `parsed.fee` / `parsed.feePayer` — unverändert | | `signature` | `signature` (auf Umschlagebene) | | `slot` | `parsed.slot` | | `timestamp` | `parsed.blockTime` | | `transactionError` | `parsed.error`, plus `parsed.decodedError` mit dem eigenen Fehlernamen des Programms, wenn Metadaten verfügbar sind | | `nativeTransfers` | `parsed.nativeTransfers` — gleiche Form (`fromUserAccount`, `toUserAccount`, `amount` in Lamports) | | `tokenTransfers` | `parsed.tokenTransfers` — gleiche Kontofelder, aber `tokenAmount` (vorskaliertes Dezimal) wird zu `rawTokenAmount` (rohe Ganzzahl) plus `decimals` | Und die größte Änderung ist ein neues Feld ohne alte Entsprechung: `parsed.instructions[]` enthält jede obere und innere Anweisung in Ausführungsreihenfolge, mit `decoded.args` und `decoded.accounts`, die aus der IDL des Programms benannt werden. Wo Enhanced Transactions Ihnen eine Ereigniszusammenfassung pro Transaktion gab, gibt Ihnen Parsed Events die Zusammenfassung *und* die vollständige decodierte Anweisungsliste. Siehe [Parsed Response](/docs/de/parsed-events/parsed-response) für jedes Feld. ## Migrationsschritte Zeigen Sie Parse Transactions-Anfragen an `POST /v1/parsed-events/transactions` und Verlauf-Abfragen an `POST /v1/parsed-events/transaction-history`. Derselbe Host, derselbe `api-key` Abfrageparameter. Verlauf-Anfragen ändern sich von `GET` mit Abfrageparametern zu `POST` mit einem JSON-Body — verschieben Sie jeden Parameter gemäß der [obenstehenden Zuordnung](#parameterzuordnung). Entpacken Sie den neuen Umschlag: überprüfen Sie `parserStatus === "OK"`, lesen Sie dann Felder von `parsed` anstelle der obersten Ebene. Benennen Sie `timestamp` um in `blockTime`, lesen Sie `description` und `type` von `summary` (achten Sie auf `null`), und teilen Sie `rawTokenAmount` durch `10^decimals`, wo der alte Code `tokenAmount` las. Wo der alte Code `type=...` übergab, filtern Sie die zurückgegebenen Elemente clientseitig nach `parsed.summary.type` oder nach `parsed.instructions[]` — beispielsweise „Anweisungen, bei denen `programId` Jupiter ist und `instructionName` `route` ist“ ersetzt `type=SWAP` durch etwas, das Sie tatsächlich überprüfen können. Wenn der Typenfilter existierte, um einen Echtzeit-Feed zu betreiben, verschieben Sie diesen Verbraucher zu [Parsed Streams](/docs/de/parsed-streams), das serverseitig auf Anweisungsebene filtert. Ersetzen Sie die `before-signature` Cursor-Schleife mit `paginationToken`: ```javascript theme={"system"} let paginationToken = null; const results = []; do { const response = await fetch("https://mainnet.helius-rpc.com/v1/parsed-events/transaction-history?api-key=YOUR_API_KEY", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ address: "YOUR_ADDRESS_HERE", limit: 100, ...(paginationToken && { paginationToken }), }), }); const page = await response.json(); results.push(...page.data); paginationToken = page.paginationToken; } while (paginationToken); ``` Die Schleife endet, wenn `paginationToken` fehlt. Die alten Laufzeit-Suchfehler ("Fehler beim Finden von Ereignissen im Suchzeitraum") und ihre Handhabung der Fortsetzungssignatur verschwinden vollständig — löschen Sie diesen Code. Für eine Musteradresse holen Sie dieselbe Seite aus beiden APIs und vergleichen die Signatursätze, Gebühren und Transferbeträge. Dann bereitstellen und den alten Codepfad entfernen. Enhanced Transactions funktioniert weiterhin während der Migration — es gibt keinen erzwungenen Abbruch. ## Unterschiedliches Verhalten zur Überprüfung * **Commitment-Standards.** Verlauf standardmäßig auf `confirmed`, wo der alte Endpunkt standardmäßig auf `finalized` war. Geben Sie `commitment: "finalized"` explizit an, wenn Ihr Pipeline von Endgültigkeit abhängt. `processed` wird nicht unterstützt. * **Fehler pro Element.** Eine Signatur, die nicht analysiert werden kann, schlägt nicht mehr fehl — sie wird als ein Element mit `parserStatus: "ERROR"` und einem `parserError` zurückgegeben. Behandeln Sie es pro Element anstelle der gesamten Anfrage. * **Zusammenfassungsabdeckung.** `summary` ist `null` für Transaktionen mit keiner anerkannten transaktionsebenen Aktion. Die alte API gab in diesem Fall `type: "UNKNOWN"` zurück; die neue API gibt Ihnen immer noch jede decodierte Anweisung zurück, mit der Sie arbeiten können. * **Zugriff.** Parsed Events befindet sich in der offenen Beta in kostenpflichtigen Plänen, und die API kann sich noch ändern, bevor sie allgemein verfügbar ist. ## Lassen Sie einen KI-Agenten die Migration durchführen Wenn Sie Claude Code, Cursor oder einen anderen Codierungsagenten verwenden, fügen Sie die folgende Eingabeaufforderung in die Sitzung des Agenten Ihres Repositorys ein. Er findet Enhanced Transactions Aufrufstellen und schreibt sie um. ```markdown theme={"system"} Migrate this codebase from the Helius Enhanced Transactions API to the Helius Parsed Events API. ## Background Parsed Events is the successor to Enhanced Transactions. Same host (https://mainnet.helius-rpc.com) and api-key query parameter; new paths, JSON bodies, and response shapes. Docs: https://www.helius.dev/docs/parsed-events/quickstart.md and https://www.helius.dev/docs/parsed-events/parsed-response.md ## Step 1: Find the old call sites Search for: - POST requests to /v0/transactions - GET requests to /v0/addresses/
/transactions (any query parameters) - Pagination loops using before-signature / after-signature cursors, and handlers for the "Failed to find events within the search period" error ## Step 2: Rewrite each call site Parse transactions: - POST /v0/transactions -> POST /v1/parsed-events/transactions - Body keeps { transactions: [...] }; optionally add commitment ("confirmed" default or "finalized") and includeRawTransaction. Transaction history: - GET /v0/addresses/{address}/transactions?... -> POST /v1/parsed-events/transaction-history with a JSON body. - Parameter mapping (query -> body): address path segment -> address; limit -> limit (default is now 100, not 10); before-signature -> beforeSignature (prefer paginationToken, see below); after-signature -> afterSignature; sort-order -> sortOrder; commitment -> commitment (default is now "confirmed", not "finalized"; "processed" unsupported); gt-time/gte-time/lt-time/lte-time -> time.gt/.gte/.lt/.lte; gt-slot/gte-slot/lt-slot/lte-slot -> slot.gt/.gte/.lt/.lte. - type=... has no server-side equivalent: filter returned items client-side on parsed.summary?.type (lowercase: "swap", "transfer", ...) or on parsed.instructions[] (programId / instructionName). Response shape changes: - Each item is now { signature, parserStatus, parsed } — check parserStatus === "OK" and read fields from parsed. - Field renames: timestamp -> parsed.blockTime; description -> parsed.summary?.description; type -> parsed.summary?.type; source -> parsed.summary?.parsedData?.protocol or parsed.instructions[].programName; events -> parsed.summary?.parsedData. - nativeTransfers: unchanged shape under parsed.nativeTransfers. - tokenTransfers: tokenAmount (pre-scaled decimal) is replaced by rawTokenAmount (raw integer string/number) plus decimals — divide by 10**decimals where the old amount was used. - History responses wrap results as { data, paginationToken }. Loop while paginationToken is present, passing it back in the next request body. Delete continuation-signature error handling for the old runtime type search — it no longer exists. ## Step 3: Constraints and cleanup - Keep the same Helius API key and host; only paths, methods, bodies, and response handling change. - Never hardcode an API key; keep reading it from the existing config or environment variable. - Preserve the surrounding code style and error handling conventions. - Leave Enhanced Transaction webhook payload handling unchanged — this migration covers only the /v0/transactions and /v0/addresses REST calls. ## Step 4: Verify - Run the project's type checks and tests. - Do NOT make any API calls yourself. Instead, write a standalone script (e.g. scripts/verify-parsed-events-migration.mjs) that fetches one page of history for an address from both APIs — the old GET /v0/addresses/{address}/transactions and the new POST /v1/parsed-events/transaction-history — and prints whether the signature sets, fees, and native transfer amounts match, listing any differences. Read the API key from an environment variable and the address from a CLI argument. - Tell the user how to run it, for example: HELIUS_API_KEY=... node scripts/verify-parsed-events-migration.mjs
- Summarize every call site changed and flag any you were unsure about. ``` Die Eingabeaufforderung ist eigenständig — der Agent benötigt keinen Zugriff auf diese Seite. Für agentenfähige Dokumente, MCP-Suche und Fähigkeiten siehe [Helius für KI-Agenten](/docs/de/agents/overview). ## Nächste Schritte Parsen Sie Ihre erste Transaktion, holen Sie den Adressverlauf ab und blättern Sie durch die Ergebnisse. Feldreferenz für analysierte Transaktionen, Transfers und Anweisungen. Das gleiche Decoding in Echtzeit über WebSocket, serverseitig gefiltert. Rohdatentransaktionsverlauf mit Unterstützung von Token-Konten und serverseitigen Filtern.