Zum Hauptinhalt springen
Parsed Streams ist neu für dich? Lies zuerst das mentale Modell. Es erklärt, warum Filter so aufgebaut sind.

Schnellstart

1

Get Access

Parsed Streams ist in allen Tarifen für 1 Credit pro zugestelltem Ereignis verfügbar. Rufe deinen API key im Helius Dashboard ab und verbinde dich unter wss://beta.helius-rpc.com mit dem Gatekeeper endpoint. Dabei handelt es sich um denselben Host wie für den RPC- und WebSocket-Datenverkehr von Helius.Authentifiziere dich mit dem API key deines Projekts. Übergib ihn als Abfrageparameter api-key oder über den Header x-api-key.
2

Connect

wscat
Ein fehlender oder ungültiger API key wird mit HTTP 401 abgelehnt. Hat ein Projekt sein Verbindungslimit erreicht, erhält es HTTP 429.
3

Subscribe with a Filter

Sende parsedTransactionSubscribe mit einem Filter und optionalen Optionen:
Der result der response ist eine ganzzahlige Abonnement-ID:
4

Read a Notification

Jede passende Transaktion kommt als parsedTransactionNotification an und ist bereits decodiert. matchedIndexes verweist auf die Anweisungen, auf die dein Filter zutraf. Unter Benachrichtigungen findest du die vollständige Struktur.
5

Unsubscribe

Du kannst die Verbindung auch einfach schließen. Dadurch werden alle zugehörigen Abonnements entfernt.

Anleitungen

Track Jupiter Swaps

Verwende describeProgram, um vor dem Abonnieren einen zuverlässigen Filter zu erstellen.

Track Pump.fun Mints

Ein Listener mit sicherer Wiederverbindung, der jedes neue Token-deployment von Pump.fun protokolliert.

Handling Reconnects

Überstehe inaktive timeouts und deployments. Führe danach einen backfill für genau die Daten aus, die dir fehlen.

Protokollreferenz

Parsed Streams verwendet JSON-RPC 2.0 über eine einzelne WebSocket-Verbindung. Jeder request erhält eine response mit demselben id. Anschließend sendet ein Abonnement parsedTransactionNotification-Nachrichten, bis du es beendest oder die Verbindung trennst.

Abonnieren

Sende parsedTransactionSubscribe mit einem Filter und optionalen Optionen. Der result der response ist eine ganzzahlige Abonnement-ID.
Request
Response

Filterfelder

Mindestens eines der Felder programs oder accounts.include ist erforderlich. Die festgelegten Felder werden mit UND verknüpft: Eine Anweisung muss alle Bedingungen erfüllen.
string[]
Abzugleichende Programm-IDs (Base58-Adressen, keine Namen). Eine Anweisung stimmt überein, wenn ihr Programm in dieser Liste enthalten ist. Innerhalb der Liste gilt ODER.
string[]
Decodierte Anweisungsnamen wie route. Zuerst erfolgt ein exakter Abgleich. Danach folgt ein Abgleich ohne Berücksichtigung von Groß- und Kleinschreibung sowie Trennzeichen. Daher stimmt sharedAccountsRoute auch mit dem Übertragungsnamen shared_accounts_route überein. Innerhalb der Liste gilt ODER. Nur Anweisungen, deren Namen der Katalog identifizieren konnte, können übereinstimmen. Übernimm die Namen daher aus describeProgram.
string[]
Kontoadressen. Eine Anweisung stimmt überein, wenn eine dieser Adressen in ihrer Kontoliste vorkommt. Innerhalb der Liste gilt ODER. Dies funktioniert für jede Anweisung, unabhängig davon, ob sie decodiert wurde. Die Programm-ID selbst zählt hier nicht als Konto.
object
Eine Zuordnung von decodierten Kontorollennamen zu Adressen, zum Beispiel { "user_transfer_authority": "<pubkey>" }. Jeder Eintrag muss zutreffen (UND über alle Einträge hinweg), und die Anweisung muss dafür decodiert sein. Rollennamen werden exakt und unter Beachtung der Groß- und Kleinschreibung abgeglichen. Kopiere sie daher aus describeProgram, anstatt sie zu erraten.
boolean
Standard:"false"
Schließt Anweisungen aus fehlgeschlagenen Transaktionen ein.
boolean
Standard:"true"
Innere Anweisungen (CPI) können übereinstimmen. Setze false, um nur Anweisungen der obersten Ebene abzugleichen.
Unbekannte Felder im Filter oder in den Optionen werden mit -32602 abgelehnt und nicht stillschweigend ignoriert. Tippfehler führen dadurch zu einem deutlichen Fehler, statt keine Treffer zu liefern.

Optionen

Der zweite Parameter ist optional.
string
Standard:"confirmed"
Es wird nur confirmed unterstützt.
string
Standard:"full"
Legt den Inhalt jeder Benachrichtigung fest. full: die gesamte Transaktion, alle Anweisungen sowie matchedIndexes mit Verweisen auf die Filtertreffer. matched: nur die übereinstimmenden Anweisungen, ohne Indexliste. raw: nur übereinstimmende Anweisungen. Jede ist auf ihre Position, programId und einen Base58-Blob in data reduziert. Decodierte Felder und das Array accountKeys fehlen. Verwende matched, wenn Bandbreite wichtiger als Kontext ist. Vollständige payloads sind im Durchschnitt etwa dreimal so groß. Verwende raw, wenn du Anweisungsdaten selbst decodierst und nur die Bytes benötigst.
Die Anzahl gleichzeitiger Verbindungen pro Projekt hängt von deinem Tarif ab: 5 bei Free, 10 bei Developer und 50 bei Business und Professional. Dieses Kontingent gilt gemeinsam für alle API keys des Projekts. Siehe Rate Limits.

Benachrichtigungen

Pro passender Transaktion und Abonnement wird eine Benachrichtigung gesendet. Mit dem Standardwert details: "full":
So liest du sie:
  • transaction enthält den vollständigen Kontext. fee wird in Lamports angegeben. accountKeys ist die vollständige Liste der Schlüssel, einschließlich der aus Adress-Lookup-Tabellen geladenen Schlüssel. Die Reihenfolge entspricht der Ausgabe der Chain. feePayer ist immer accountKeys[0]. error enthält den Transaktionsfehler als strukturiertes JSON, zum Beispiel {"InstructionError": [2, {"Custom": 6001}]}, wenn status den Wert "error" hat.
  • summary hat überall dieselbe Struktur: einen type (wie swap oder transfer), einen lesbaren description und einen strukturierten parsedData-Payload, wenn der Parser die Aktion erkennt. Bei einem Swap enthält der Payload das Protokoll, die Beträge und die Mints. transaction.summary bezeichnet die Hauptaktion der Transaktion. Jede erkannte Anweisung enthält einen eigenen summary mit derselben Struktur. Um alle Swaps einer Transaktion zu erfassen, durchlaufe instructions und lies summary.parsedData, wenn summary.type den Wert "swap" hat.
  • Swap-Beträge werden von der Handelsplattform gemeldet. in_amount, actual_out_amount und die Beträge innerer Swaps in parsedData entsprechen den Angaben der Handelsplattform, nicht den Beträgen, die das Wallet des Nutzers tatsächlich gesendet oder empfangen hat. Übertragungsgebühren von Token-2022 oder andere außerhalb des Swaps vorgenommene Abzüge werden nicht berücksichtigt. Um den exakt empfangenen Betrag zu ermitteln, vergleiche die Salden in den token accounts des Nutzers vor und nach der Transaktion.
  • nativeTransfers und tokenTransfers führen die vom Parser aus der gesamten Transaktion extrahierten Bewegungen von SOL und token auf. Ihre Struktur entspricht der response der Parsed Events API, sodass Nutzer von stream und API denselben Verarbeitungscode verwenden können. Beide sind immer vorhanden, können aber leer sein.
  • instructions enthält alle Anweisungen der Transaktion in Ausführungsreihenfolge: Auf jede Anweisung der obersten Ebene folgen ihre inneren Anweisungen. Jeder Eintrag enthält seine eigene Position: instructionIndex gibt an, zu welcher Anweisung der obersten Ebene er gehört (beginnend bei 0). innerInstructionIndex gibt seine Position unter den inneren Aufrufen dieser Anweisung an (null bedeutet, dass es sich um die Anweisung der obersten Ebene selbst handelt). stackHeight gibt die Aufruftiefe an (1 für die oberste Ebene). Verwende diese Werte, nicht die Array-Position.
  • matchedIndexes enthält Indizes für instructions. Sie geben an, welche Anweisungen dein Filter tatsächlich gefunden hat. Die übrigen dienen als Kontext. Bei details: "matched" enthält das Array nur die Treffer und matchedIndexes fehlt.
  • decoded-Namen verwenden snake_case (in_amount, user_transfer_authority), wie in der IDL des Programms veröffentlicht. Ganzzahlargumente sind häufig Zeichenfolgen ("1000000"), da u64-Werte nicht in JavaScript-Zahlen passen.
  • blockTime ist derzeit immer null. Verlass dich nicht darauf.
  • Rechne innerhalb einer Transaktion mit einer Mischung aus decodierten und nicht decodierten Anweisungen: Ein vollständig decodierter Swap kann neben einem nicht erkannten Memo stehen. Prüfe decoded: Wenn der Wert null ist, enthält die Anweisung stattdessen rawData (Base58-Bytes) und rawAccounts (einfache Liste öffentlicher Schlüssel). So stehen dir immer verwertbare Daten zur Verfügung.
Mit details: "raw" wird value auf Transaktionsmetadaten und Blobs reduziert. accountKeys, nativeTransfers, tokenTransfers, matchedIndexes und alle decodierten Felder fehlen. Das summary der Transaktion ist weiterhin enthalten. Jede übereinstimmende Anweisung besteht aus ihrer Position, ihrem Programm und ihren Base58-Bytes in data, genau wie sie auf der Chain erscheinen. Dies gilt auch für Anweisungen, die der Katalog hätte decodieren können:

Abonnement beenden

Gibt true zurück, wenn das Abonnement existierte und dir gehörte. Benachrichtigungen werden sofort gestoppt. Wenn du die Verbindung schließt, werden alle zugehörigen Abonnements entfernt.

Ermittlung

Der häufigste Fehler bei dieser Art von API ist ein gültiger Filter, der keine Treffer liefert. Meist wurde dabei der Name einer Instruktion oder Rolle nur erraten. describeProgram verhindert das, indem es genau die Namen zurückgibt, die der Matcher vergleicht. Diese Funktion ist derzeit nur für wss://fs-beta.helius-rpc.com/?api-key=<API_KEY> verfügbar. Sende sie daher über eine von deinen Abonnements getrennte Verbindung:
Request
Response
Du kannst eine Programmadresse oder einen Katalognamen übergeben. Bevorzuge jedoch die Adresse: Namen können über verschiedene Programmversionen hinweg mehrdeutig sein. Mehr als ein Katalogeintrag heißt jupiter, und die Suche nach einem Namen kann den älteren Eintrag liefern. Wenn du nach einem Namen suchst, prüfe, ob result.id dem Programm entspricht, das du abonnieren möchtest. Empfohlener Ablauf: Rufe mit describeProgram die exakten Anweisungs- und Rollennamen ab. Erstelle den Filter mit diesen Namen und abonniere ihn anschließend. Die Anleitung Jupiter-Swaps verfolgen führt dich durch den gesamten Ablauf.

Limits

Fehler

Fehler folgen JSON-RPC 2.0: { "error": { "code": <int>, "message": "<text>" }, "id": <id> }. Die Meldungen geben genau an, was fehlerhaft war und wo der Fehler auftrat. Verbindungen können auch mit einem WebSocket-Schließcode beendet werden. Unter Wiederverbindungen handhaben erfährst du, was die einzelnen Codes bedeuten und wie du die Verbindung wiederherstellst.

Client-Beispiele