wire, ach_debit, and fednow_credit. There are three common ways of funding a custodial wallet at Brale (type: internal) using offchain transfers:
- Submit a Transfer request with a source
transfer_typeofwire - Submit a Transfer request with a source
transfer_typeofach_debit - Create an Automation, which automatically mints stablecoins to a pre-configured destination wallet when funds are received via ACH, wire, or FedNow.
Submitting a Transfer request with a source transfer_type of wire
Here is an example of onramping to your own stablecoin (SBC) via wire transfer by calling the Transfers endpoint with the source transfer_type of wire.
POST https://api.brale.xyz/accounts/account_id/transfers
Request
Response
pending. Once Brale receives the funds at the bank account provided in wire_instructions the stablecoins will immediately be minted to the destination wallet.
Submitting a Transfer request with a source transfer_type of ach_debit
You can initiate ACH debits from Plaid-linked addresses. See Addresses for the full flow of linking Plaid accounts as addresses you can pull from. This guide is specifically designed for first party funding of stablecoin mints, into a Brale custodial wallet.
POST https://api.brale.xyz/accounts/account_id/transfers
Request
Response
Fetching Transfers
Query a transfer that has been created. GEThttps://api.brale.xyz/accounts/account_id/transfers/:id
Response
source.payment_details appears when Brale has underlying payment metadata to expose for the source leg of a transfer. Wire transfers typically include the full set of fields (sender_name, sender_bank_name, imad, etc.). ACH transfers may include only a subset — fields may be null or omitted depending on available rail metadata, and may include trace_number as the ACH trace identifier. See Transfers — source.payment_details for the full field reference.Wire payment references
If a sender enters a reference in their bank’s “Message to receiving bank” field, Brale can expose it insource.payment_details.payment_reference. Some banks call this field “Instruction for Creditor Agent.” Brale uses it only when the instruction is received and no higher-priority reference is available. An existing memo, Originator-to-Beneficiary Information (OBI), or remittance reference keeps its current precedence.
payment_reference is an existing response-only field. It is not a request parameter, and it may be null or absent. Availability depends on the metadata the sending bank supplies and Brale receives, so not every inbound wire includes a reference.
Illustrative Transfer response excerpt:
Response excerpt
Fiat to Stablecoin Automation (Automatic Onramp)
Automations provide a unique account number and routing number that accepts wire transfers, ACH deposits, and FedNow credits (on accounts with FedNow enabled), and automatically reconciles funds received and mints them to a bound wallet address. See Receive FedNow deposits.
Here is an example of onramping to your own stablecoin (SBC) via wire transfer by creating a fiat-to-stablecoin automation.
Automations mint Brale-issued stablecoins, such as
SBC. USDC is not a supported Automation destination. To deliver USDC, mint a Brale-issued stablecoin with the Automation, then create a separate swap Transfer to USDC. See Onramp to USDC.https://api.brale.xyz/accounts/account_id/automations
Request
source.transfer_type. A USD Automation accepts the inbound rails enabled for its virtual account, and responses may return source.transfer_type: null.
Automations are created in a pending state and transition to active when the virtual account is ready.
When an automation becomes active, the source.funding_instructions object is populated with the virtual account’s bank details (routing number, account number, beneficiary name, etc.). These are the coordinates you share with your customer to fund the automation.
GET https://api.brale.xyz/accounts/{account_id}/automations/{automation_id}
Response
When an automation is no longer needed, archive it by sendingPATCH /accounts/{account_id}/automations/{automation_id}with{ "status": "archived" }. This closes the virtual account and stops future deposits from being processed.
Test an Automation on testnet
Testnet Automations return placeholder banking coordinates that cannot receive real deposits. Use Simulate an Automation deposit to test the full onramp flow without moving real fiat. Prerequisites:- Testnet API credentials with the
automations:writeandnetwork:testnetscopes. See Sandbox and Testnet. - A custodial wallet address on a testnet chain, such as
base_sepoliaorsolana_devnet. - A webhook subscription that includes
payment.completed.
1. Create an Automation
POSThttps://api.brale.xyz/accounts/{account_id}/automations
Request
2. Wait until the Automation is active
PollGET /accounts/{account_id}/automations/{automation_id} until status is active. Brale returns 422 automation_not_active if you simulate a deposit before then.
3. Simulate a deposit
POSThttps://api.brale.xyz/accounts/{account_id}/automations/{automation_id}/simulations/deposits
transfer_type accepts ach, wire, or fednow. A fednow simulation produces a Transfer with source.transfer_type: "fednow_credit". Brale returns 202 Accepted with the resulting Transfer. Save its id.
Use a new Idempotency-Key for each new simulated deposit. Retrying with the same key returns the original response without creating another deposit or mint. See Idempotency.
4. Receive webhooks
Brale emits the normalpayment.completed webhook event for the simulated inbound payment. There is no simulation-specific webhook type, so your production handler works unchanged.
5. Fetch the Transfer
GEThttps://api.brale.xyz/accounts/{account_id}/transfers/{transfer_id}
Response
6. Verify the testnet mint
Confirm thatautomation_id matches your Automation and status is complete. Look up destination.transaction_id in a block explorer for the testnet chain to verify the mint.