

Money moves fast these days. We all need quick and convenient updates on the status of our transfers. Brale is the Grand Central Station of tradfi and defi payment rails and you want someone to tell you when the train arrives, you don't want to have to keep checking the tracks.
We're rolling out Webhooks to push event-driven notifications to you through the Brale API. We're starting with events related to Transfers.
These webhooks will notify the moment something does change by sending a web request to an endpoint you build and provide. All with the reliability, security, and the operational guardrails you need in a regulated environment.
With Brale's API, everything is a transfer. This is supported by both onchain and offchain transfer types. Our API leverages polymorphism to hide the complexity of the differences between traditional banking rails and web3 rails. This includes currencies, accounts, and the type of a transfer. Our webhook implementation is aligned with this mental model. It doesn't matter if you are transferring with a wire to a stablecoin on Solana, swapping between tokens, or moving funds between two different blockchains. It's all a transfer.
So, behind the scenes, every transfer is different. One of the goals of our webhook implementation is to completely hide that complexity. A transfer is transfer. It doesn't matter if it involves API requests to banking infrastructure, or half a dozen blockchain transactions.
If you're new to webhooks, you can think of them as a reversed API. Instead of your app calling Brale to ask "what happened?", Brale calls your app the moment something does. You build an HTTP endpoint, we send you a defined payload, you react to it.
To get started, you build and host an endpoint, and subscribe it with our new API. When something happens to a transfer we send an HTTP POST to your endpoint with a structured payload describing the event. Your app receives it and does whatever you need: update a UI, fire a notification, kick off the next step in a workflow. We also offer an endpoint to get delivery logs, which we can use for troubleshooting and auditing.
Build your endpoint, subscribe it through the API, and start receiving real-time transfer events.
When you build your webhook endpoints, keep these in mind:
- 1
Create a new dedicated API Key — we've introduced a new scope for webhooks.
- 2
Your endpoint should respond quickly and kick off any workflows asynchronously. There is a 30 second timeout.
- 3
The
sharedSecretis only returned when the webhook subscription is created, so don't lose it. Save it securely. - 4
We sign the message with an HMAC signature in the
x-request-signature-sha-256header, which you can verify against the payload with yoursharedSecret. - 5
Every request has a unique
idempotency-key.
Our preliminary testing at a large volume across multiple payments rails shows a 20%+ reduction in perceived client-side transaction latency. It's impossible to line up a polling schedule consistently with actual finality, so you'll see the benefits of webhooks relative to your polling window. Effectively, the last poll on every transfer introduced a time delay buffer that is now going to be removed from your workflows. If I poll every :30 seconds, and the event completes at :31, then I would have to wait :29 seconds to know an order has completed. With webhooks, not anymore.
We're really excited to hear about your experience building with them and the improvement you see for your products and workflows. This is just the beginning, and there a wide-breadth of webhooks we are looking forward to iteratively rolling out. Let us know what webhook events you want next, and how your experience has been. Our docs include everything you need to get started.
Get real-time transfer notifications pushed directly to your app — no more polling.
Contributors
Edward FlemingHead of Engineering
Chris KnutsonSr Software Engineer- KCKasey CantuSoftware Engineer





