Overview
What is ProxyRequest?
ProxyRequest is the infrastructure layer between your upstream proxy providers and your end
clients. It handles routing, user management, bandwidth accounting, and white-label delivery —
so you can run a proxy business without building any of that yourself.
If you've ever tried reselling proxy access — from Brightdata, Oxylabs, or similar — you
quickly hit the same wall. How do you give each client separate credentials? How do you enforce usage
limits? How do you stop them figuring out who your supplier is? How do you resolve billing disputes
without per-user logs?
ProxyRequest solves all of that. It sits between your providers and your clients, keeps
your suppliers invisible, and gives you a full product layer with sub-user management, billing, and
real-time analytics.
One endpoint for all your providers
Clients connect to one address. Behind it, the system routes traffic across
your upstream providers according to weights you set.
Suppliers are completely concealed
Metadata, error messages, and response headers are sanitised. Clients
cannot identify who your upstream providers are.
Per-user usage tracked to the megabyte
Every client has their own usage log. Exportable, timestamped,
dispute-ready.
Hard limits that cut off access immediately
When a user hits their bandwidth cap, the proxy stops serving them. No
overages, no arguments.
Overview
Why not just resell directly?
Reselling proxy access directly from a provider is the obvious starting point. But as soon as you have
more than a handful of clients, it breaks down. Here's why operators move to a product layer.
Your clients can see your supplier
Direct resale exposes the upstream provider in connection metadata and
error messages. Once a client knows you're just wrapping Brightdata, they negotiate direct —
and you lose the account. Provider concealment is the single biggest margin
protector in this business.
No usage accounting — billing disputes are guesswork
Direct resale gives you one aggregate number from the provider. When a
client disputes their bill, you have no per-user records to back you up. Every dispute is
either a loss or a relationship risk.
Tied to one provider's quality and pricing
If your provider has a bad month — IP quality drops, a region goes down,
price goes up — you absorb it entirely. With a mixer, you shift weight to a different
provider in seconds without touching a single client's connection string.
No product differentiation
You can only sell what one provider offers. ProxyRequest lets you blend
providers into distinct products — Lite, Pro, ISP — with different routing, geo coverage,
and pricing. You're selling your product, not theirs.
You're building around their brand, not yours
Resale panels expose the underlying provider's name, endpoints, and error
strings. ProxyRequest puts your brand on everything — your domain, your dashboard, your API.
Clients see only you.
The shift from resale to product is the difference between a
thin-margin commodity business and one with real defensibility. ProxyRequest is the layer that makes
that shift possible without months of engineering.
Overview
What operators actually achieve
These are the concrete outcomes operators typically see when they switch from direct resale or a DIY
setup to ProxyRequest. Not projections — patterns from real deployments.
Days
From zero to first paying client
Connect providers, define products, create sub-users. The entire setup path is
measured in hours for a first deployment, not months.
0
Billing disputes without resolution data
Per-user, per-session logs mean every dispute has a data-backed answer. Churn
from unresolved billing arguments drops to zero.
3–4×
Engineering time saved vs. DIY
Most teams that price out building billing, accounting, routing, and a panel
from scratch find they've underestimated by 3–4x. ProxyRequest ships all of it.
100%
Supplier concealment from day one
Provider names, endpoints, and fingerprints are sanitised from the first
connection. No leakage, no client bypass attempts, no margin erosion from direct deals.
The biggest unlock for most operators isn't speed — it's the ability to
blend multiple providers into one product. When Provider A degrades, you shift
weight to Provider B. Your clients don't see the change. Your quality stays consistent. That's not
possible with direct resale.
Overview
Who this is for
ProxyRequest is built for a specific type of operator. If any of these describe you, you're in the right
place.
Proxy resellers with their own clients
You buy access from upstream providers and sell it to end clients. You want
your own product layer between them and you — branded, controlled, measurable.
Scraping SaaS and data platforms
You're building a scraping or data collection product and need a reliable
proxy backend with geo-targeting, session management, and per-user quota enforcement.
Anti-detect browser platforms
Your clients need stable IPs, sticky sessions, and UDP support for browser
fingerprinting tools. You need to assign per-user proxy credentials with concurrency and
bandwidth controls.
Affiliate proxy sellers and reseller networks
You operate a network of sub-resellers who sell to end users. The sub-user
system supports nested allocation — users can create their own sub-users and allocate data to
them.
Automation and traffic arbitrage teams
You run high-volume automated operations and need reliable geo-coverage,
session control, and a billing backend that won't become a bottleneck.
Teams operating shared proxy access
An admin creates accounts for team members, allocates data budgets per person,
and tracks individual usage. Each member has their own credentials — no shared passwords, no
usage disputes within the team.
ProxyRequest is not a proxy provider. It doesn't supply IPs.
You bring your own upstream provider contracts — Brightdata, Oxylabs, Infatica, your own modem
hardware, or any combination. If you need help choosing providers for your use case,
reach
out and we'll advise.
How it works
Four steps to a live proxy product
ProxyRequest works in four steps. You configure once; the system runs everything ongoing. Here's the
full picture from setup to first client.
1
Connect your upstream providers
Add provider credentials via the one-click import: Providers →
Import → pick from list → enter username/password. The system reads available
locations, protocols, and capabilities automatically. Or add any provider manually with an
HTTP/SOCKS5 endpoint.
2
Define your product packages
Create the products you sell — Residential, ISP, geo-targeted, or
blended. For each product, assign providers and set routing weights (e.g. 40% Provider A,
35% Provider B, 25% your own pool). You can have unlimited products with completely
different configurations.
3
Provision sub-users and allocate data
Each client becomes a sub-user. Assign them a product, set a bandwidth
cap, and the system generates their credentials. Sub-users can also create their own
sub-users and allocate data from their balance — useful for team accounts or
reseller tiers.
Via UI
Via API
Bulk operations
4
Clients connect; you monitor everything live
Traffic flows through your product layer. Suppliers are concealed. Usage
is tracked in real time. Provider health is visible in the admin panel. When someone hits
their cap, they stop — automatically, without any action from you.
How it works
Your side vs our side
The division is clean. You focus on acquiring clients and setting product pricing. ProxyRequest handles
everything technical between your providers and your clients.
Your side
Brand · Landing
Marketing · Clients
Your side
Payments · Pricing
Customer relations
ProxyRequest handles
Traffic
routing & provider mixing
Sub-user
management & credentials
Bandwidth
accounting & hard limits
Provider
concealment
White-label
dashboard (ready to use)
Payment
processing (fiat + crypto)
Analytics,
monitoring & webhooks
You handle
✓ Brand, domain, landing page
✓ Marketing and client acquisition
✓ Setting your product pricing
✓ Sourcing upstream providers
ProxyRequest handles
✓ All proxy infrastructure
✓ Sub-user management & credentials
✓ Bandwidth tracking and hard limits
✓ Full white-label client dashboard
✓ Payment processing (all methods)
Platform
Upstream providers
A provider is the company whose IPs your clients' traffic will exit through. You add them to
ProxyRequest and the system routes traffic through them — invisibly to the client.
Most popular providers can be added in under a minute. Go to Providers →
Import, pick from the pre-configured list, enter your username and password. The system reads
available locations, protocols, and capabilities automatically.
Compatible with any provider that exposes an HTTP or SOCKS5 endpoint — Brightdata, Oxylabs,
Infatica, NetNut, your own modem hardware, or custom infrastructure.
How multiple providers work together
When you add multiple providers to a product, you set a routing weight for each. The system
distributes traffic accordingly — but weights are just the starting point. The routing engine also
considers which providers have the requested geo, which support the required protocol, and whether a
session is already active. The right provider for each request is selected automatically.
A healthcheck module automatically disables degraded provider servers and
sends Telegram alerts. You can test requests through any user's order from the admin panel — useful
when a client reports issues.
Platform
Products & packages
A product is what you sell. It defines which providers are used, how traffic is weighted between them,
what geo and protocols are available, and what limits apply. You can have unlimited products with
completely different configurations.
| Product | Providers | Typical use case |
|---|
| Residential Lite | Single provider, standard geo | Basic scraping, low-volume |
| Residential Pro | 2–3 providers blended | Anti-detect, high success rate |
| ISP / Datacenter | Dedicated ISP pool | Speed-sensitive, account automation |
| Geo-targeted | Provider with best coverage per region | Ad verification, local data collection |
When you change a product's provider mix, the client's connection string stays the same.
They connect to the same endpoint with the same credentials — the routing behind it changes
silently.
Platform
Sub-users, teams & nested access
Every client you serve is a sub-user. Each has their own credentials, their own bandwidth balance, and
their own usage log. Sub-users can also create their own sub-users — making nested team
structures and reseller tiers straightforward.
How sub-users work
1
Create the user and assign a product
Takes seconds in the admin panel or one API call. Pick their product and
set their bandwidth cap in GB.
2
The system generates credentials
Each user gets a unique proxy username and password. This, combined with
your proxy endpoint and port, is what they put into their software.
3
Usage is tracked in real time
Every byte is counted against their limit. Updates every 1–3 seconds. You
can see their usage live or via API.
4
When they hit the cap, access stops
Automatic. No manual action needed. You top up, reset, or suspend via
panel or API at any time.
Nested sub-users for teams and resellers
Any sub-user with available bandwidth can create their own sub-users and allocate data to
them from their own balance. This means a team lead can create accounts for each team member and control
their individual quotas — without those members having access to the main account. It also makes tiered
reseller structures possible: your resellers manage their own client accounts directly, using the data
you've allocated to them.
Practical example: An agency buys 500 GB. They create 5
sub-accounts for their team members, giving each 100 GB. Each team member manages their own proxy
credentials and sees only their usage — not the total account. The admin sees everything.
Platform
Payments & billing
The platform includes a full built-in payment system — from the client-facing purchase flow to invoice
management. You don't need a separate payment backend. Configure your payment provider keys and
endpoints once, and the system handles the rest.
Supported payment methods
Credit and debit cards
Standard card processing via your configured payment gateway. Clients see a
familiar card checkout flow inside the dashboard.
Crypto payments (Cryptomus and others)
Bitcoin, USDT, ETH, and other major cryptocurrencies. Processed through
Cryptomus or your preferred crypto payment processor. Many proxy operators' clients prefer
to pay in crypto.
Internal wallet balance
Clients can top up a balance and pay from it. Useful for high-frequency
purchases or when you want to manage client credit manually.
Manual invoicing
For enterprise clients or custom arrangements, you can create invoices
manually and mark them as paid. Full invoice history is visible to both admin and client.
How purchase flow works for clients
Clients go to the Buy Proxies page in their dashboard. They select a
product package (e.g. Pro — 250 GB at $350), choose a payment method, and complete the payment. The
system creates an order, allocates the bandwidth, and their credentials become active — no manual step
from your side needed.
Coupon codes, custom pricing per client, and company billing information for VAT purposes
are all supported from the same interface.
Integration — what you configure
To enable payment methods, you add your API keys and endpoints in the admin settings. No
backend development is needed — the payment logic is already built into the platform. Stripe, Cryptomus,
and other gateways connect with key + webhook endpoint configuration only.
You don't need a separate billing backend. Invoice
management, payment processing, bandwidth allocation after payment, and invoice history are all
handled by the platform. The client sees it all inside their dashboard.
Platform
White-label client dashboard
ProxyRequest includes a full-featured, production-ready client dashboard that you can deploy under your
brand from day one. Your logo, your colours, your domain. No frontend development required to launch.
The dashboard supports dark and light themes out of the box,
and is fully multi-language with one-click switching — so you can serve
international clients without any localisation work on your end.
What clients see
Usage statistics with charts for data consumption and request volume —
filterable by package and date range. Live balance display, quick top-up button, and account
overview. The dashboard is the client's first screen after login and shows everything relevant
at a glance.
Clients generate ready-to-use proxy credentials directly from the panel. They
choose country, region, protocol (HTTP/SOCKS5/Auto), session type (sticky or rotating),
format, and quantity — and get a formatted list instantly. No API calls or manual
credential construction needed.
Per-domain breakdown of requests and data usage, filterable by package and
date. Clients can see exactly which sites their traffic went to, how much data each consumed,
and compare across time periods.
A live, paginated log of recent proxy requests. Each row shows: target
domain, data consumed, protocol used, geo location, and timestamp. Filterable by
package and date range. Useful for clients debugging their scraping pipelines or verifying geo
targeting.
IP Whitelist: clients restrict proxy access to specific IP
addresses — up to 50 by default, configurable higher. A security layer against credential theft.
Domain Blocklist: clients can block specific domains (or entire subdomains with
wildcard syntax) from being accessible through their proxies.
Full invoice history with payment method, status, and package details. Clients
can see active packages and their usage. Supports card, crypto, wallet balance, and manual
payments — all in one place with clear statuses.
Clients manage their own sub-users from this panel. Create users, allocate data
from their packages, view per-user usage with analytics charts, edit or delete users, and
generate proxy credentials per sub-user. Full analytics filterable by package or date range —
84 sub-users, full data visible at a glance.
Profile information, company details for billing/VAT, password management,
two-factor authentication, API key management, webhook configuration for
real-time usage notifications, and email notification preferences (marketing, expiry reminders,
security alerts).
Most operators launch with the built-in dashboard and build a custom UI later
if needed. The dashboard covers everything a client needs — and the same API it's built on is fully
accessible to you for building your own frontend at any stage.
Platform
Routing, geo & protocols
The routing engine decides which provider handles each request. It considers session state, domain
rules, geo availability, and protocol support — then applies your configured weights. All of this
happens in under 2ms.
Geo-targeting
Clients control their exit geo by including parameters in the proxy username — no separate
API call needed. Supported targeting parameters:
| Parameter | Example | What it does |
|---|
| country | us, de | Exit through an IP in that country |
| region | california | Exit through an IP in that region |
| city | miami | Exit through an IP in that city |
| asn | 15169 | Exit through an IP on that ASN |
| isp | comcast | Exit through an IP on that ISP |
If the requested geo isn't available across any provider in the product, the request
returns an error — no silent fallback. This prevents clients from inadvertently using the wrong location
without knowing.
Protocols supported
| Protocol | Status | Notes |
|---|
| HTTP / HTTPS | Supported | CONNECT tunneling, no traffic interception |
| SOCKS5 | Native | Full native implementation, not HTTP conversion |
| SOCKS5h | Supported | Hostname resolution on proxy side |
| SOCKS5 UDP ASSOCIATE | Supported | Required for some anti-detect browsers |
| HAProxy v1/v2 | Supported | Infrastructure-level integrations |
| Auto-detect | Supported | One port accepts HTTP and SOCKS5 automatically |
Sessions
By default, each new request can use a different IP. When a client includes a
session parameter in their username, the system ties that session to a specific provider
and IP for the session's TTL. Sessions are deterministic — they work consistently across multiple proxy
servers without a shared session database.
Platform
Bandwidth accounting & limits
Every byte of traffic flows through a metering layer that gives you per-user records in real time. Hard
limits enforce themselves — you don't need to watch usage manually.
Usage updates every 1–3 seconds
The proxy aggregates data locally before writing to avoid database
pressure. In practice, usage figures are always current within a few seconds.
Hard caps enforced at the routing layer
When a user hits their limit, the proxy stops serving them immediately —
enforced before traffic leaves the routing engine, not checked after the fact.
Concurrency limits per product
Set a maximum number of simultaneous connections per user on each product.
One product might have no concurrency limit; another might cap at 10. Configurable
independently per product.
Exportable logs for billing disputes
Per-session records with timestamps, target domains, bytes transferred, and
protocol. Export to CSV or query via API. Every dispute has a data-backed answer.
Billing by bandwidth (GB) is the default. Billing by request count can be
added on request. Combined models (GB + requests simultaneously) are not supported — they complicate
accounting in ways that rarely add real value in practice.
Platform
Monitoring & analytics
Full visibility across your operation — live traffic, provider health, per-user usage, error rates, and
latency — from the admin panel, via API, or through Grafana dashboards.
Live traffic overview
Requests per second, active connections, bandwidth — live. Broken down by
provider, product, and user.
Provider health
Which upstreams are healthy, degraded, or disabled. Healthcheck runs
automatically. Telegram alert when a provider goes down.
Per-user analytics
Usage history, success rate, latency, and session data per sub-user.
Available in admin, API, and the client dashboard itself.
Webhooks for real-time events
Subscribe to bandwidth usage thresholds, user state changes, upstream
health events. Signed payloads delivered to your endpoint, with a delivery log and one-click
replay.
Grafana dashboards
Full technical metrics — latency p99, error rates, connection counts.
Alerts configurable via Grafana. No pre-built templates, but full flexibility.
Launch guides
Starting a proxy business from scratch
You have a use case in mind but no infrastructure yet. Here's the path from zero to live — in the right
order.
The most important decision is your use case, not your
infrastructure. Providers that work for scraping are different from those that work for anti-detect
browsers. Get clear on what your clients will actually do — then provider choice becomes obvious.
Define your target audience and use case
Who will buy from you, and for what? Common patterns: scraping /
data collection (care about IP quality, geo, ASN), anti-detect /
accounts (stability, IP behaviour, UDP support), ad verification /
marketing (residential geo, clean IPs). The use case determines which providers you
need.
Get upstream provider contracts
Sign up with 1–2 providers that fit your use case. Starting with one is
fine — add more later. If you're unsure which to start with,
reach out with
your use case and we'll advise.
Set up ProxyRequest
Connect providers, create product packages, configure routing weights.
First setup usually takes under an hour.
Book a demo call
and we'll walk through your specific configuration live.
Configure payments
Add your payment gateway keys (card, crypto, or both) in Settings. Set your
product prices. The purchase flow and invoice management are already built into the client
dashboard.
Launch your brand
At minimum: a landing page, your domain on the proxy endpoint and
dashboard. You can use the built-in white-label dashboard from day one — customise with your
logo and brand colours. Build a custom frontend later if you need it.
Onboard first clients and iterate
Create sub-user accounts, assign products and caps, send credentials. Test
connections from the admin panel before clients start. Real usage will show you what to
adjust — which geo to add, which providers to shift weight toward.
Launch guides
Migrating an existing business
You already have clients on a different setup. Here's how to move to ProxyRequest without disrupting
them.
Migration doesn't have to be a cutover. You can run both
systems in parallel, move clients gradually, and validate each batch before switching the next.
We'll help plan the sequence on the onboarding call.
Connect your existing upstream providers
Non-destructive — doesn't affect anything yet. Your upstreams stay the
same; only the layer above them changes.
Recreate your product packages
Mirror your existing structure. Residential US, ISP, Datacenter — create
corresponding products with the same or improved routing.
Import existing clients
Create sub-users for existing clients via API or panel. Set their starting
bandwidth to match their current remaining balance. Usernames can match your
existing naming convention — clients only need to update their proxy password
and host, not their whole configuration.
Test with a small group first
Move 5–10 clients first. Validate geo-targeting, session behaviour, and
analytics. Get their feedback before rolling out to the rest.
Migrate remaining clients in batches
Most migrations require only a credentials update on the client side — new
proxy host and password. Coordinate timing per client where needed.
Decommission old system
Once all clients are stable on ProxyRequest, wind down the old setup. You
now have better per-user visibility than before and a single backend for all products.
Will clients experience downtime? Not with a gradual migration. Old system stays live while you move clients over.
Each client just gets updated credentials — no application downtime on their end, just a config
change.
Can I preserve existing usernames? In most cases yes. Sub-user usernames are flexible. The proxy password will be
new (generated by the system), but the username pattern can match your existing format —
minimising what clients need to update in their tools.
What about remaining client balances? You set each sub-user's starting bandwidth when creating them. If they had 20 GB
remaining on the old system, create them with 20 GB. Tracking picks up from there.
Can you help with the migration? Yes.
Book a call. We'll walk through your current setup, plan the
migration sequence, and be available during the transition. Support comes from the team
maintaining the routing and infrastructure stack — not a script.
Launch guides
Hybrid / headless mode
You already have a working SaaS with your own users, billing, and product logic. You don't want to move
any of that — you just want to use ProxyRequest as the proxy and traffic backend while keeping your
control plane on your side.
How it works: mirrored entities
ProxyRequest's API requires a package_id and optionally a user_id
when generating credentials or querying analytics. In a hybrid setup, you create mirrored entities on
the ProxyRequest side and store the mapping in your own database.
Your system
your_user_id: 7291
your_plan: "residential-pro"
→ maps to →
ProxyRequest
user_id:
pr_u_8x2k
package_id: pr_p_res_pro
You store this mapping in your own database — one row per user
Recommended flow
1
Create package mirrors for each of your plans
One ProxyRequest package per product type. Store the
package_id in your plan config. Do this once — not per user.
2
Create a ProxyRequest sub-user when a client signs up
On registration or purchase, call the ProxyRequest API to create the
mirrored sub-user. Store their ProxyRequest user_id alongside your internal
user record.
3
Use the mapping for all API calls
Credential generation, usage queries, analytics — look up the
ProxyRequest IDs from your mapping and pass them in the API call.
4
Handle billing on your side; sync bandwidth
When a client pays you (Stripe webhook, etc.), call the ProxyRequest API
to top up their bandwidth. When they run out, ProxyRequest cuts them off — you don't need to
do anything.
TYPESCRIPT · HYBRID INTEGRATION // When a new user signs up on YOUR platform:
const prUser = await
proxyRequest.users.create({
email: yourUser.email,
package_id: PLAN_TO_PACKAGE[yourUser.planId],
bandwidth_gb: yourUser.plan.bandwidthGb,
});
// Store the mapping in your DB
await db.userMappings.create({
yourUserId: yourUser.id,
prUserId: prUser.id,
prPackageId: prUser.package_id,
});
// Generate credentials for a user:
const map = await
db.userMappings.find({ yourUserId });
const creds = await
proxyRequest.proxy.generate({
user_id: map.prUserId,
package_id: map.prPackageId,
country: "us",
});
// When client pays → top up their bandwidth:
await proxyRequest.users.addBandwidth({
user_id: map.prUserId,
gb: 50,
});
There is no external_id passthrough currently. You maintain
the mapping in your own database. This is a thin layer — one row per user — and the pattern works
reliably in production across multiple operators using this integration mode.
If you're building a hybrid integration and want to walk through the exact API
calls for your architecture,
book a call. We've helped multiple operators implement
this pattern and can map out the integration for your specific data model.