Brale 先日、stablecoinのAPIの更新版をリリースしました。このプロジェクトは第1四半期に設計チームを立ち上げて始まり、第2四半期に開発段階へ移行し、その後まもなく実際の顧客向けに本番環境へ移行しました。

APIには多くの機能があります。この記事は、そのすべての機能を解説するものではありません。あくまで、私が主に楽しみ半分で、また一部は他の方が初めてこれを利用する際にどのようなアプローチを取るかを理解するために、どのようにテストを行ってきたかを記録したものです。

LLMを活用してAPIを検証する

以前、私が同様の作業に取り組んでいた頃、大規模言語モデル（LLM）はワークフローの一部ではありませんでした。しかし、状況は変わりました。Cursorと適切なプロンプトを使えば、動作するプロトタイプを簡単に作成し、仮説をリアルタイムで検証できるようになりました。

APIの探索には依然としてPostmanを使うのが好きですが、実際のインターフェースに近い環境でBrale（API）を使ってみるとどのような感じになるのか試してみたかったのです。

最初のテスト：認証

まずは基本的な認証フローから始めました。client_idとclient_secretを使ってベアラートークンを取得するだけです。特別なことは何もしていません。認証情報が機能し、スコープが適切に設定されていることを確認するのに十分な程度です。

この小さなテストはこちらにあります：github.com/superduperdot/auth-app

2つ目のテスト：残高

こちらは少し手間がかかりました。Brale API は、複数の値タイプ（それぞれが異なる資産を表す）と複数の転送タイプ（それぞれがチェーンまたはネットワークを表す）をサポートしています。そのため、残高を取得するプロセスは次のようになりました：

  • 認証情報に関連付けられた account_id を取得する
  • そのIDを使用してアドレスのリストを取得する
  • 結果をタイプでフィルタリングする：「internal」でカストディアルウォレットを抽出
  • 既知のすべての値タイプと転送タイプの組み合わせを順に処理する
  • 残高を照会し、返された結果をログに記録する

そのアプリはこちら：github.com/superduperdot/balance-app

サポートされているタイプの調査

TransferTypesについては十分にドキュメント化されています。ValueTypesについてはまだドキュメントに直接記載されていないため、実稼働中のアプリケーションから取得し、今後の参考のために両方のリストをGitHubに公開しました：

データエンドポイントからの価格情報の取得も問題なく動作しました。

その他の観察事項

  • ローカル環境で実行している場合は、CORSの問題が発生する可能性があるため、プロキシを使用してください。
  • 認証は auth.brale.xyz で行われ、それ以外はすべて api.brale.xyz で行われます。
  • account_id と address_id の区別は、注意しないとまだ小さなバグの原因になります。
  • これらのテストアプリは認証情報をローカルに保存するため、本番環境での使用には適していません。これは意図的な仕様です。

ここにある内容はどれも最終的なものではありません。これらのテストは主に速度と使いやすさを重視したものです。目的は、内部ツールやプラットフォームに関する深い知識に頼ることなく、認証情報から実用的なものへとどれだけ素早く移行できるかを確認することでした。

Brale API を検討中なら、この情報が道のりを短縮するかもしれません。そうでない場合でも、新しいレイヤーが実環境でどのように動作するかを確認する価値はありました。CLI を使って試してみるのも役立つでしょう。