Skip to main content

なぜ移行するのか?

拡張トランザクションAPIはメンテナンスモードのレガシープロダクトです:まだ機能しますが、新しいパーサータイプや機能作業は受け付けていません。その後継は解析イベントであり、解析ストリームを強化するIDLカタログを通じて命令をデコードします。 トランザクションのデコード方法に違いがあります。拡張トランザクションはトランザクションを固定されたイベントタイプのリストの1つに分類し、知っているタイプに対して事前に構築された概要を返します。解析イベントはプログラム自体のIDLに対してすべての命令をデコードし、名前付き引数と名前付きアカウントにし、上に概要を構築します: Parsed Eventsは、Freeを含むすべてのプランで正式に提供されており、リクエストあたり10クレジットです。Enhanced Transactionsはメンテナンスモードで引き続き動作するため、ご自身のペースで移行できます。

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

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

前後の比較

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

パラメータマッピング

トランザクションの解析

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

トランザクション履歴

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

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

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

移行手順

1

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

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

レスポンス処理の更新

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

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

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

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

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

古い出力に対して検証

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

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

  • コミットメントのデフォルト値。 History のデフォルトは confirmed ですが、旧エンドポイントのデフォルトは finalized でした。パイプラインがファイナリティに依存している場合は、commitment: "finalized" を明示的に渡してください。processed はサポートされていません。
  • 項目ごとのエラー。 解析できない署名がリクエスト全体を失敗させることはなくなりました。代わりに、parserStatus: "ERROR" と parserError を含む項目として返されます。リクエスト単位ではなく、項目単位で処理してください。
  • サマリーの対象範囲。 認識されたトランザクションレベルのアクションがないトランザクションでは、summary は null になります。その場合、旧 API は type: "UNKNOWN" を返していました。新しい API でも、デコードされたすべての命令を利用できます。
  • アクセスとコスト。 Parsed Events はすべてのプランで利用でき、リクエストあたりのコストは 10 クレジットです。Enhanced Transactions の 100 クレジットから引き下げられています。

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

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

次のステップ

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

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

解析レスポンス

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

解析ストリーム

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

getTransactionsForAddress

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