#ビットコインAPI取引の最初の壁
ビットコイン取引所のAPIを利用しようとして、おそらく殆どの人が最初につまづくのは認証の部分でしょう。
各取引所で微妙に仕様・作法が異なる上、エラーになっても「認証に失敗しました」などの、なんの手がかりも与えてくれない無慈悲なメッセージが帰ってくるだけです。
私自身も裁定取引のアプリケーションを作るにあたり、新しい取引所を追加するたびに、認証方式の微妙な違いにぶつかり手間取ってしましました。
自分の失敗を晒すことで、この記事が今後API取引にトライする方々の助けになればと思います。
#認証のフロー
はじめに、認証の一般的なフローを説明します。
プログラミング言語にかかわらず、HTTPリクエストを作成するという観点では同じフローになります。
- 取引所Webサイトからキー、シークレットを発行する。
- 各オペレーション(オーダー送信、ポジション取得等)のAPIのURLとパラメータリストを用意する。
- 各取引所で定められた方式で各データを連結し、「メッセージ」文字列を作成する。
- メッセージ文字列をシークレットを使ってハッシュ化する。
- 適切なContent-Typeヘッダーを設定する。
- その他のHTTPヘッダーを設定する。
- HTTPリクエストを送信する。
どの取引所も、大枠としてはこのフローに従っているのですが、メッセージ文字列の作成方法等、各々で独自の加工が必要になります。
このフローのどの部分を間違えても、取引所からのエラーレスポンスは何が間違っていたのか教えてくれません。おそらく認証がうまくいかずAPI取引を諦めた人も多数いることかと思います。
認証方式テーブル
そこで、以下に各取引所の認証方式をテーブルにまとめました。
| Exchange | メッセージ内容 | メッセージ連結方法 | ハッシュアルゴリズム | Content-Typeヘッダー | その他の必須ヘッダー |
|---|---|---|---|---|---|
| Bitflyer | - Nonce - HTTPメソッド名 - パス: /v1/me/から始まる文字列 |
文字列の連結 | HMAC-SHA256 | application/json | - ACCESS-KEY - ACCESS-TIMESTAMP - ACCESS-SIGN |
| Coincheck | - Nonce - URL: httpsから始まるURL全体 - リクエストボディ |
文字列の連結 | HMAC-SHA256 | application/x-www-form-urlencoded | - ACCESS-KEY - ACCESS-NONCE - ACCESS-SIGNATURE |
| Quoine | - Nonce - パス - キー |
JSON Web Token | HMAC-SHA256 | application/json | - X-Quoine-API-Version (常に“2”) - X-Quoine-Auth (シグニチャ) |
| Zaif | - Nonce - APIメソッド名 - APIパラメータ |
クエリ文字列 | HMAC-SHA512 | application/x-www-form-urlencoded | - Key - Sign |
| Bitbank | - Nonce - パス: /v1から始まる文字列 (GETリクエスト時のみ) - リクエストボディ (POSTリクエスト時のみ) |
文字列の連結 | HMAC-SHA256 | application/json | - ACCESS-KEY - ACCESS-NONCE - ACCESS-SIGNATURE |
太字の部分が私自身がハマったポイントです。
特に"/v1"等の部分を含むか含まないかは、ドキュメントに記述が見つからず手探りで繰り返し試行して判明しました。
また、Content-Typeヘッダーもドキュメントに書いていないケースが散見されました。
Quoine APIの品質
余談ですが、上記した取引所の中ではQuoineのAPIの品質が最もよいと思います。APIの設計もとてもクリーンで、扱いやすいものとなっています。
また、レバレッジ取引でネットアウトをサポートしている点など、裁定取引で非常に使いやすい取引所です。
WebのUIにはやや難がありますが(特に入出金)、個人的にはお気に入りの取引所です。