Proxies for Data-as-a-Service Companies: Buying for Resale

The mechanics are the same: requests go out through an IP pool and pages come back. The commercial position is not.

Three consequences follow. You need to know proxy cost per record, not per month. You need capacity sized to a delivery deadline, not to average load. And you need contractual clarity from the proxy vendor, because your customer contract assumes a supply chain you do not fully control.

If your datasets feed model training rather than resale, the priorities shift toward corpus breadth and text quality, which we covered in proxies for AI training data. This guide assumes you invoice someone for the output.

Start with the number your finance team actually needs: what does collecting one delivered record cost in proxy spend?

Worked model, illustrative assumptions only: a retail product dataset of 2,000,000 SKUs refreshed daily. Each record needs on average 1.15 requests once pagination, retries and occasional detail-page fetches are counted. Average transferred page size is 120 KB. Thirty refreshes a month.

The per-GB rates above are round assumptions for illustration, not any vendor's published price. Check real rate cards when you model your own sources.

Divide and the spread is stark. On the assumed metered tiers, proxy spend is roughly $0.00007 to $0.00028 per delivered record. On a flat plan it falls to $0.000004 or less. Neither is large per record, but on a dataset sold for a fixed annual fee, the metered figure also moves: if a retailer ships heavier pages or your retry rate doubles, the bytes and the bill rise while the contract price does not.

Two cautions keep this honest. First, a flat datacenter plan only works for sources that accept datacenter IPs. If a source blocks hosting ranges, the cheap line in the table is not available for it at any price. Second, proxy spend is rarely the largest cost in a DaaS business. Parser maintenance, QA and customer support usually are. The reason to model it anyway is variance, not size: it is the cost line most likely to move without anyone deciding to move it.

The dataset contract tells you which proxy billing model fits. Match the shape of the revenue to the shape of the cost.

Most DaaS catalogues contain several rows. A company selling a flat subscription feed from 400 sources might put 350 easy sources on a flat datacenter plan and route 50 guarded ones through a metered service, pricing that premium into the product tier that depends on them. The mistake is choosing one billing model for the whole catalogue because it was the first vendor someone signed. Our breakdown of datacenter proxy pricing models explains how each model reacts to heavier pages and tighter rate limits.

A refresh commitment ("updated every 24 hours", "delivered by 06:00 UTC") is a throughput requirement. Average load does not matter; finishing inside the window does.

Required concurrency comes from four inputs: requests per refresh, average seconds per request, the window you allow yourself, and headroom for retries and bad days.

# Capacity planner for a dataset refresh window.
# All inputs below are assumptions: replace them with your own logs.

records_per_refresh = 2_000_000
requests_per_record = 1.15      # pagination, retries, detail pages
avg_seconds_per_req = 1.8       # measured end to end through the proxy
window_hours        = 20        # keep 4 hours of a 24h SLA as buffer
headroom            = 1.5       # bad days, source slowdowns, reruns
avg_page_kb         = 120

requests  = records_per_refresh * requests_per_record
window_s  = window_hours * 3600
threads   = requests * avg_seconds_per_req / window_s * headroom
mbps_avg  = requests * avg_page_kb * 8 / 1000 / window_s   # megabits per second

print(f"requests per refresh: {requests:,.0f}")
print(f"concurrent threads needed: {threads:,.0f}")
print(f"average throughput inside the window: {mbps_avg:,.1f} Mbps")

With those assumptions the script prints about 2.3 million requests, roughly 86 threads, and about 30.7 Mbps of average throughput inside the window.

The second number is the one people miss. On an unmetered plan, the thread count is rarely what binds you. The speed ceiling is. SparkProxy's fair usage policy caps Starter at 25 Mbps, Core at 50, Boost at 100 and Plus at 150. Starter's 100 threads cover the concurrency in this example, but its 25 Mbps ceiling sits below the 30.7 Mbps average the window needs. Core, at $140 a month for 250 threads and a 50 Mbps ceiling, is the smallest plan that fits both. Those caps are ceilings, not guaranteed rates, which is one more reason for the headroom multiplier.

Then check the constraint no plan can fix: per-source politeness. If 40% of those records come from one retailer that starts returning 429s above a certain request rate per IP, your refresh time for that source is set by its tolerance, not by your thread count. Spread that source across enough exits and schedule it first. Our guide to managing per-IP request limits covers the arithmetic, and incremental scraping with change detection is often the cheapest way to shrink the refresh itself.

When your revenue depends on a proxy provider, its terms of service are part of your supply contract. Read these clauses before you build a product on top of one.

Two of those deserve emphasis. Resale language trips up new DaaS companies because some AUPs are written for resellers of proxy access. Selling a dataset is a different activity, but get that in writing during onboarding rather than arguing it after a compliance review flags your account. Providers that run KYC and use-case approval will usually ask what you collect and for whom; describe the resale model plainly at that stage.

Uptime credits are almost never proportional to your exposure. A vendor credit worth a fraction of one month's plan does not cover a missed enterprise delivery. Treat SLA credits as a signal of how seriously the vendor measures uptime, and buy your real protection through architecture. The procurement side, including what security reviewers ask, is covered in our enterprise proxy procurement checklist.

Institutional data buyers, especially in finance, run vendor due diligence on how a dataset was collected. Expect questions like these, and have answers written down before the first large deal.

• Where do your collection IPs come from? Datacenter IPs are leased from hosting providers, which is simple to explain. If you use residential or mobile exits from a third party, you inherit the question of how those devices' owners consented, and the buyer may ask for the vendor's sourcing statement.
• Do you collect data behind logins? Many buyers exclude datasets built from authenticated sessions. Keep a source register that records whether each source is public.
• Do you honour robots.txt and source terms? Answer per source, not with a blanket statement you cannot prove.
• Does the dataset contain personal data? If yes, you need a lawful basis and a retention policy, and some buyers will refuse the file regardless.
• Can you reproduce a historical record? Keep raw captures or hashes with collection timestamps so you can show when and where a value came from.
• What happens if a source objects? Have a documented takedown process and know how quickly you can remove a source from future deliveries.

None of these are proxy questions on the surface, but your proxy choice shapes several answers. A datacenter-first collection setup is the easiest to document. For the legal backdrop, see are proxies legal for business use, and take advice specific to your jurisdiction and data.

Single-vendor dependency is the most common structural risk in small DaaS companies. The fix is not buying twice as much; it is giving each vendor a clear role.

Primary lane: a flat, unmetered plan carrying the easy majority of sources. Its cost is fixed, so it absorbs retries, heavier pages and reruns for free.

Overflow and hard-source lane: a metered provider or scraping API with a different network, used for sources the primary lane cannot serve and as failover capacity. Its cost is variable, but it only carries a slice of traffic most of the time.

Route by source, not by request, so a failover is a config change:

# sources.yaml: routing is per source, so moving one is a one-line change
defaults:
  lane: primary
lanes:
  primary:
    proxy: http://USER:PASS@gateway.sparkproxy.io:11000
    max_threads: 200
  overflow:
    proxy: ${OVERFLOW_PROXY_URL}     # second vendor, different network
    max_threads: 40
sources:
  retailer-a:   { lane: primary }
  retailer-b:   { lane: primary, per_ip_rps: 0.5 }
  marketplace-c: { lane: overflow }  # blocks hosting ranges
failover:
  trigger: success_rate_below_0.85_for_15m
  action: move_source_to_overflow

Test the failover on purpose once a quarter by moving a real source for a day. A failover path that has never carried production traffic tends to discover its credential or allowlist problems at 3am. Our guides on proxy failover and redundancy and switching proxy providers without downtime go further into health checks and cutover order.

If you whitelist by IP rather than username and password, count whitelist slots per plan against every worker host in both lanes. Running out of slots during an incident is avoidable.

Track the numbers that connect proxy behaviour to delivered data, per source:

Count soft blocks honestly. A 200 response with a captcha page or an empty product grid is a failure, and a success rate that ignores that will look healthy until a customer finds nulls in their file. How to measure proxy success rate covers content-based checks.

SparkProxy is a good fit for the primary lane and a poor fit for some hard sources, and it is worth being clear about both.

Where it fits: datacenter proxy plans are flat monthly with unlimited bandwidth and 30-day validity. Starter is $75 for 100 threads, Core $140 for 250, Boost $240 for 500 and Plus $440 for 1,000, with 5 to 25 whitelist slots by plan. Pro and Pro+ tiers with 1,500 and 2,000 threads exist under the fair usage policy without a public price, and custom arrangements go up to 1 Gbps. The network is 1M+ datacenter IPs across 80+ countries, including 50,000+ in the US, on gateway.sparkproxy.io with port 11000 for rotating HTTP/HTTPS, 11002 for sticky sessions and 13000 for SOCKS5. Rotation is random per request or automatic every 5 minutes.

Where it does not: SparkProxy does not sell residential or mobile proxy plans. For scraping jobs, the SparkProxy Scraping API does offer residential exits through its premium_proxy option, which routes a request through a residential pool for 10 credits, or 25 with JavaScript rendering. Sources that block hosting ranges need a different vendor in your overflow lane. For JavaScript-heavy sources you do not want to render yourself, the SparkProxy Scraping API starts at $49 for 250,000 credits (1 credit for a plain fetch, 5 with JS rendering, 10 for a screenshot or PDF), with 1,000 free credits and no card to test a source before routing it.

A practical way to start: take your ten highest-volume sources, run a day of real traffic through a flat plan, and record success rate and requests per delivered record per source. The sources that pass go to the primary lane. The ones that do not tell you what your second vendor needs to be good at.