FBR IP Whitelisting for Digital Invoicing

IP whitelisting limits API access to approved network origins alongside token authentication. FBR’s Digital Invoicing User Manual asks for hosting-company name, country and public IP information before sandbox testing.

For hosted software, ask the provider for the stable egress IP used specifically for FBR calls. A private 10.x address, load-balancer inbound address or developer laptop address is not normally what FBR observes.

Version 1.5 of the user manual describes one to three IPs in the direct entry flow and a file option for multiple entries. Use the current portal format and integrator instructions because forms and limits can evolve.

Serverless and autoscaling platforms may rotate outbound addresses unless configured for stable egress. Confirm sandbox and production paths before launch, and treat an infrastructure migration as a compliance-impacting change.

For forbidden responses, capture time, endpoint and observed outbound IP without logging the token. Compare them to the approved record, confirm the request is in the right environment, and wait for approval after updates before retrying.

Document the outbound route for each environment. A developer may test sandbox from an approved office address while production leaves through a cloud gateway. One successful test does not prove the live address is approved. Confirm both paths through the selected integrator’s current process.

Store environment-specific endpoints, tokens and network settings separately. Use clear configuration names and deployment checks that prevent a sandbox credential from reaching production. Never print the secret while diagnosing which configuration was loaded.

Before a hosting migration, ask whether the public egress will change, submit any required whitelist update, wait for confirmation, and schedule a controlled validation. Keep the old route available only as long as security and the migration plan require; remove stale access through the approved process.

Monitor the first submissions after every network change. An HTTP authorization failure should enter a visible queue with the order reference and literal response. It should not trigger rapid automatic retries, which add noise without fixing an unapproved address.

Whitelisting does not replace secret management, least-privilege access, encryption, audit logs or token rotation. Anyone using an approved network path may still need a valid token, and exposed credentials remain an incident. Limit who can view or replace them and document emergency rotation.