Configuration

Client IP Whitelist

Mandatory — Client IP Whitelist

Every client must configure an IP whitelist before using the Brick API in Production. Brick only accepts API requests from registered, permitted IP addresses. Make sure every server sending requests to Brick uses a static public IP.

Why Is an IP Whitelist Important?

An IP whitelist is a security mechanism that restricts API access to approved IP addresses. Requests from addresses outside the permitted list are rejected, even if they attempt to access a Brick API endpoint.

An IP whitelist is important because the Brick API processes financial activities, including receiving payments and sending funds. Restricting request sources helps:

Prevent unauthorized access: Only registered client infrastructure can send API requests.
Reduce the risk of API misuse: Requests from unknown networks or servers can be blocked before further processing.
Protect financial transactions: Add a security layer to reduce the risk of transaction requests from unauthorized sources.
Support security controls and audits: Make it easier to manage and review the IP addresses permitted to access the API.

An IP whitelist is an additional security layer, not a replacement for API authentication, credential protection, or other security controls.

IP Whitelist Requirements

Criterion	Requirement
Obligation	Mandatory for Brick API access in Production
IP type	Static public IP only
Maximum number	10 IP addresses per whitelist configuration
Dynamic IP	Not supported
Private/local IP	Cannot be used as the public source IP of API requests
Scope	Incoming requests to the Brick API, including Send Money and Receive Money
Environment	Sandbox and Production configurations are managed separately
Sub-account	Configuration is managed separately for each sub-account

Important: Register the public outbound IP your server actually uses when sending requests to Brick. If you use a NAT Gateway, proxy, or cloud infrastructure, use the static public egress IP visible to Brick, not the server's private IP.

How to Configure the IP Whitelist

Log in to the Brick Dashboard.
Open Configuration in the Brick Dashboard.
Select the Callback URL tab, where the IP whitelist settings are available.
Find IP Whitelist / Incoming Request Validation.
Add the static public IP addresses your servers use to access the Brick API, up to 10 IPs.
Save the configuration, then make sure the IP whitelist is enabled.
Test the API from a registered IP to confirm that requests can be processed.

Configuration page with the Callback URL tab selected

Client IP Whitelist settings in the Brick Dashboard

Note: Check the selected environment and sub-account before saving the configuration. The Sandbox IP list does not automatically apply to Production, or vice versa.

How Does IP Validation Work?

Each API request is checked against its source IP address.

Condition	Result
The source IP is registered in the whitelist	The request is accepted to proceed with authentication and other API validation.
The source IP is not registered	The request is rejected with HTTP `401` and error code `ip_not_whitelisted`.

Example Response for an Unregistered IP

Code
{
  "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
}

If you receive ip_not_whitelisted, verify your server's public outbound IP and make sure it is included in the whitelist for the correct environment and sub-account.

Before Using Production

Make sure every application or server accessing the Brick API uses a static public IP.
Register all required outbound IPs without exceeding the limit of 10 IPs.
Make sure the configuration is saved for Production and the correct sub-account.
Test API connectivity from a registered IP before running Production transactions.
If an outbound IP changes, update the whitelist first to avoid disrupting your integration.

For more information, see Configuration Overview.

Last modified on November 11, 2026