New Brale Stablecoin API

Posted on by Ben Milne

Brale recently shipped an updated version of the stablecoin APIs. The project started with a design cohort in Q1, moved into development in Q2, and ended up in production with real customers shortly after.

There’s a lot the API does. This post isn’t a breakdown of all that functionality. It’s just a record of how I’ve been testing things mostly for fun, and partially to understand how others might approach using it for the first time.

Using LLMs to Work Through the API

The last time I was working on something like this, large language models weren’t really part of the workflow. That’s changed. With Cursor and some decent prompting, it’s now easy to throw together working prototypes and test assumptions in real time.

I still like using Postman to explore APIs, but I wanted to see what it felt like to use the Brale API inside something a little closer to a real interface.

First Test: Auth

I started with a basic authentication flow—using a client_id and client_secret to get a bearer token. Nothing fancy. Just enough to prove the credentials worked and were scoped properly.

That small test lives here: github.com/superduperdot/auth-app

Second Test: Balances

This turned out to be a little more involved. The Brale API supports multiple value types (each representing a distinct asset) and multiple transfer types (each representing a chain or network). So the process to retrieve balances went like this:

  • Get the account_id associated with your credentials
  • Use that ID to pull the list of addresses
  • Filter the results by type: “internal” to isolate custodial wallets
  • Iterate through every known value type and transfer type combination
  • Query balances and log what returns

That app is here: github.com/superduperdot/balance-app

Chasing Down Supported Types

The TransferTypes are well documented. The ValueTypes aren’t exposed directly in the docs yet, so I pulled them from the live application and dropped both lists in GitHub for future reference:

Getting pricing from the data endpoint also worked well.

Other Observations

  • If you’re running locally, expect CORS issues, use a proxy.
  • Authentication happens at auth.brale.xyz; everything else is at api.brale.xyz.
  • The distinction between account_id and address_id still creates small bugs for me if I’m not careful.
  • These test apps store credentials locally and aren’t safe for production use. That’s intentiona

Nothing here is final. These tests were mostly about speed and usability. The goal was to see how quickly you can go from credentials to something real, without relying on internal tooling or deep knowledge of the platform.

If you’re exploring the Brale API, maybe this shortens the path. If not, it was still worth the time to see how the new layer behaves in the wild. The CLI can be helpful kicking the tires too.