01 / Understand the basics
Credentials identify you.
A whitelist identifies the source.
An IP whitelist is a list of IP addresses permitted to access the Brick API. Brick checks the source IP of each incoming request. Registered IPs can proceed to authentication and other validation; requests from IPs outside the list are rejected.
For financial activities such as sending funds and accepting payments, this restriction helps reduce access from unknown servers and makes it easier to review permitted infrastructure.
Keep your API credentials protected and maintain other security controls for your integration.
02 / Before you start
The right IPs. The right configuration.
Use the static public IP address that Brick actually sees when your server sends a request.
Static public IPs
Dynamic IPs and private or local addresses cannot be used as the public source IP.
Up to 10 addresses
The limit applies to each whitelist configuration.
Separate environments
Your Sandbox list does not automatically apply to Production, or vice versa.
Separate sub-accounts
Make sure the IP list is saved for the correct sub-account.
Using a NAT Gateway or proxy?
Register the
public outbound IP (egress IP) visible to Brick, rather than
the private IP of the server behind it.
03 / Configuration
Enable it in the Brick Dashboard.
Prepare your static public IP list, then follow these steps.
-
Open your integration settings
Log in to the Brick Dashboard, select Configuration → Callback URL, then find IP Whitelist / Incoming Request Validation.
-
Add your static public IPs
Check the selected environment and sub-account. Add all required outbound IPs, up to 10 IP addresses.
-
Save, enable, and test
Save the configuration and make sure IP Whitelist is enabled. Test API access from a registered IP to confirm that requests can be processed.
04 / Troubleshooting
Request rejected? Check the source IP.
An unregistered IP receives HTTP 401 with the error code
ip_not_whitelisted. Match your server’s public outbound IP
against the whitelist for the correct environment and sub-account.
{
"status": 401,
"error": {
"code": "ip_not_whitelisted",
"message": "Request is not coming from whitelisted IP",
"reason": "Source IP is not whitelisted in Brick servers"
},
"data": null
}Example response from the official Brick documentation.
05 / Final checks
Before your first transaction.
Use this checklist to review your configuration.
If an outbound IP changes, update the whitelist first to keep your integration running. This checklist is a page-level reminder, not an account verification.
06 / Common questions
Frequently asked questions.
Is IP Whitelist mandatory?
Yes. Current Brick documentation requires every client to configure an IP whitelist before using the Brick API in Production.
Can I use a dynamic or local IP?
No. Use a static public IP as the request source. For servers behind a NAT or proxy, register the public outbound IP visible to Brick.
Do Sandbox settings apply to Production?
No. Sandbox and Production are managed separately. Each sub-account also has its own configuration.
Does whitelisting replace API authentication?
No. Requests from whitelisted IPs must still pass authentication and other API validation.
