You’ve wired BoldSign webhooks into your backend. Documents get signed, and your API quietly updates records, moves deals, creates users, or even releases funds.
But there’s a problem: your webhook endpoint is public. Anyone who discovers that URL can try to hit it. A spoofed callback could update account states, trigger automations, or fire off payouts without ever going through BoldSign.
A simple, effective fix is to lock down your BoldSign API webhook endpoint so that only BoldSign’s IP addresses can reach it. That’s what IP whitelisting gives you: your firewall or server only accepts traffic from known BoldSign IPs and drops everything else at the edge.
This article is for developers integrating with the BoldSign API. We’ll cover:
- What IP whitelisting is, in practical, network terms
- The exact BoldSign IPs you should allow, by region
- A step-by-step setup flow you can follow on any stack
- A Node.js example you can adapt to your codebase
- Best practices and limitations so this doesn’t come back to bite you later
What Is IP Whitelisting for BoldSign Webhooks?
IP whitelisting is a simple rule:
Only accept traffic from these IP addresses. Drop everything else.
In the context of BoldSign API webhooks:
- Your firewall, reverse proxy, or application server is configured to accept incoming requests only from BoldSign-owned IPs.
- Any request from a non-whitelisted IP is rejected before your application logic runs.
Because this happens at the network level, you get:
- A strong outer layer of protection around your webhook endpoint
- Protection even if someone leaks a URL, token, or credential
- Less noise from bots, scanners, and random internet traffic hitting your webhook route
Think of IP whitelisting as a network-level gatekeeper sitting in front of your BoldSign webhook handler.
Why Securing Webhooks Matters for API Integrations
When you’re using the BoldSign API, webhooks often trigger important backend flows:
- Creating or updating user accounts
- Moving contracts through states
- Updating CRM or billing systems
- Triggering payouts or financial actions
- Kicking off internal automation workflows
If your webhook endpoint is not secured, you risk:
- Spoofed callbacks pretending to be BoldSign
- Brute-force hits on your webhook URL
- Abuse of internal automation (fake contract completions, rogue account creation, etc.)
IP whitelisting helps by:
- Blocking unsolicited traffic at the edge
- Giving security and DevOps teams clear, deterministic rules to enforce
- Working particularly well with services like BoldSign, which expose fixed IP addresses by region
You still want HTTPS, HMAC, and validation. But IP whitelisting is a low-friction, high-impact first step.
How BoldSign Supports Secure API Webhooks
BoldSign makes network-level hardening straightforward by:
- Providing fixed IP addresses per region (US, Europe, Canada, Australia)
- Sending all webhook requests from those IPs
- Keeping those IPs stable so you can safely encode them in firewall rules, WAF rules, or infra-as-code
For API-first teams, this means you can:
- Lock down your
/webhooks/boldsignroute to known IPs - Keep the rest of your API behind your existing auth stack
- Document and automate the rules in Terraform, CloudFormation, ARM templates, etc.
BoldSign Webhook IP Addresses by Region
Whitelist the IP address that matches the region where your BoldSign tenant is hosted.
| Region | IP Address to Whitelist |
|---|---|
| US | 35.243.182.124 |
| Europe | 34.141.138.53 |
| Canada | 34.130.12.142 |
| Australia | 34.40.190.114 |
Note: Use the region where your BoldSign account is hosted, not necessarily where your own servers run. Check the BoldSign documentation for the official IP list.
Step-by-Step: How to Set Up IP Whitelisting for BoldSign API Webhooks
What You’ll Need
- A BoldSign account with webhooks configured or ready to configure
- A backend/API endpoint to receive webhooks, for example:
/webhooks/boldsign - Access to your firewall, WAF, load balancer, API gateway, or reverse proxy
- Knowledge of your BoldSign region (US, Europe, Canada, or Australia)
Steps
- Identify Your BoldSign Region
- Find out where your BoldSign tenant is hosted (US, Europe, Canada, or Australia).
- From the IP table above, note the IP address that corresponds to that region.
- Configure Firewall or Gateway Rules
- In your firewall, security group, WAF, or API gateway, add rules so that:
- Requests to your BoldSign webhook endpoint are allowed only from the region-specific BoldSign IP.
- Requests from any other IP to that endpoint are blocked or dropped.
- This could be done in:
- Cloud security groups (AWS, Azure, GCP)
- NGINX/Apache allow/deny rules
- Cloudflare or similar providers
- Managed API Gateways with IP-based access control
- In your firewall, security group, WAF, or API gateway, add rules so that:
- Enforce HTTPS for the Webhook URL
- Ensure your BoldSign webhook URL uses HTTPS only.
- Terminate TLS at your load balancer or reverse proxy.
- Redirect HTTP to HTTPS if you still expose port 80.
- This keeps signer and document data encrypted in transit.
- Enable Logging and Monitoring
- Enable and centralize logs for:
- Access logs: which IPs hit the endpoint and when
- Error logs: any blocked or failed attempts
- Application logs: what your webhook handler did with each event
- Route logs to your usual stack (CloudWatch, Datadog, ELK, etc.) so you can easily debug and audit.
- Enable and centralize logs for:
- Test the Webhook Flow End-to-End
- Trigger a webhook from BoldSign (for example, complete a signing request).
- Confirm that:
- Your backend successfully receives and processes the event.
- The source IP in your logs matches the whitelisted BoldSign IP.
- A request from a non-whitelisted IP to the same endpoint is rejected with the expected status (for example, 403).
Example: IP Whitelisting Check in Node.js
Your primary IP filtering should happen at the edge (firewall, gateway, or WAF). Still, adding a simple IP check in your application can act as a useful second layer.
Here’s a minimal Express example you can adapt:
const allowedIps = new Set(["35.243.182.124", "34.141.138.53"]);
app.post("/webhook", (req, res) => {
const ip = req.headers["x-forwarded-for"]?.split(",")[0] || req.ip;
// Normalize IPv6-mapped IPv4 (e.g., ::ffff:35.243.182.124)
const normalizedIp = ip.replace("::ffff:", "");
if (!allowedIps.has(normalizedIp)) {
return res.status(403).send("Forbidden");
}
// Valid request; proceed
// Process payload here
res.sendStatus(200);
});
Note: In many environments, the canonical place to enforce IP checks is on the load balancer or gateway, where headers such as x-forwarded-for are controlled. Do not blindly trust user-controlled headers at the edge of the internet.
Other Security Layers to Combine with IP Whitelisting
IP whitelisting is a strong outer fence, but you still want additional checks.
Recommended layers:
- HMAC Signatures
- Use a shared secret and HMAC to sign the payload.
- Recompute and compare on your side. If they don’t match, reject the request.
- HTTPS Everywhere
- Use HTTPS for all webhook communication to encrypt data and prevent man-in-the-middle attacks.
- Authentication Tokens
- Require a secret token in a header or query parameter that only BoldSign and your backend know.
- Reject requests missing or using the wrong token.
- Strict Input Validation
- Validate event types, required fields, and payload structure.
- Do not apply changes based purely on “shape matches”; verify IDs and states.
- Logging and Monitoring
- Track what events you receive and how frequently.
- Set alerts for unusual patterns, spikes, or error rates.
Simple model to keep in mind:
- IP whitelist: who can talk to you
- HMAC and tokens: who they claim to be
- Validation: what they are allowed to do
Limitations of IP Whitelisting (and How to Mitigate Them)
IP whitelisting is very useful, but it has trade-offs you should be aware of.
Key limitations:
- No Payload Integrity by Itself
- IP whitelisting confirms the source IP, not the content.
- Mitigation: enable HMAC signatures or another signing mechanism to detect tampered payloads.
- Operational Overhead Across Environments
- Dev, staging, and production all need correct rules.
- Mitigation: keep whitelists in environment-specific config instead of sprinkling IPs across multiple places.
- False Sense of Security
- It is easy to stop after whitelisting and forget HTTPS, auth, or validation.
- Mitigation: treat IP whitelisting as one control in a larger, layered security design.
- No Protection Against Internal Threats
- IP whitelisting mainly filters external traffic.
- Mitigation: enforce proper access control, least privilege, and monitoring inside your network.
Logs to Monitor for BoldSign Webhooks
For a production-ready integration, you should monitor:
- Access Logs
- Confirm that incoming webhook requests come from the BoldSign IPs you expect.
- Error Logs
- Catch blocked or failed attempts, which might indicate misconfigurations or probing.
- Application Logs
- Track how each BoldSign event is processed inside your code.
- Security Logs
- Alert on repeated unauthorized attempts, unusual frequency, or abnormal patterns.
When something breaks or behaves oddly in your webhook flow, logs usually give you the fastest root cause.
Here are some concrete scenarios where IP whitelisting adds real value
In all these cases, a compromised or noisy webhook endpoint can cause operational and security headaches. IP whitelisting keeps the signal clean.
- HR Onboarding
- A new hire signs their offer letter in BoldSign.
- The webhook hits your backend API and automatically creates accounts, assigns roles, and provisions tools.
- IP whitelisting ensures that only genuine BoldSign events can trigger this provisioning.
- Loan Disbursement
- A customer signs a loan agreement.
- Your systems release funds only after receiving a webhook from a trusted BoldSign IP that confirms the signed document.
- Healthcare Consent
- A patient signs a consent form.
- The webhook updates the EHR securely and consistently, helping you stay compliant with healthcare regulations.
- Government Licensing
- A citizen signs a permit or license application.
- The licensing system advances the application only after a verified BoldSign callback.
- SaaS and Legal Tech Automation
- CRM stages move when contracts are signed.
- Subscription states update when agreements are completed.
- Legal platforms change contract state or trigger reminders based on reliable BoldSign events.
Best Practices for Securing BoldSign API Webhooks
You can treat this as a simple checklist:
- Whitelist the BoldSign IP addresses for your region
- Enforce HTTPS for all webhook URLs.
- Use HMAC verification to protect payload integrity.
- Use authentication tokens where appropriate.
- Validate payloads and event types before applying changes.
- Centralize logs and set alerts for anomalies.
- Store IP whitelists and secrets in configuration or environment variables, not hard-coded.
- Test webhook changes in a staging environment before production.
- Rotate secrets (HMAC keys, tokens) periodically.
Conclusion: A Simple Win for BoldSign API Security
If you rely on the BoldSign API and webhooks to drive critical backend flows, IP whitelisting is one of the simplest high-impact security upgrades you can add:
- Only trusted BoldSign IPs can hit your webhook endpoint.
- Random internet traffic and spoof attempts are dropped at the edge.
- Your automation stays fast, predictable, and much harder to abuse.
To get started safely:
- Use a BoldSign trial and wire it to a dev or staging endpoint.
- Configure IP whitelisting and HMAC there first.
- Once you are confident, roll the same pattern into production.
If you need help designing this around your specific stack, you can always schedule a demo or reach out to the BoldSign team through the support portal.
Related blogs
- REST API vs SDK: Which is Best for eSignature Integration
- Explore BoldSign eSignature APIs in Postman: A Step by Step guide
- Exploring the API Trenches: Overcoming Challenges in API Integration and Development
Note: This blog was originally published at boldsign.com
Top comments (0)