Skip to main content

なぜ移行するのか?

拡張トランザクションAPIはメンテナンスモードのレガシープロダクトです:まだ機能しますが、新しいパーサータイプや機能作業は受け付けていません。その後継は解析イベントであり、解析ストリームを強化するIDLカタログを通じて命令をデコードします。 トランザクションのデコード方法に違いがあります。拡張トランザクションはトランザクションを固定されたイベントタイプのリストの1つに分類し、知っているタイプに対して事前に構築された概要を返します。解析イベントはプログラム自体のIDLに対してすべての命令をデコードし、名前付き引数と名前付きアカウントにし、上に概要を構築します: 解析イベントは有料プランでオープンベータ中です。APIは一般提供前に変更される可能性がありますが、拡張トランザクションはその間も動作し続けるので、移行は自分のペースで進められます。

エンドポイントマッピング

解析イベントの両方のメソッドは、すでに使用しているのと同じ api-key クエリパラメータで認証され、 POST リクエストに送信されます: 履歴エンドポイントはすべての入力をクエリストリングパラメータからJSONボディに移します。リクエストボディは未知のフィールドを拒否するため、タイプミスは黙って無視されるのではなく、大々的に失敗します。

前後の比較

同じタスク — ウォレットの解析された履歴をフェッチする — を両方のAPIで:

パラメータマッピング

トランザクションの解析

POST /v0/transactionsPOST /v1/parsed-events/transactions 旧に相当する新しいオプションなし: includeRawTransaction は解析結果とともに元のSolanaトランザクションペイロードを返します。

トランザクション履歴

GET /v0/addresses/{address}/transactionsPOST /v1/parsed-events/transaction-history。すべてのクエリパラメータはJSONボディフィールドになります: 道中で3つのデフォルトが変更されます:
  • limit は100にデフォルトし、10ではありません。
  • commitmentconfirmed にデフォルトし、 finalized ではありません;processed はサポートされていません。
  • sortOrder は同じ asc/desc 値で保持し、デフォルトは desc です。
ページングには、前回のレスポンスから paginationToken を使用して、 beforeSignature を使用することをお勧めします — 以下を参照してくださいページネーションの簡素化 古い type パラメータには解析イベントに対応するものはありません — サーバー側のトランザクションタイプフィルターはありません。クライアント側で parsed.summary.type (swap, transfer, add_liquidity, …) もしくは、その命令が持つデコード情報自体を使って精度の高いフィルタリングを行います。リアルタイムなタイプ特定のフィードの場合は、解析ストリーム がサーバー側で命令レベルでフィルターします。

レスポンスフィールドのマッピング

拡張トランザクションは拡張されたトランザクションのフラットな配列を返します。解析イベントは結果を { signature, parserStatus, parsed } エンベロープでラッピングし、履歴レスポンスは paginationToken ページオブジェクトでラッピングします。解析されたフィールドは次のようにマッピングされます: そして最大の変更は古いものに相当する新しいフィールドです: parsed.instructions[] はすべてのトップレベルと内部命令を実行順に含み、decoded.argsdecoded.accounts がプログラムのIDLから名前付けされます。拡張トランザクションがトランザクションごとに1つのイベント概要を与えたのに対し、解析イベントは概要完全にデコードされた命令リストを提供します。解析レスポンスですべてのフィールドを確認してください。

移行手順

1

エンドポイントの置き換え

パーサートランザクション呼び出しを POST /v1/parsed-events/transactions に、履歴呼び出しを POST /v1/parsed-events/transaction-history に指します。同じホスト、同じ api-key クエリパラメータ。履歴リクエストは、クエリパラメータを持つ GET から、JSONボディを持つ POST に変更します — 各パラメータを上記のマッピングに従って移動します。
2

レスポンス処理の更新

新しいエンベロープをアンラップ:parserStatus === "OK" をチェックし、トップレベルの代わりに parsed からフィールドを読み取ります。timestampblockTime にリネームし、summary から descriptiontype を読んで(null をガード)、古いコードが tokenAmount を読んだ場所で 10^decimalsrawTokenAmount を割ります。
3

タイプフィルタリングの置き換え

古いコードが type=... を渡した場所で、返されたアイテムをクライアント側で parsed.summary.type または parsed.instructions[] でフィルタリングします — 例えば、“命令で programId が Jupiter で instructionNameroute”は、type=SWAP を実際に検証できる何かに置き換えます。タイプフィルターがリアルタイムフィードを駆動するために存在した場合、そのコンシューマーを解析ストリームに移動し、サーバー側で命令レベルでフィルターします。
4

ページネーションの簡素化

before-signature カーソルループを paginationToken に置き換えます:
ループは paginationToken が欠落すると終了します。古いランタイム検索エラー(“検索期間内にイベントを見つけられませんでした”)とその継続シグネチャの処理は完全に消えます — そのコードを削除します。
5

古い出力に対して検証

サンプルアドレスに対して、両方のAPIから同じページをフェッチし、シグネチャセット、料金、転送額を比較します。その後、デプロイして古いコードパスを削除します。拡張トランザクションは移行中はそのまま動作します — 強制的なカットオフはありません。

レビューすべき動作の違い

  • コミットメントのデフォルト。 履歴は古いエンドポイントが finalized にデフォルトするところで confirmed にデフォルトします。パイプラインが最終性に依存する場合は commitment: "finalized" を明示的に渡します。processed はサポートされていません。
  • アイテムごとのエラー。 パースできないシグネチャはリクエストを失敗させず、parserStatus: "ERROR"parserError を持つアイテムとして戻ってきます。リクエスト単位ではなくアイテム単位で処理してください。
  • 概要のカバレッジ。 summary は認識されたトランザクションレベルのアクションがない場合に nullです。この場合、古いAPIは type: "UNKNOWN" を返しましたが、新しいAPIはすべてのデコードされた命令を扱うことができます。
  • アクセス。 解析イベントは有料プランでオープンベータ中であり、APIは一般提供前に変更される可能性があります。

AIエージェントに移行をさせる

Claude Code、Cursor、または他のコーディングエージェントを使用している場合は、以下のプロンプトをリポジトリのエージェントセッションに貼り付けてください。これは拡張トランザクションのコールサイトを見つけ出し、それらを書き換えます。
このプロンプトは自己完結型です — エージェントがこのページにアクセスする必要はありません。エージェント対応のドキュメント、MCP検索、スキルについては、AIエージェント向けHeliusを参照してください。

次のステップ

解析イベントクイックスタート

最初のトランザクションを解析し、アドレス履歴をフェッチし、結果をページングします。

解析レスポンス

解析されたトランザクション、転送、命令のフィールド参照。

解析ストリーム

サーバー側でフィルタリングされたWebSocketでリアルタイムの同じデコードを提供。

getTransactionsForAddress

トークンアカウントサポート、サーバー側フィルターを伴う生トランザクション履歴。