Zum Hauptinhalt springen

Warum migrieren?

Die Enhanced Transactions API ist ein Legacy-Produkt im Wartungsmodus. Sie funktioniert weiterhin, erhält aber keine neuen Parser-Typen oder Funktionen. Ihr Nachfolger ist Parsed Events. Das Produkt decodiert Anweisungen über den IDL-Katalog, der auch Parsed Streams unterstützt. Der Unterschied liegt darin, wie Transaktionen decodiert werden. Enhanced Transactions ordnet eine Transaktion einem Ereignistyp aus einer festen Liste zu (TRANSFER, SWAP, NFT_SALE, …) und gibt für bekannte Typen eine vorgefertigte Zusammenfassung zurück. Parsed Events decodiert jede Anweisung anhand der IDL des jeweiligen Programms — mehr als 3.600 Programme — in benannte Argumente und Konten und erstellt darauf aufbauend die Zusammenfassung: Parsed Events ist in allen Tarifen allgemein verfügbar, einschließlich Free, und kostet 10 Credits pro request. Enhanced Transactions funktioniert weiterhin im Wartungsmodus. Du kannst daher in deinem eigenen Tempo migrieren.

Zuordnung der endpoints

Beide Parsed Events-Methoden sind POST-requests an https://mainnet.helius-rpc.com. Zur Authentifizierung verwendest du denselben api-key-Abfrageparameter wie bisher: Der Verlaufs-endpoint verschiebt alle Eingaben aus den Query-String-Parametern in einen JSON-Body. Request-Bodys lehnen unbekannte Felder ab. Tippfehler führen daher zu einem eindeutigen Fehler, statt stillschweigend ignoriert zu werden.

Vorher und nachher

Dieselbe Aufgabe — den geparsten Verlauf für eine Wallet abrufen — in beiden APIs:

Parameterzuordnung

Transaktionen parsen

POST /v0/transactions → POST /v1/parsed-events/transactions Neue Optionen ohne bisherige Entsprechung: includeRawTransaction gibt den ursprünglichen Solana-Transaktions-payload zusammen mit dem geparsten Ergebnis zurück.

Transaktionsverlauf

GET /v0/addresses/{address}/transactions → POST /v1/parsed-events/transaction-history. Jeder Abfrageparameter wird zu einem JSON-Body-Feld: Dabei ändern sich drei Standardwerte:
  • limit hat standardmäßig den Wert 100 statt 10.
  • commitment verwendet standardmäßig confirmed statt finalized; processed wird nicht unterstützt.
  • sortOrder behält dieselben Werte asc/desc bei. desc ist der Standardwert.
Verwende für die Paginierung vorzugsweise paginationToken aus der vorherigen response statt beforeSignature. Weitere Informationen findest du unten unter Paginierung vereinfachen. Für den alten Parameter type gibt es keine Entsprechung in Parsed Events. Es gibt keinen serverseitigen Filter nach Transaktionstyp. Filtere clientseitig nach parsed.summary.type (swap, transfer, add_liquidity, …) oder nach den decodierten Anweisungen selbst. Das ist präziser als die alten festen Typen. Für typspezifische Echtzeit-Feeds filtert Parsed Streams serverseitig auf Anweisungsebene.

Zuordnung der response-Felder

Enhanced Transactions gibt ein flaches Array angereicherter Transaktionen zurück. Parsed Events umschließt jedes Ergebnis mit einem Envelope — { signature, parserStatus, parsed }. Verlaufs-responses umschließen das Array zusätzlich mit einem Seitenobjekt, das paginationToken enthält. Die geparsten Felder werden wie folgt zugeordnet: Die größte Änderung ist ein neues Feld ohne bisherige Entsprechung: parsed.instructions[] enthält alle Anweisungen der obersten Ebene und alle inneren Anweisungen in Ausführungsreihenfolge. decoded.args und decoded.accounts werden anhand der IDL des Programms benannt. Enhanced Transactions lieferte dir eine Ereigniszusammenfassung pro Transaktion. Parsed Events liefert dir die Zusammenfassung und die vollständige Liste decodierter Anweisungen. Unter Geparste response findest du alle Felder.

Migrationsschritte

1

Swap the endpoints

Leite Aufrufe zum Parsen von Transaktionen an POST /v1/parsed-events/transactions und Verlaufsaufrufe an POST /v1/parsed-events/transaction-history weiter. Host und api-key-Abfrageparameter bleiben gleich. Verlaufs-requests wechseln von GET mit Abfrageparametern zu POST mit einem JSON-Body. Verschiebe jeden Parameter gemäß der obigen Zuordnung.
2

Update the response handling

Entpacke den neuen Envelope: Prüfe parserStatus === "OK" und lies die Felder dann aus parsed statt aus der obersten Ebene. Benenne timestamp in blockTime um. Lies description und type aus summary und berücksichtige dabei null. Teile rawTokenAmount durch 10^decimals, wenn der alte Code tokenAmount gelesen hat.
3

Replace type filtering

Wenn der alte Code type=... übergeben hat, filtere die zurückgegebenen Elemente clientseitig nach parsed.summary.type oder parsed.instructions[]. Beispielsweise ersetzt „Anweisungen, bei denen programId Jupiter und instructionName gleich route ist“ den Wert type=SWAP durch etwas, das du tatsächlich überprüfen kannst. Wenn der Typfilter einen Echtzeit-Feed steuern sollte, verschiebe diesen Consumer zu Parsed Streams. Dort wird serverseitig auf Anweisungsebene gefiltert.
4

Simplify pagination

Ersetze die Cursor-Schleife mit before-signature durch paginationToken:
Die Schleife endet, wenn paginationToken fehlt. Die alten Fehler bei der Laufzeitsuche („Ereignisse konnten innerhalb des Suchzeitraums nicht gefunden werden“) und die zugehörige Verarbeitung von Fortsetzungssignaturen entfallen vollständig. Lösche diesen Code.
5

Verify against the old output

Rufe für eine Beispieladresse dieselbe Seite aus beiden APIs ab und vergleiche die Signaturmengen, Gebühren und Übertragungsbeträge. Führe dann das deployment durch und entferne den alten Codepfad. Enhanced Transactions funktioniert während deiner Migration weiterhin. Es gibt keine erzwungene Abschaltung.

Zu prüfende Verhaltensunterschiede

  • Commitment-Standardwerte. Für den Verlauf gilt standardmäßig confirmed, während für den alten endpoint standardmäßig finalized galt. Übergib commitment: "finalized" explizit, wenn deine Pipeline von Finalität abhängt. processed wird nicht unterstützt.
  • Fehler pro Element. Eine Signatur, die nicht geparst werden kann, führt nicht mehr dazu, dass der request fehlschlägt. Stattdessen wird sie als Element mit parserStatus: "ERROR" und einer parserError zurückgegeben. Behandle den Fehler pro Element statt pro request.
  • Abdeckung der Zusammenfassung. Bei Transaktionen ohne erkannte Aktion auf Transaktionsebene ist summary gleich null. Die alte API gab in diesem Fall type: "UNKNOWN" zurück. Die neue API stellt dir weiterhin jede decodierte Anweisung zur Verarbeitung bereit.
  • Zugriff und Kosten. Parsed Events ist in allen Tarifen verfügbar und kostet 10 Credits pro request statt wie zuvor 100 bei Enhanced Transactions.

Lass einen KI-Agenten die Migration übernehmen

Wenn du Claude Code, Cursor oder einen anderen Coding-Agenten verwendest, füge den folgenden Prompt in die Agentensitzung deines Repositorys ein. Er findet Aufrufstellen für Enhanced Transactions und schreibt sie um.
Der Prompt ist eigenständig. Der Agent benötigt keinen Zugriff auf diese Seite. Agentenfähige Dokumentation, MCP-Suche und Skills findest du unter Helius für KI-Agenten.

Nächste Schritte

Parsed Events Quickstart

Parse deine erste Transaktion, rufe den Adressverlauf ab und durchlaufe die Ergebnisse seitenweise.

Parsed Response

Feldreferenz für geparste Transaktionen, Übertragungen und Anweisungen.

Parsed Streams

Dieselbe Decodierung in Echtzeit über WebSocket, serverseitig gefiltert.

getTransactionsForAddress

Unverarbeiteter Transaktionsverlauf mit Unterstützung für token-Konten und serverseitigen Filtern.