Case Studies

Built for operators running
real proxy businesses

See how proxy companies use ProxyRequest to build product layers, conceal upstream providers, manage sub-users, and scale infrastructure — without rebuilding everything internally.

Not marketing stories.
Real infrastructure scenarios.

Every proxy business runs a different stack. Some blend multiple residential providers. Some operate modem pools. Some resell ISP traffic. Some migrate away from fragile internal tooling.

These case studies show how ProxyRequest fits into those setups — the problem, the existing stack, the architecture change, and the operational outcome.

01
Residential Reseller
Stopping supplier leakage in a multi-upstream residential operation
A 3-person team reselling Brightdata and Oxylabs traffic was losing clients to direct bypass. No per-user accounting, no upstream concealment.
3–15 TB/mo 2–5 people Multi-upstream
Read case study
02
Infrastructure Migration
Replacing fragile internal Python scripts with a production billing backend
A solo operator running DIY billing scripts and manual credential management hit a scaling wall at 200 sub-users with no per-user logs.
5–20 TB/mo 1–2 people Migration
Read case study
03
ISP + Residential Hybrid
Running differentiated ISP and residential products from a single backend
An operator selling both ISP and residential packages from separate setups needed user isolation, different routing logic, and a unified billing view.
10–40 TB/mo 3–8 people Hybrid products
Read case study
04
Anti-Detect Platform
Embedding a white-label proxy layer inside an anti-detect browser SaaS
A browser automation SaaS needed embedded proxy provisioning with per-session sticky IPs, UDP support, and API-driven credential management at scale.
API-first High concurrency Embedded layer
Read case study
05
Modem Pool Operator
Blending an own modem pool with residential upstreams and adding failover
An operator with 400+ modems had no routing layer between hardware and clients — no geo selection, no failover, no usage tracking per customer.
Own hardware Failover routing Custom mixing
Read case study
06
Scraping SaaS
Building a scraping-as-a-service product on top of ProxyRequest infrastructure
A data collection platform needed a proxy backend with geo coverage, quota enforcement per client, and a usage API their own product could query.
Coming soon
Case study in progress
Residential Proxy Reseller
How a residential proxy reseller stopped exposing upstream providers to clients
A small team combining Brightdata and Oxylabs traffic needed a branded product layer — without letting clients identify the underlying providers and negotiate direct.
Industry
Proxy Reseller
Team Size
2–5 people
Traffic Volume
3–15 TB / month
Migration Type
Partial replacement
Use Case
Residential + ISP resale
Key Requirement
Upstream concealment
Main Risk
Client bypass
Deployment
Cloud-hosted
The challenge
Before ProxyRequest
Architecture setup
Before / after
Outcomes
The challenge
The operator was purchasing residential bandwidth from Brightdata and Oxylabs and reselling it to ~80 clients. Traffic flowed through credentials that exposed the underlying provider endpoints directly — visible in connection errors, HTTP headers, and proxy configuration strings.
Within three months, two enterprise clients identified the upstream providers and started negotiating direct contracts, cutting the operator out entirely. The business model depended on supplier relationships staying invisible. They had no mechanism to enforce that.
On the billing side, tracking happened through provider dashboards and manual spreadsheets. When usage periods rolled over, reconciling what each client actually consumed took hours. Disputes were impossible to resolve with data — only with guesswork.
The team had also reached the limit of what manual credential management could handle. Adding a new client meant logging into two provider portals, creating credentials in both, combining them manually, and sending them over chat.
What they were running before
Infrastructure before ProxyRequest
Brightdata SOCKS5 credentials shared directly with clients
Oxylabs credentials distributed separately per-user
No routing abstraction — provider endpoints exposed verbatim
Billing via monthly manual export from provider dashboards
No per-user usage logs — aggregate only
Manual credential creation per client per provider
No unified dashboard or client portal
The setup was functional at 10 clients. At 80, every billing cycle was a reconciliation effort. Every new client onboarding was a manual process across two systems. And there was no answer to the supplier leakage problem at all.
Architecture after ProxyRequest
Provider Layer
Brightdata Residential
Oxylabs Residential
Routing Engine
Brightdata45%
Oxylabs55%
Provider names sanitised
Metadata scrubbed
Product Structure
Residential Lite
Residential Pro
80 sub-users isolated
Bandwidth caps enforced
API provisioning active
All 80 clients connect to a single endpoint under the operator's domain. Neither provider name appears anywhere in the connection path, error output, or credential format. Clients have no way to identify what's routing their traffic.
Before / After
BeforeAfter
Provider endpoints exposed in credentialsSingle branded endpoint, no provider traces
Clients identifying and bypassing suppliersZero bypass attempts since migration
Manual credential creation per clientAPI provisioning — seconds per user
Aggregate billing from provider dashboardsPer-user real-time usage tracking
Billing disputes with no supporting dataExportable per-session logs
No unified client viewWhite-label dashboard per sub-user
Outcomes
Upstream providers fully concealed. No metadata, error messages, or connection fingerprints reveal provider identity. Client bypass attempts stopped.
Per-user billing records. Usage is tracked per-session. Every billing dispute can be answered with exportable data rather than guesswork.
Provisioning reduced from hours to minutes. New clients are created via one API call. Credential generation, product assignment, and limit configuration happen in a single request.
Provider flexibility without client disruption. Routing weights adjusted multiple times — once after Oxylabs quality dropped in a region. Clients noticed nothing.
Operational overhead dropped sharply. Two providers, one control plane. No more cross-referencing multiple dashboards for billing or monitoring.
We stopped acting like a reseller and started operating like a real proxy platform. The first month after migration we didn't lose a single client to direct bypass.
Running a similar setup?
See how ProxyRequest fits your upstream configuration.
Infrastructure Migration
Replacing fragile internal billing scripts with a production-grade proxy backend
A solo operator running DIY Python billing scripts and manual credential management hit a wall at 200 sub-users — no per-user logs, no automated caps, no failsafe.
Operator Type
Solo / 2-person
Sub-users
200+ active
Traffic Volume
5–20 TB / month
Migration Type
Full replacement
Previous Stack
Python scripts + cron
Key Problem
No usage accounting
Main Risk
Unlimited overages
Deployment
VPS + cloud mix
The challenge
Before ProxyRequest
Architecture setup
Before / after
Outcomes
The challenge
The operator had grown a 200+ client business on top of a stack held together with Python cron jobs, manually-updated credential lists, and a shared SOCKS5 endpoint. For the first 50 clients it worked. By 200 it was breaking regularly.
The core problem: no per-user accounting. The operator knew total monthly usage from the upstream provider. They had no idea what individual clients used. When a client burned through their "allocation" and kept going, there was nothing to stop them. Overages landed on the operator's provider bill.
Credential management was entirely manual. Adding a new client meant editing a config file, restarting a service, and sending details over Telegram. Removing a churned client sometimes happened days late. There was no dashboard, no self-service, no usage visibility for clients at all.
The internal billing scripts had accumulated over 18 months. They worked — until they didn't. A cron failure once resulted in 40 active clients not having their limits reset at period rollover, causing a disputed billing month that took two weeks to resolve.
What they were running before
Stack before migration
Single upstream provider, SOCKS5 forwarding via Python script
Credential rotation via cron job — no atomic operation, failure-prone
Usage tracked via monthly aggregate from provider portal only
No per-user cap enforcement — soft limits communicated via message
Billing disputes: no evidence, only provider total
No client dashboard — credentials delivered via Telegram/email
Architecture after ProxyRequest
Provider Layer
Existing upstream (SOCKS5)
Imported via 1-click setup
+1 backup provider added
Routing Engine
Primary upstream80%
Backup upstream20%
Hard caps enforced
Real-time accounting
Billing Layer
Card payments enabled
Crypto payments enabled
Auto top-up via webhook
200 sub-users migrated
Migration from the old stack took less than a week. Existing clients were recreated as sub-users with their remaining balances. Their credentials changed (new proxy host), but username patterns were preserved where possible to minimise disruption.
Before / After
BeforeAfter
Manual credential management via config filesAPI and dashboard provisioning
No per-user usage trackingReal-time per-user accounting
No limit enforcement — soft limits onlyHard caps cut access immediately at cap
Billing disputes unresolvablePer-session logs, exportable CSV
Cron failures causing billing incidentsAccounting runs at infrastructure level
Clients receive credentials over chatWhite-label self-service dashboard
Single upstream, no fallbackTwo upstreams, automatic routing
Outcomes
All overages eliminated. Hard caps enforced at the routing layer. When a user hits their limit, access stops immediately — no manual intervention needed.
Billing disputes resolved with data. Per-session export answered all disputed months within minutes of migration going live.
Client onboarding time reduced from hours to under 2 minutes. New sub-user via API or panel — product assigned, credentials generated, limit set in one operation.
Payments automated. Clients top up via card or crypto inside the white-label dashboard. Balance updates trigger bandwidth allocation automatically — no manual top-up processing.
Python scripts and cron jobs fully decommissioned. Eighteen months of accumulated internal tooling replaced with a production platform that requires no maintenance overhead.
The migration took four days. The first two weeks after, I had zero billing questions, zero overage incidents, and no late-night credential resets. It paid for itself immediately.
Running a DIY stack that's reaching its limits?
We'll help you plan the migration without disrupting existing clients.
ISP + Residential Hybrid
Running differentiated ISP and residential products from a single unified backend
An operator selling ISP and residential packages from completely separate setups had no cross-product visibility, fragmented billing, and users who had to manage two separate credential sets.
Products Sold
ISP + Residential
Team Size
3–8 people
Traffic Volume
10–40 TB / month
Active Sub-users
500+
Key Problem
Fragmented backends
Requirement
Product isolation
Use Cases
Scraping + automation
Deployment
Multi-region cloud
The challenge
Before ProxyRequest
Architecture setup
Before / after
Outcomes
The challenge
The operator had grown by adding products incrementally — first residential, then ISP — using completely separate infrastructure for each. Two proxy servers, two billing systems, two credential sets per client, two Telegram bots for support. Running two separate businesses from inside one team.
Clients who bought both products had to manage separate login panels, separate proxy addresses, and separate billing. This created support overhead and churn from clients who found the experience fragmented.
There was no cross-product usage visibility. The team couldn't see which clients were using both products heavily and segment them for upsell. Monitoring required checking two separate dashboards. Incidents on one product were invisible from the other.
Routing logic was different for each product — ISP used geographic round-robin, residential used a single provider's internal geo. When they tried to add a second residential provider, doing it without rebuilding the routing layer wasn't possible.
What they were running before
Residential product stack
Single residential upstream, direct credential distribution
Billing via provider export, manual CSV merge per billing cycle
Separate client portal (hosted panel, aging codebase)
ISP product stack
ISP pool on separate VPS infrastructure
Manual IP allocation per client, no rotation
Separate billing tracking — spreadsheet per client
Separate monitoring — no cross-product visibility
Architecture after ProxyRequest
Provider Layer
Brightdata Residential
Oxylabs Residential
ISP Pool (own VPS)
NetNut ISP
Product Layer
Residential Lite
Residential Pro
ISP Standard
ISP Premium
Client Layer
One dashboard per client
Cross-product usage view
Unified billing / invoices
Single credential system
500+ sub-users
ISP and residential products now run on separate routing configurations within the same platform. A client buying both products sees one dashboard, one invoice, one billing balance. The team sees one admin panel with cross-product analytics.
Before / After
BeforeAfter
Two separate backends with no shared visibilitySingle control plane for all products
Clients managing two credential setsOne dashboard, unified access
Separate billing systems and exportsUnified invoicing and balance
No cross-product usage analyticsFull cross-product visibility in admin
Adding new provider required system rebuildNew providers added via import in minutes
Support split across two monitoring setupsOne dashboard, one Grafana, one alert channel
Outcomes
Both products consolidated under one backend. ISP and residential routing configured as separate products. Same platform, different routing logic, different upstream pools.
Client experience unified. Clients who buy both products log into one dashboard, manage one balance, see one invoice history. Support tickets about "which panel" dropped to zero.
Cross-product usage analytics enabled upsell visibility. Team can now see which clients are nearing residential cap and proactively offer ISP as a speed alternative. Not possible with separate systems.
Added second residential provider without client disruption. Connected Oxylabs alongside Brightdata. Adjusted weights. Clients noticed improved geo coverage and nothing else.
Operating multiple products on separate infrastructure?
We'll show you how consolidation works for your specific setup.
Anti-Detect Browser Platform
Embedding a proxy layer inside an anti-detect browser SaaS with API-driven provisioning
A browser automation product needed embedded proxy credential generation, per-session sticky IPs, UDP associate support, and per-client quota — all accessible via API, not a manual panel.
Integration Mode
API-first / Hybrid
Provisioning
Fully automated
Session Type
Sticky (per browser profile)
Key Protocol
SOCKS5 + UDP ASSOC
Key Requirement
No manual UI operation
Client Type
End users of the SaaS
Billing Model
Per-user GB quota
Concurrency
High — per browser tab
The challenge
Before ProxyRequest
Integration setup
Before / after
Outcomes
The challenge
The platform let users manage browser profiles for automation and anti-detect work. Each profile needed its own proxy — ideally a sticky residential IP that stayed consistent across sessions and was invisible to the target site.
The team had been purchasing residential proxy packages from a provider and manually distributing credentials to users via their own backend. When a user created a browser profile, a support team member assigned them a proxy. This didn't scale.
The platform also ran into protocol issues. Their provider's SOCKS5 endpoints didn't reliably support UDP ASSOCIATE — a requirement for certain browser fingerprinting modes that needed WebRTC traffic to pass through the proxy correctly.
They needed a programmatic way to: create a proxy credential per browser profile, pin it to a sticky IP, enforce a bandwidth quota, and get usage back via API — all without any manual intervention and without exposing their upstream provider to the browser session metadata.
What they were doing before
Previous proxy layer
Provider credentials purchased in bulk, manually distributed to users
No per-profile quota enforcement — shared pool with no isolation
SOCKS5 UDP ASSOCIATE unreliable — WebRTC tunneling broken for some users
Provider metadata leaking into session headers — detectable by some sites
No API for proxy provisioning — manual assignment via support team
No per-user usage tracking — couldn't tier pricing by consumption
Integration architecture
Their SaaS Platform
User registers for browser plan
SaaS calls ProxyRequest API
Creates sub-user + quota
Receives credential string
Injects into browser profile
ProxyRequest Layer
Residential upstream
SOCKS5 + UDP native
Sticky sessions enforced
Hard GB caps per profile
Metadata sanitised
Mapping Layer (their DB)
profile_id → pr_user_id
plan_id → pr_package_id
Usage queried per profile
Top-up on plan payment
The SaaS operates in hybrid mode — their users and billing live in their system. ProxyRequest handles routing, session management, accounting, and protocol delivery. A mapping table connects the two systems. No ProxyRequest UI is visible to end users.
Before / After
BeforeAfter
Manual proxy assignment by support teamFully automated via API at profile creation
Shared pool — no per-user isolationDedicated credential per browser profile
UDP ASSOCIATE unreliableNative SOCKS5 + UDP — WebRTC tunneling stable
Provider metadata in session headersMetadata fully sanitised — provider invisible
No per-user quota — no usage-based pricingPer-profile GB quota + usage API
No session persistence guaranteeSticky sessions with configurable TTL
Outcomes
Proxy provisioning fully automated. From user registration to active proxy credential: one API call, under 500ms. Support team involvement for proxy setup dropped to zero.
UDP ASSOCIATE stable across all browser profiles. WebRTC traffic now tunnels correctly. A class of support tickets about browser detection issues related to proxy protocol behaviour was eliminated.
Per-profile usage enabled consumption-based pricing. The SaaS launched a tiered plan where heavier users pay more based on actual GB consumed. Previously impossible without per-user accounting.
Provider completely invisible to browser sessions. No upstream metadata reaches the browser. Detection rate on sensitive targets decreased after migration — attributable to sanitised connection fingerprints.
Building a product that needs an embedded proxy layer?
We'll walk through the API integration architecture for your use case.
Modem Pool Operator
Adding routing, failover, and accounting to a 400-modem hardware operation
An operator running 400+ 4G modems had no layer between hardware and clients. No geo selection, no failover between modems, no per-user bandwidth accounting, and no client panel.
Infrastructure
400+ modems
Team Size
2–4 people
Traffic Volume
8–30 TB / month
Upstreams
Own hardware + residential
Key Problem
No routing layer
Requirement
Failover + geo selection
Use Case
Mobile IP traffic
Deployment
On-prem + cloud hybrid
The challenge
Before ProxyRequest
Architecture setup
Before / after
Outcomes
The challenge
The operator had built a hardware modem pool over two years — 400+ 4G devices across multiple locations, each with a SIM card and a SOCKS5 endpoint. This gave them genuine mobile residential IPs that were valuable to clients who needed organic-looking traffic.
The problem was everything above the hardware. Clients connected directly to individual modem IPs — no routing abstraction, no geo selection beyond what they negotiated manually. If a modem went offline, the client's session broke and someone had to notify them manually.
There was no usage accounting at the hardware level. The operator charged clients flat monthly rates regardless of consumption. High-bandwidth clients were subsidised by low-bandwidth ones with no visibility into the imbalance.
When they tried to blend in a residential upstream provider to cover geo gaps the hardware didn't have, there was no routing layer to merge the two. Clients used either hardware IPs or provider IPs — never transparently blended.
What they were running before
Hardware operation before ProxyRequest
400+ modems exposing raw SOCKS5 endpoints directly to clients
No routing layer — client connects to specific modem IP directly
No geo selection — clients request specific units by prior agreement
Modem failures require manual client notification
No per-client usage tracking — flat monthly pricing only
Residential upstream add-on sold separately, not blended
No client panel — credentials managed via spreadsheet
Architecture after ProxyRequest
Provider Layer
Own modem pool (400+)
Brightdata Residential
Modems imported via SOCKS5
Healthcheck on all units
Routing Logic
Own modems70%
Brightdata (geo fill)30%
Auto-failover on modem drop
Geo-fill via residential
Client Layer
One endpoint, mixed pool
GB-based billing enabled
Per-user usage tracking
Modem failure transparent
White-label panel live
The modem pool connects to ProxyRequest as a custom upstream via SOCKS5. Residential bandwidth fills geographic gaps when hardware coverage is thin. Clients connect to one endpoint and can specify geo or ASN — the system routes to whichever source can satisfy the request.
Before / After
BeforeAfter
Clients connect to raw modem IPs directlyUnified endpoint — hardware and residential blended
Modem failure breaks client session, manual alertAutomatic failover — transparent to clients
No geo selection — modem assignment by agreementGeo targeting via credential username
Flat monthly pricing regardless of usagePer-GB billing — high-usage clients priced correctly
No usage visibility per clientReal-time per-user accounting
No client panel — spreadsheet managementWhite-label dashboard for all clients
Outcomes
Modem failures now transparent to clients. When a modem goes offline, traffic routes to another unit or to the residential fallback. Clients no longer receive failure notifications — they experience continuity.
Geo coverage gaps filled without new hardware. Regions with thin modem coverage now route through residential upstream. Clients get the geo they need; the operator doesn't need to buy new SIMs for every gap.
Pricing switched to GB-based model. First billing cycle on the new model revealed that the top 10% of clients were consuming 60% of bandwidth under flat pricing. Revenue per TB increased materially after repricing.
Hardware and residential now sold as one product. Clients who previously needed to buy separate hardware and residential packages now purchase one blended product. Fewer SKUs, simpler sales conversations.
We'd been running the hardware for two years but selling it like it was 2018. ProxyRequest is what turned the modem pool into an actual product.
Running your own modem or hardware pool?
We'll help you add a routing and accounting layer without changing your hardware setup.
Talk to the team

These people understand
your exact business

Every demo is with the engineers who built the infrastructure. Bring your current stack, your upstream setup, your questions. We'll tell you exactly how ProxyRequest would fit — or if it wouldn't.

Book a Demo Call
30 minutes. Walk through your setup. Live product demo on your use case. No deck, no pitch script.
Talk to Engineering on Telegram
Direct line to the team. Technical questions answered by the people who wrote the code.