Introducing the Parsed Events API and Parsed Streams

Parsed Streams and the Parsed Events API are two new Helius products that return fully decoded Solana transactions for 3,600+ programs decoded from their onchain IDLs:

• Named accounts
• Named instruction arguments
• Plain-language summaries
• Every SOL and token transfer

Parsed Streams pushes matching transactions to you over WebSocket the moment they're confirmed.

The Parsed Events API returns the same decoded model on demand, over REST and GraphQL, for any signature or any address's history.

Both are in open beta today and available on all paid plans.

Why is reading Solana transactions difficult?

When you query standard RPC nodes about what happened in a transaction you get a list of account addresses with no names, and instruction data as an opaque base58 blob.

To turn that into "this wallet swapped 1,500 SOL for PUMP on Jupiter," you traditionally have to:

1. Fetch the transaction and identify every program it touched
2. Find each program's IDL (its published interface), if one exists
3. Decode the instruction data (usually Borsh) against that IDL
4. Map positional accounts to their roles: is the third address the authority or the destination? Only the program's interface knows
5. Recurse into inner instructions (CPIs), where most of the real activity happens, like the token movements inside a swap
6. Repeat for every program you care about, and keep your decoders updated as programs ship new versions

That's weeks of engineering work before you've answered a single question, and it's one of the steepest learning curves when starting on Solana. The chain’s data is public, but isn't legible.

We built a server-side decoding layer so you don’t have to.

What’s included in a Parsed Events response?

Every transaction comes back decoded through the Helius IDL catalog. 

Here’s a real Jupiter swap, trimmed to the highlights:

{
  "summary": {
    "type": "swap",
    "description": "GV6UUm… swapped 1500 SOL for 64672839.26195 PUMP via Jupiter",
    "parsedData": {
      "protocol": "jupiter",
      "in_amount": "1500000000000",
      "actual_out_amount": "64672839261950",
      "input_mint": "So11111111111111111111111111111111111111112",
      "output_mint": "pumpCmXqMfrsAkQ5r49WcJnRayYRqmXz6ae8H7H9Dfn"
    }
  },
  "instructions": [
    {
      "programName": "jupiter",
      "instructionName": "shared_accounts_route_v2",
      "decoded": {
        "args": { "in_amount": "1500000000000", "slippage_bps": 2200 },
        "accounts": [
          { "name": "user_transfer_authority", "pubkey": "GV6UUm…", "isSigner": true },
          { "name": "source_mint", "pubkey": "So1111…" }
        ]
      }
    }
  ]
}

Instead of guessing what the third address in an account list means, you read "name": "user_transfer_authority". 

Arguments arrive decoded too: "slippage_bps": 2200 vs. raw bytes.

And the transaction-level summary could be shown to users verbatim.

Each result also includes the fee and fee payer, native SOL transfers, SPL and Token-2022 transfers, and decoded custom program errors when metadata is available. 

For programs outside the catalog, instructions fall back to raw data and raw accounts, so you always have something to work with.

Parsed Streams: Decoded transactions, pushed to you

Parsed Streams is a WebSocket service that watches every confirmed transaction, decodes it, and pushes you the ones that match your filter at the instruction level, server-side.

You never touch a firehose, and you never maintain a decoder.

A filter is built from five fields:

1. programs
2. instructionNames
3. accounts (by inclusion or by named role)
4. includeCpi
5. includeFailed

For example, "every Jupiter route instruction touching this wallet" is:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "parsedTransactionSubscribe",
  "params": [
    {
      "programs": ["JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4"],
      "instructionNames": ["route", "shared_accounts_route"]
    }
  ]
}

Every notification carries the whole decoded transaction, plus matchedIndexes points to the instructions that matched your filter.

How do you get instruction names for Solana programs?

Guessing instruction names is the most common way a filter silently matches nothing. To get the instruction names for Solana programs, call describeProgram with any program's address and it returns the instructions, events, and account roles the matcher compares against:

{
  "id": "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4",
  "name": "jupiter",
  "instructions": ["route", "shared_accounts_route", "exact_out_route"],
  "events": ["SwapEvent"],
  "roles": ["user_transfer_authority", "destination_token_account"]
}

Look up the program, add the names to your filter, and then subscribe. 

The Track Jupiter Swaps guide walks this workflow end to end.

The Parsed Events API: Decoded transactions on demand

For lookups rather than live data, the Parsed Events API applies the same IDL-catalog decoding on request.

Parse Transactions takes signatures and returns them decoded.

Parsed Transaction History pages through an address's complete decoded history, and returns the newest transactions first.

curl -X POST "https://mainnet.helius-rpc.com/v1/parsed-events/transactions?api-key=YOUR_API_KEY" \
  -H "content-type: application/json" \
  -d '{"transactions": ["5xSKzM8bvpudE521jikHqASzMr23Ms4X4ieY3K8oFPFrJWCSSgYocJmHznrR8b12voDxKDH8ykdCLXSRrx6duVLH"]}'

Both methods are also available over GraphQL, so you can select just the parsed fields your app needs.

Parsed Events vs. Enhanced Transaction API

Parsed Events is the successor to the Enhanced Transactions API. 

Where Enhanced Transactions classified transactions into a fixed list of event types, Parsed Events decodes each instruction via the IDL catalog, with a raw fallback instead of UNKNOWN for unrecognized programs.

If you're using the Enhanced Transactions API today, the migration guide maps every endpoint, parameter, and response field, and includes a prompt your agent can run to complete the migration for you.

Which parsing tool is right for me?

The two new products share one decoding engine, so a transaction looks the same whether it arrived over a stream or a REST call. Importantly, you can prototype against history with Parsed Events and switch to live data with Parsed Streams without changing your parsing code.

Get started

Parsed Streams and the Parsed Events API are in open beta, and are available on all paid plans. Grab your API key from the Helius Dashboard.

To connect, use the following endpoints:

Parsed Streams: 

wss://fs-beta.helius-rpc.com/?api-key=YOUR_API_KEY

Parsed Events API: 

https://mainnet.helius-rpc.com/v1/parsed-events/...?api-key=YOUR_API_KEY

Guides

The Parsed Streams Quickstart gets you to your first decoded notification in a few minutes, and the Parsed Events Quickstart does the same for your first parsed signature. 

If you have questions, please contact our us on Telegram or Discord.