Brails blocks every request arriving from an IP you have not whitelisted, and each entry on the list needs a 2FA confirmation. Send payout and wallet API calls through two fixed static EU IPs, confirm the pair once, and every call leaves from an address Brails already trusts.
# one variable pins egress on every surface
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
# unapproved source IPs are blocked,
# so leave from approved ones
curl -s "https://api.onbrails.com/api/v2/customers" \
-H "Authorization: Bearer $BRAILS_API_KEY"
Brails documents the feature plainly: only whitelisted API server IPs may call the platform, and everything else gets blocked. The rule is simple to state and punishing to operate when your egress address refuses to hold still.
The IP whitelisting guide says it outright: requests from any unapproved IP get blocked, and the docs add that this includes your own requests if the address is missing from the list. One rotating egress hop and the payout service that worked yesterday is locked outside its own account.
Adding an address means the dashboard, Settings, the Add IP Address button, a carefully typed IP, and a two-factor code to confirm it all. Cloud platforms that hand you a fresh egress address after every redeploy turn each deploy into an authenticated dashboard detour on the road to production.
Brails tells teams running multiple servers, microservices, or mobile backends to add the IP of each machine that calls the API. Autoscaled pods and ephemeral functions have no such address to name, which describes exactly the fleet most payment platforms run on today.
The documented flow asks for a Quote covering rate, fee, and expiry, then initiation with a beneficiaryId or an inline beneficiary object, then tracking until SUCCESS. Every hop is an authenticated request from your servers, so an address change mid-transfer breaks the chain at its most expensive step.
Your Platform
payouts · collections · virtual cards
HTTPS Proxy
(Static EU IP)
Brails API
api.onbrails.com/api/v2
On the Brails side, every request your systems make arrives from the same two EU addresses, whether it left a container, a cron worker, or a batch job. Both sit in the whitelist, so a proxy node failing over changes nothing the gate can see.
HTTPS_PROXY once in your environment and every API family Brails exposes, quotes, payouts, beneficiaries, customers, collections, and virtual cards, leaves through the same pair.Brails' guidance for microservices is to whitelist every server that talks to the API. Two fixed addresses satisfy that instruction for every pod, region, and scheduled job at once, and the list stops growing with your infrastructure.
The sandbox host sandboxapi.onbrails.com and the production host api.onbrails.com ask the same whitelist question. Keep the pair listed in both environments while you test, and going live after KYB changes the base URL and nothing else.
Payout platforms rarely settle on a single provider. Our Flutterwave static IP guide and Razorpay guide show the same two addresses clearing other whitelists, so the pair you confirm for Brails keeps paying dividends.
Teams whose Brails traffic has to arrive trusted, on every single call.
Brails moves money to bank accounts and mobile money wallets in 49+ countries, including EUR and SEPA corridors, US wires, and Chinese rails. A fixed European origin matches the destination map and keeps every corridor call trusted.
Payroll and settlement runs quote, initiate, and track dozens of transfers in a loop, often at hours nobody is watching. A blocked call at step two of three is a failed run, and the whitelist cannot tell time.
Issuing, funding, freezing, and unfreezing Brails' virtual Visa USD cards rides the same authenticated API. Card operations inherit the whitelisted pair automatically, with no second integration to maintain.
Graduating from sandbox to production brings live keys, real money, and a production whitelist that blocks unknown addresses. Landing it with the pair already listed means launch day changes keys, not infrastructure.
One environment variable routes every Bearer-authenticated Brails call out of your fixed EU address.
Set the variable wherever your payout code runs. Brails authenticates every request with a Bearer API key and rejects anything that is not HTTPS, and the proxy alters neither.
# .env, task definition, or Kubernetes secret, wherever env config lives
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
# any API v2 call, now egressing from your static EU IP
curl -s "https://api.onbrails.com/api/v2/customers" \
-H "Authorization: Bearer $BRAILS_API_KEY"
# sandbox twin while you build: sandboxapi.onbrails.com/api/v2/Plain requests is the documented pattern, and it picks up HTTPS_PROXY from the environment on its own, no extra wiring.
import os
import requests
# requests reads HTTPS_PROXY from the environment automatically
resp = requests.get(
"https://api.onbrails.com/api/v2/customers",
headers={"Authorization": f"Bearer {os.environ['BRAILS_API_KEY']}"},
)
resp.raise_for_status()
# payouts follow the documented flow: quote first for the rate,
# fee and expiry, then initiate with beneficiaryId OR an inline
# beneficiary object, then track until SUCCESS; amount is in
# minor units (1 USD = 100 cents) and sourceWalletCurrency
# defaults to USD; every hop leaves from the same fixed pairNode's built-in fetch ignores proxy environment variables, so hand it undici's ProxyAgent explicitly.
import { ProxyAgent } from 'undici';
const res = await fetch('https://api.onbrails.com/api/v2/customers', {
dispatcher: new ProxyAgent(process.env.HTTPS_PROXY),
headers: {
'Authorization': `Bearer ${process.env.BRAILS_API_KEY}`,
},
});
// sandbox and production hosts work identically through the
// proxy; generate keys per environment via Generate a new keyBoth addresses, one 2FA pass, and the gate is settled for the life of the integration.
# whitelisting the pair, once:
# log in to the Brails Dashboard
# Settings -> Add IP Address
# enter BOTH fixed IPv4 addresses from your account
# confirm with your 2FA code
# the whitelisted IPs are visible in the dashboard afterwards
# the docs' warning is literal: with the whitelist on, requests
# from any other address are blocked, including your own. Keep
# both listed, and keep user devices off the list; it is for
# the API servers that send requests on behalf of usersOne 2FA pass, then the gate stays open
Every account gets its own pair of static EU IPv4 addresses. Confirm both through Add IP Address once, and the hard gate Brails built stops being your problem: redeploys, scale-outs, and region moves all present the same two addresses, and a failover between nodes never asks anyone for a code.
Which traffic is covered? Outbound, Bearer-authenticated REST against the Brails API: quotes, payouts, beneficiaries, customers, collections, and virtual cards, on api.onbrails.com in production and sandboxapi.onbrails.com while testing. Webhooks run the other direction: Brails POSTs events such as payout.transfer.success to your endpoint, and you verify the x-brails-signature header, an HMAC SHA512 of the payload signed with your secret key, so nothing inbound flows through the proxy and no source-IP rule is needed on your side.
📖 Complete Documentation: For detailed examples, error handling, and advanced configurations, see the Python guide, the Node.js guide, or all guides.
Brails runs its platform on Amazon Web Services, and its security page lists GDPR compliance reviews alongside periodic penetration testing, TLS 1.2 or higher in transit, and AES-256 encryption at rest. The origin of your side of the journey is the part you control.
Payout requests carry customer emails, beneficiary names, account details, and transfer descriptions, and much of that is personal data. Egress from EU data centres keeps the outbound leg of the journey inside Europe, which is the story a privacy team wants to hear.
Virtual Visa card rails put card program data in scope and PCI DSS framing around the chain. Your API key rides as a Bearer token inside TLS the proxy passes through untouched, and a gate that only admits two known addresses is exactly the kind of network control the standard rewards.
Both fixed IPs live in the whitelist, so the block rule never trips on your traffic, no matter how many services, jobs, or regions originate the calls.
2FA-confirm the pair once through Add IP Address. Deploys, autoscaling events, and infrastructure migrations stop involving the dashboard entirely.
The two addresses back each other up inside the list Brails already trusts, so a proxy node stepping out is invisible to the payout pipeline.
New pods, regions, and cron workers inherit the same pair automatically. The whitelist you configure at launch is still complete at a hundred times the traffic.
Brails warns that API keys grant unrestricted transaction access. Yours travel as Bearer tokens inside TLS the proxy relays as ciphertext, and stay in env vars, never in code.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
A single environment variable points every Brails API call at two fixed EU addresses the platform already trusts, from the first sandbox quote to the ten-thousandth production payout.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
Yes. The dashboard exposes it under Settings: click Add IP Address, enter the server address, and confirm with a 2FA code. The documentation describes a strict model in which any request from an unapproved IP is blocked, including your own if it is not on the list, and it recommends listing API servers only, never user devices like phones or laptops.
Open the dashboard, head to Settings, and use Add IP Address for each of the two fixed IPv4 addresses on your account, confirming with your 2FA code. Do it once in sandbox and once in production if you run both environments. Because both addresses are whitelisted, traffic continues through the survivor during a proxy failover with no dashboard action needed.
No. Webhooks are inbound: Brails POSTs events like payout.transfer.success to your endpoint, and you authenticate them by verifying the x-brails-signature header, an HMAC SHA512 of the body signed with your secret key. The proxy and the IP whitelist concern your outbound API traffic only, so your webhook receiver needs no proxy configuration at all.
Tell us what your payout stack runs on, and we will map exactly where the pair plugs in.
Contact Our Founders →