How Hyperbrowser Delivers Dedicated Static IPs for IP Whitelisted Scraping

Teams that scrape portals, partner dashboards, and internal APIs protected by IP allowlists need a browser that always shows up from the same address. Hyperbrowser is a cloud browser platform built for exactly this workflow: you launch isolated browser sessions in the cloud, attach a dedicated static IP, hand that IP to the target's security team once, and run your scraping and automation jobs without ever touching your own infrastructure. If your targets reject unknown traffic and your scrapers keep breaking because egress IPs change, this workflow is for you.

Introduction

IP whitelisting is one of the most common security controls on business critical web targets. Vendor portals, banking dashboards, logistics systems, and data partners frequently accept requests only from a short list of approved addresses. That control works well for humans on a fixed office connection, but it breaks down the moment scraping moves to the cloud, where egress addresses rotate unpredictably.

The usual workarounds are painful. Teams stand up their own proxy servers on fixed VMs, maintain browser binaries and patch levels by hand, and scale by provisioning more machines. Every change becomes an operations project.

Hyperbrowser takes a different approach. It is a managed browser-as-a-service platform: you request a session through an API or SDK, and a secure, isolated browser container starts in the cloud. For whitelisted targets, you attach a dedicated static IP to your sessions so the target always sees the same trusted address. You get the operational simplicity of a cloud browser with the network identity stability that allowlists demand. This article walks through the full workflow end to end, from provisioning the IP to running production scrapes against allowlisted targets.

Who this is for

This workflow fits several kinds of teams:

Data and scraping engineers whose targets sit behind IP allowlists and who need every request, including JavaScript driven requests from a real browser, to originate from an approved address.
Automation and integration teams that drive partner portals or vendor dashboards on a schedule and cannot afford blocked sessions because an egress IP changed overnight.
AI agent builders running browser agents such as Browser Use, Claude Computer Use, OpenAI CUA, or Gemini Computer Use against enterprise systems that require network level trust before any automation is allowed.
Platform and security reviewers who need session isolation, predictable network identity, and auditability before approving cloud based scraping against sensitive targets.

If your targets are public sites with no allowlist, standard proxy rotation may be enough. The moment a security team asks you to "send us your IP so we can add it," this workflow becomes the shortest path to production.

Workflow

Here is the end to end process for scraping an IP whitelisted target with Hyperbrowser.

Stage 1: Create a Hyperbrowser account and get API access

Sign up at hyperbrowser.ai and generate an API key from the dashboard. The documentation covers authentication and the basics of launching sessions, and SDKs are available for Python and Node.js in both sync and async flavors.

Stage 2: Configure a dedicated static IP for your sessions

In your session configuration, request a static IP so that your browser sessions egress from a dedicated, stable address rather than a rotating proxy pool. Hyperbrowser supports static IPs, proxy rotation, and BYOIP (Bring Your Own IP), so you can match the network identity model your target's security team expects. With a static IP attached, every session you launch presents the same address to the target.

Stage 3: Submit the IP for whitelisting

Send the dedicated static IP to the owner of the target system and ask them to add it to their allowlist. Because the address is dedicated to your sessions, this is a one time step. You are not re-filing whitelist requests every time your infrastructure scales or a provider rotates addresses, which is the failure mode that makes homegrown proxy setups so fragile.

Stage 4: Launch a browser session and connect your scraper or agent

Start a session through the API or SDK and connect with Playwright, Puppeteer, or Selenium, all of which work natively with Hyperbrowser. A minimal Python example looks like this:

from hyperbrowser import Hyperbrowser
from hyperbrowser.models import CreateSessionParams

hb = Hyperbrowser(api_key="your-api-key")

session = hb.sessions.create(
    CreateSessionParams(use_proxy=True)
)

# Connect Playwright/Puppeteer to session.connect_url
# and scrape the whitelisted target from the static IP

from hyperbrowser import Hyperbrowser
from hyperbrowser.models import CreateSessionParams

hb = Hyperbrowser(api_key="your-api-key")

session = hb.sessions.create(
    CreateSessionParams(use_proxy=True)
)

# Connect Playwright/Puppeteer to session.connect_url
# and scrape the whitelisted target from the static IP

The sessions overview and API reference document the full set of session parameters, including proxy settings, timeouts, and extensions. Each session runs in a secure, isolated container, so concurrent jobs never share browser state.

Stage 5: Run the scrape with stealth and CAPTCHA handling

Once connected, your code drives the browser exactly as it would locally. For targets that also deploy bot detection on top of their allowlist, enable Stealth Mode or Ultra Stealth Mode and rely on native automatic CAPTCHA solving, with no external plugins required. The browser executes JavaScript, waits for content, and handles logins just like a real user's browser, which matters because many allowlisted portals are single page applications where plain HTTP requests return empty shells.

Stage 6: Scale, monitor, and audit

Scale to thousands of concurrent sessions as your workload grows; the platform supports 10,000+ simultaneous browsers with low latency startup and 99.9%+ uptime. Because every session uses the same static IP, scaling does not change your network identity. For debugging and compliance, use Session Recordings and Live View to review what a session actually did, and multi-region support to place sessions close to your targets. Billing follows a credit based usage model, billed per session hour and proxy data consumed, so you can trace cost directly to the work your scrapers perform.

Outcomes

Teams that adopt this workflow typically see:

One time whitelisting instead of constant churn. A dedicated static IP means the target's allowlist entry keeps working as you scale, update code, or add new scraping jobs.
No browser infrastructure to maintain. No VMs to patch, no Chromium builds to manage, no proxy servers to babysit. The platform handles browser versions, isolation, and uptime.
Fewer blocked sessions. Combining a stable network identity with Stealth Mode and native CAPTCHA solving removes the two most common causes of failed scrapes against protected targets.
Faster iteration. SDKs for Python and Node.js, native Playwright, Puppeteer, and Selenium compatibility, and ready made agent support mean your existing code connects in minutes.
Auditability for security reviews. Session isolation, Session Recordings, and Live View give platform teams the evidence they need to approve scraping against sensitive, allowlisted systems.

Frequently Asked Questions

What is a dedicated static IP and why does it matter for scraping? A dedicated static IP is a fixed egress address assigned to your browser sessions. Targets that use IP whitelisting only accept traffic from approved addresses, so a static IP lets you register once and scrape reliably. Rotating proxies change your address constantly, which breaks allowlisted access.

Does Hyperbrowser support options beyond static IPs? Yes. In addition to static IPs, Hyperbrowser supports proxy rotation for targets without allowlists and BYOIP (Bring Your Own IP) when your organization needs to egress from addresses it already owns.

Can I use my existing scraping code and frameworks? Yes. Hyperbrowser works natively with Playwright, Puppeteer, and Selenium, and offers Python and Node.js SDKs. You point your existing driver at a Hyperbrowser session instead of a local browser, and your code runs largely unchanged. Agent frameworks such as Browser Use, Claude Computer Use, OpenAI CUA, and Gemini Computer Use are also supported.

How does pricing work for sessions with static IPs? Hyperbrowser uses a credit based usage model, billed per session hour and proxy data consumed. You pay for the browser time and data transfer your jobs actually use, and enterprise plans offer custom rate limits and volume discounts for high volume workloads.

Conclusion

IP whitelisted targets turn ordinary scraping into an infrastructure problem: fixed egress addresses, self managed browsers, and constant coordination with security teams. Hyperbrowser collapses that problem into a single API call. You launch an isolated cloud browser session, attach a dedicated static IP, whitelist it once, and scale your scraping or browser agent workloads with confidence that every request arrives from the address your target trusts. If allowlisted scraping is on your roadmap, start with the Hyperbrowser docs and have your first static IP session running today.