このページは機械翻訳されています。英語の原文が正式版です。 英語で読む →
メインコンテンツにスキップ

APIエラー

リクエストに対応するレスポンスの形式を使用してください。

  • HTTPエラー: 4xx または 5xx のJSONレスポンスには、安定した code フィールドと診断用の message フィールドが含まれます。
  • 注文結果: HTTP 200 の注文レスポンスでも、注文が拒否されている場合があります。status と reason を確認してください。
  • JSON-RPCレスポンス: JSON-RPCエンドポイントは、HTTP 200 レスポンス内に数値の error.code を保持します。

HTTPエラーレスポンス​

APIが生成するすべてのHTTP 4xx および 5xx のJSONエラーレスポンスには、以下が含まれます。

{
  "error": "existing endpoint value, when present",
  "code": "invalid_field",
  "message": "price must be greater than zero"
}

code はプログラムで扱うための契約です。 この小文字の識別子で分岐し、将来追加される未知の値も安全に処理してください。message は診断用のテキストです。 表示やログ出力には使用できますが、パースしないでください。

error は互換性のために残されているレガシーフィールドです。 一部のエンドポイントではすでに公開されており、今後も引き続き返されますが、内容は不透明であり新しい契約ではありません。readinessの詳細や Retry-After など、既存のエンドポイント固有のフィールドも引き続き含まれます。

HEAD レスポンスにはボディがありません。HTTPステータスを通常どおり使用してください。Hypercallは別途エラーコード用のヘッダーを追加しません。

出金の事前チェック​

Core配信のUSDC出金では、新しい出金を受け付ける前に、受取人のアクティベーション状態と送金の互換性を確認します。withdrawal_destination_inactive と withdrawal_destination_mode_unsupported は送金先のエラーとして処理してください。withdrawal_preflight_unavailable は、検証が一時的に利用できないことを意味します。withdrawal_source_unavailable は、サービス側で互換性のある送金元アカウントまたはルートを復旧する必要があることを示します。

これらのエラーによって新たな出金の引き落としが発生することはありません。以前に受け付けられたリクエストは既存のステータスを維持します。事前チェックが成功しても着金は保証されないため、出金の実行ステータスを引き続き確認してください。EVMのみの出金では、HyperCoreアカウントの適格性は不要です。

ポートフォリオ証拠金のアカウントモード​

ポートフォリオ証拠金は、HyperCoreのエクイティに基づいてAccountを評価します。HyperCoreがエクイティを公開するのは、unifiedAccount モードのAccountのみです。

  • portfolio を指定した POST /margin-mode は、Accountが別のモードの場合に 400 pm_account_not_unified を返します。abstractionに unifiedAccount を指定して hl_set_abstraction ディレクティブに署名し、HyperCoreでの確認を待ってから再試行してください。
  • 現在のHyperCoreエクイティがないポートフォリオ証拠金Accountに対する GET /portfolio は、HyperCoreがそのAccountのエクイティを一度も公開しておらず、かつ別のモードであると報告している場合に 409 pm_account_not_unified を返します。それ以外の場合は、最新のunifiedスナップショットがエンジンに届くまで 503 pm_account_equity_pending を返します。保持されているエクイティが古く、HyperCoreが別のモードを報告している場合、メッセージにそのモード名が含まれます。pm_account_equity_pending の場合は少し待ってから再試行し、メッセージでAccountがunifiedモードから外れたことが示されている場合は、unifiedモードを再度有効にしてください。
  • account_abstraction_unavailable (503) は、HyperCoreのアカウントモードを読み取れなかったことを意味します。少し待ってから再試行してください。

RFQレッグのサイズ​

契約サイズは 0.000001 単位で執行されます。POST /rfq/request は、小数点以下7桁以上のレッグサイズをHTTP 400 で拒否します。メッセージには、切り捨てた上で執行可能な最大サイズが示されます。テイカーは正確なレッグサイズに署名するため、Hypercallがサイズを自動で丸めることはありません。署名前に切り捨ててから再送信してください。

RFQクォートの事前チェック理由​

事前チェックで拒否されたメイカーのクォートには、短い理由コードが付与されます。margin_rejected は、メイカーのアカウントがパッケージに対する証拠金チェックを通過しなかったことを意味します。pricing_unavailable は、インプライド・ボラティリティのサーフェスや参照価格が欠けているなどの理由で、取引所がパッケージを評価できなかったことを意味します。これは証拠金に関する判断ではなく、価格算出が復旧すれば新しいクォートは成功する可能性があります。

注文拒否​

注文は、実行結果が拒否であっても HTTP 200 を返す場合があります。

{
  "status": "REJECTED",
  "reason": "Insufficient margin: required=1500.00, equity=1200.00, shortfall=300.00, current_consumed_initial_margin=900.00, incremental_order_initial_margin=600.00, current_consumed_maintenance_margin=500.00, incremental_order_maintenance_margin=250.00"
}

reason は説明用のテキストであり、安定したコードではありません。 リアルタイムの値を含むことがあり、検証ロジックの変更に伴って変わる可能性があります。ポートフォリオ証拠金が不足している場合、required は注文後の当初証拠金の合計であり、current_consumed_* と incremental_order_* の各フィールドは既存の使用分と新規注文分を区別します。拒否された注文の判定には status を使用し、reason は表示またはログ出力に使用してください。安定した注文拒否コードの契約を提供するには、別途プロトコルとSDKの対応が必要です。

ポートフォリオ証拠金のパーペチュアル注文では、open_orders_initial_margin は、有効な注文全体で個別に選択可能な未約定状態または指値全量約定状態のうち、最悪のケースから生じる追加の当初証拠金（IM）です。アカウントがIMを下回っている状態でも、その注文を追加することでこのエンベロープや、対応する最悪約定時の維持証拠金容量要件が増加しない場合に限り、注文が受け付けられることがあります。未約定注文は、公開されるポジションの維持証拠金（MM）には引き続き影響しません。クライアントは、注文が受け付けられたことをもって現在のアカウントに十分な資金があると推測してはならず、また、資金が十分な受付と悪化させない受付を区別するために診断用の reason をパースしてはなりません。

JSON-RPCエラー​

GET /orderbook は、存在しない銘柄に対して、HTTP 200 でJSON-RPC形式のレスポンスを返します。

{
  "jsonrpc": "2.0",
  "error": {
    "code": 13020,
    "message": "not_found",
    "data": {"object": "instrument_name", "value": "BTC-20200101-1-C"}
  },
  "testnet": false,
  "usDiff": 1,
  "usIn": 1791273938274109,
  "usOut": 1791273938274109
}

数値の error.code で分岐してください。RSM固有のJSON-RPCコードは、デフォルトの公開HTTPカタログには含まれません。

公開エラーコードカタログ​

この検索可能なカタログは、公開されている OpenAPIドキュメント の info.x-hypercall-error-codes 拡張から生成されています。利用者向けのHTTPコードと、常時有効なJSON-RPCコードのみを掲載しています。

Loading API error catalog…

処理チェックリスト​

  • HTTPクライアント: code で分岐し、HTTPステータスを保持し、Retry-After がある場合はそれに従ってください。
  • 注文クライアント: HTTPリクエストが成功していても、status: "REJECTED" は実行結果として扱ってください。
  • JSON-RPCクライアント: エンドポイント本来のプロトコルに従い、数値の error.code で分岐してください。
  • すべてのクライアント: 将来追加される未知のコードに対して安全なフォールバックを用意し、診断メッセージは決してパースしないでください。
最終更新: