概要
暗号資産取引所の API は、REST の Public / Private とリアルタイム配信の WebSocket という構成がほぼ共通しています。一方で、署名の作り方とレート制限の刻み方は取引所ごとに違い、ここを吸収せずに書くと取引所を増やすたびにロジックが分岐します。
国内の例として bitFlyer Lightning API を見ると、Private API の認証は ACCESS-KEY / ACCESS-TIMESTAMP / ACCESS-SIGN の 3 ヘッダで、署名は「タイムスタンプ + HTTP メソッド + リクエストパス + リクエストボディ」を API シークレットで HMAC-SHA256 したものです。リアルタイム配信は WebSocket 上の JSON-RPC 2.0 で提供されます。
技術仕様
公式ドキュメントで確認した内容です。出典はページ末尾に記載しています。仕様は更新されることがあるため、実装前に一次資料をご確認ください。
- 一般的な構成
- REST（Public / Private）+ WebSocket によるリアルタイム配信
- 認証（bitFlyer の例）
- ACCESS-KEY / ACCESS-TIMESTAMP / ACCESS-SIGN の 3 ヘッダ。HMAC-SHA256
- 署名対象（同）
- タイムスタンプ + HTTP メソッド + リクエストパス + リクエストボディ
- リアルタイム（同）
- JSON-RPC 2.0 over WebSocket
- レート制限（同）
- IP あたり 5 分で 500 回、Private API も 5 分で 500 回。注文系の一部エンドポイントは合算で 5 分 300 回
- 小口注文の制限（同）
- 数量 0.1 以下の注文は 1 分で 100 回
- 超過時の挙動（同）
- 一時的にアクセスが制限され、その後の上限も引き下げられる
受託の範囲
- 取引所非依存のインタフェース設計と、取引所ごとのアダプタ実装
- レート制限を織り込んだリクエスト制御（トークンバケット・優先度制御）
- WebSocket の購読管理、切断復帰、スナップショットと差分の整合
- 注文の冪等性設計と、約定・残高の突合バッチ
- API キーの保管と権限分離（出金権限を持たせない運用を含む）
実装で詰まりやすい点
レート制限は「超えなければよい」ではない
超過すると一時的な制限に加えて、その後の上限自体が引き下げられる取引所があります。上限ぎりぎりを狙うのではなく、余裕を持った制御と、制限に当たった場合の縮退動作を先に決めておきます。
注文系だけ別枠の制限がある
全体のレート制限とは別に、注文系エンドポイントに合算の上限が設けられていることがあります。一般的な API 呼び出しと同じキューで扱うと、相場が動いたときに注文が通らなくなります。
WebSocket の再接続で状態が壊れる
切断・再接続のたびにスナップショットを取り直さないと、板や残高の状態が実際とずれます。差分だけを積み上げる実装は、切断を経験した時点で信用できなくなります。
API キーに出金権限を付けない
自動取引に必要なのは発注と参照の権限です。出金権限を持つキーを常時稼働のシステムに置くと、鍵の漏洩がそのまま資産の流出になります。
関連する解説記事
参照元
暗号資産取引所 API についてよくあるご質問
複数の取引所へ同時に接続できますか。
対応します。取引所ごとに署名方式とレート制限が違うため、共通のインタフェースを定義したうえで差異をアダプタに閉じ込める構成にします。取引所を追加するときに業務ロジックへ波及しない形にしておくのが要点です。
自動取引の実運用まで任せられますか。
要件定義から本番運用まで一貫して請け負います。とくに注文の冪等性、レート制限時の縮退、約定と残高の突合といった、運用に入ってから効いてくる部分を設計段階で織り込みます。