Skip to main content
Parsed Streams is in closed beta. Access is limited to whitelisted project ids for now, and the API may change before general availability. To join the closed beta, apply here.

​
What is Parsed Streams?

Parsed Streams is a WebSocket service that watches every confirmed Solana transaction (vote transactions excluded), decodes it, and pushes you the transactions that match a filter you define. You say “I care about Jupiter route instructions” or “I care about anything touching this account”, and the server does the watching, decoding, and matching for you. You receive whole transactions, already decoded: every instruction with named arguments and named accounts, plus the fee, the full account key list, a transaction-level summary of what happened, the SOL and token transfers, and pointers to the exact instructions that matched your filter. All data is delivered at confirmed commitment.

​
The mental model

If you already know Solana internals, skip ahead. If not, this is the model the whole API is built on. A transaction is a signed message. It names a fee payer, lists every account it will touch, and carries a list of instructions. When you look at one you see: a signature (its unique id), the slot it landed in, the fee paid, the account keys, whether it succeeded or failed, and the instructions. An instruction is one action: run this program, with this input, using these accounts. A swap on Jupiter, a token transfer, a memo. A transaction usually carries several instructions, and they run in order. Programs can call other programs. When Jupiter executes a swap, it does not move the tokens itself. Its route instruction calls the token program to move tokens and the exchange programs that hold the liquidity. Those nested calls are instructions too, called inner instructions (or CPIs, cross program invocations). This matters when you write a filter: much of the real activity, like the actual token movements inside a swap, happens in inner instructions, so your filter matches them by default. If you only want the instructions a user signed for, set includeCpi to false. Accounts are the on-chain things an instruction works with: wallets, token balances, pools, mints. Each instruction carries them as an ordered list of addresses, and the order is the contract: the program defines what each position means. The token program, for example, expects the account to take tokens from first, then the account to receive them, then the owner approving the transfer. Roles give those positions names. Most well known programs publish a machine readable manual for their interface, called an IDL. The manual lists every instruction the program has, what its data fields mean, and what each account position is for. Helius keeps a catalog of these manuals for thousands of programs. Using it, a bare address list turns into named accounts: for a token transfer, position 0 becomes source, position 1 becomes destination, position 2 becomes authority. Instead of guessing what the third address means, you read {"name": "authority", "pubkey": "9xQe...", "isSigner": true}. These names are the roles you can filter on. Decoding is the same idea applied to the instruction’s input data. On the wire that data is opaque bytes. With the program’s manual, the bytes become named values: {"in_amount": "1000000", "slippage_bps": 50}. Not every instruction can be decoded, so each one lands in one of three states you can see directly from its fields:
  • Decoded: the instruction carries a decoded object with named args and named accounts.
  • Recognized: on top of decoded, the instruction carries a summary with a type (such as swap), a human-readable description, and a structured parsedData payload, such as swap metadata with amounts and mints.
  • Undecoded: the program or instruction is not in the catalog, decoded is null, and the instruction carries the raw bytes (rawData) and the plain address list (rawAccounts) instead, so you always have something to work with.
That is the whole model, and your filter is built directly from it:
  • programs: which program the instruction calls
  • instructionNames: what the program’s manual calls that action
  • accounts.include: which addresses it touches
  • accounts.roles: which named position must hold which address
  • includeCpi and includeFailed: whether inner instructions and failed transactions count
Filters select instructions; notifications deliver the whole transaction.

​
How it compares

vs Enhanced WebSockets

Enhanced WebSockets stream whole transactions or account updates without decoding. Parsed Streams matches at the instruction level and decodes everything for you.

vs LaserStream gRPC

LaserStream is a high-throughput gRPC firehose that you filter and decode on the client. Parsed Streams is a WebSocket API that filters and decodes on the server.

vs Parsed Events

Parsed Events applies the same decoding to historical transactions: parse signatures or page through an address’s history on demand over REST and GraphQL. Parsed Streams pushes new transactions as they land.

​
Supported programs

Parsed Streams decodes 3,600+ programs from their on-chain IDLs, plus core programs like SPL Token, Token-2022, and the System Program through built in decoders. You can filter by any program address. Instructions the service cannot decode stream as raw instruction data instead. A few of the most-used decoded programs:
Don’t see a program? It’s likely still in the catalog. Call describeProgram with its address to see its instructions, events, and account roles.

​
Access

Only whitelisted project ids can connect during the closed beta. The Helius team shares the connection endpoint with you when your project is whitelisted. Authenticate with your project’s API key, passed as the api-key query parameter (or the x-api-key header). The key is checked when the connection opens: a missing, invalid, or non-whitelisted key is rejected with HTTP 401, and a project at its connection cap gets HTTP 429.

​
Get Started

Quickstart

Connect, send your first filter, and read a notification.

Track Jupiter Swaps

Build and subscribe a real filter using program discovery.

Track Pump.fun Mints

A reconnect-safe listener that logs every new Pump.fun token deploy.

Handling Reconnects

Detect disconnects, back off, resubscribe, and backfill missed slots.