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に公開しました：

  • BraleのTransferTypes一覧

  • BraleのValueTypes一覧

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

その他の所見

  • ローカル環境で実行する場合は、CORSの問題が発生する可能性があるため、プロキシを使用してください。

  • 認証は auth.brale.xyz で行われ、それ以外はすべて api.brale.xyz で行われます。

  • account_id と address_id の区別については、注意を怠るとまだ小さなバグが発生することがあります。

  • これらのテストアプリは認証情報をローカルに保存しているため、本番環境での使用には適していません。これは意図的な仕様です。

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

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