Introducing the New Brale API Docs: Faster Stablecoin Integrations, Less Guesswork

Stablecoin integrations don't stall at minting. They stall in the details.

ACH return windows. Transfer state transitions. Consent capture. Missing parameters that only show up after your third support ticket.

If you've ever evaluated a stablecoin API and wondered how it behaves in production, you know the gap between what's documented and how money actually moves.

That's why we're excited to launch the new Brale API Docs, revamped to close that gap and help teams move from API credentials to a first successful transfer, faster.

What's new

Ask AI: LLM-powered documentation querying

The most requested improvement from active integrators is officially live!

You can now query the Brale documentation directly using an embedded AI assistant.

Ask a question and get a direct answer, with links to the exact endpoints, parameters, and workflows involved.

Use it to:

Instead of scanning multiple pages, you can move from question to working code in seconds.

Try asking:

• How do I set up an ACH debit onramp to a self-custody wallet?
• How do I onramp via wire or virtual accounts?
• How do I handle KYB for my customers?

For complex integrations, this is the fastest way to find what you need.

A clear path from API key to first transfer

Instead of reverse-engineering object relationships across endpoints, you now follow a linear path that mirrors how real systems are built. From credentials → required IDs → first transfer, dependencies are explicit.

Bonus: We've also improved navigation by workflow.

Beyond endpoint-level improvements, documentation is now structured around how teams actually build:

Core concepts and workflows are easier to find. You can now navigate by use case, not just by endpoint name. Or use the new AI assistant to jump directly to what you need!

Complete schemas & explicit retrieval parameters

We audited the core primitives and closed real-world gaps:

• Clarified Accounts endpoint intent and response structures
• Documented previously missing Transfers retrieval parameters
• Completed Addresses request documentation (required fields and examples)
• Standardized request/response examples
• Marked deprecated flows clearly with supported alternatives

If a parameter is required, it's documented. If a transfer can be retrieved or filtered, the query parameters are listed. If something is deprecated, you'll know what to use instead.

Because we know that for teams building against a regulated stablecoin API, predictability matters.

Dedicated ACH onboarding & debit flow clarity

Many stablecoin programs depend on U.S. bank rails. That's where operational nuance lives and where integrations often slow down.

The updated docs now make ACH debit behavior and Plaid orchestration explicit.

Updates include:

• A dedicated ACH onboarding section
• Clear separation between ACH debits and credits
• Explicit debit lifecycle documentation (posting → settlement → returns)
• Consolidated Plaid routes under: /accounts/{account_id}/plaid/*
• Clarified token exchange vs transfer initiation
• Explicit documentation of how Plaid-linked accounts connect to Transfers
• Removed ambiguity between legacy Financial Institutions guidance and supported flows

If you're building a fiat-to-stablecoin onramp or ACH debit integration, the behavior of funds over time is now clearly explained, not implied.

Supported paths: compliance built-in, legacy removed

In regulated stablecoin programs, getting it almost right isn't good enough.

Compliance steps like presenting the End-User Agreement (EUA) and capturing consent aren't optional, and neither is building on supported flows. The updated documentation makes both explicit.

On the compliance side, you'll now see:

• How and when to present the End-User Agreement (EUA)
• How to capture and record user consent before onboarding
• Where compliance gating intersects with account creation and transfers

Instead of separating compliance into standalone policy documents, this guidance now appears directly inside the onboarding flows where you actually implement it.

The same principle applies to integration paths.

Nothing creates integration risk faster than realizing you built on a legacy path, so we've formally deprecated standalone Financial Institutions guidance in favor of the supported pattern:

Addresses + Transfers

Deprecated flows are clearly labeled, and the recommended alternative is explicitly documented.

No hidden routes. No outdated examples. No ambiguity about what's current.

If you're maintaining an existing integration, you can now verify you're building on the supported path without second-guessing what's current.