Proxies for Freelancers: Sizing and Billing Scraping Clients

Every freelance scraping job lands in one of three arrangements, whether you choose it deliberately or not.

Bundled feels cleanest and is the one that hurts most often. A client asking for 50,000 product pages sounds like a 50,000-request job. Then you find half the catalogue needs JavaScript rendering, the site starts returning challenges after the first 10,000 pages, and your development test runs have consumed more requests than the delivery itself. None of that was in the quote.

Itemised pass-through protects you if you can show usage per job. That is a record-keeping problem, and the sections on splitting and credit billing below solve it.

Client-owned is underused by freelancers because it feels less professional to ask a client to sign up for something. It is the opposite. A company that relies on a daily price feed should own the account that feed runs on, receive the provider's invoices, and accept the provider's acceptable use terms in its own name.

Check the provider's rules on contractor access before you set this up. SparkProxy's Terms of Use, for example, prohibit providing access to its proxy infrastructure to third parties without express written permission, so ask the client to get written confirmation from support that you may operate the account on their behalf.

A practical default: bundle below a small threshold you can comfortably absorb, pass through above it, and push anything recurring beyond three months towards client ownership.

The three common billing units behave very differently for someone whose workload arrives in bursts.

SparkProxy sells the first two, so here are the published numbers to plan against.

Proxy plans run Starter at $75 a month for 100 threads and 5 whitelist slots, Core at $140 for 250 threads and 10 slots, Boost at $240 for 500 threads and 15 slots, and Plus at $440 for 1,000 threads and 25 slots. All have unlimited bandwidth and 30 days of validity, with a fair usage speed ceiling of 25, 50, 100 and 150 Mbps respectively. Traffic goes through gateway.sparkproxy.io: port 11000 rotates per request, 11002 holds sticky sessions, 13000 is SOCKS5.

The Scraping API gives 1,000 free credits with no card, then Starter at $49 for 250,000 credits and 50 concurrent requests, Growth at $99 for 1,000,000 and 100 concurrent, Pro at $249 for 3,000,000 and 200 concurrent, and Scale at $599 for 8,000,000 and 400 concurrent. A plain fetch costs 1 credit, a JavaScript render 5, a screenshot or PDF 10.

The freelancer reading of those numbers: the API is the natural fit while your client list is irregular, because cost follows work. A flat proxy plan pays off once you have enough steady recurring jobs that the plan would rarely sit idle. How many threads each job needs is a separate exercise, covered in how many proxies you need for scraping.

Most underpriced freelance scraping quotes miss the same four lines. Build the estimate from them, not from the client's headline page count.

1. Delivery volume. Pages the client actually wants, multiplied by how often.
2. Render share. The fraction of pages that need a headless browser. On credit billing this line changes the cost fivefold per page.
3. Retries and challenges. Requests that come back blocked or empty and must be repeated.
4. Development runs. Every parser change you test against the live site consumes requests. On a site with messy templates, this line can rival the delivery run.

Here is a worked quote using those lines. The volumes and percentages are illustrative assumptions for a hypothetical job, not measurements, and you should replace them with a short test against the real target.

Job: one-off extraction of 80,000 product pages, with 30% of pages needing rendering.

That fits one month of the $49 Starter plan with a little headroom. The same job quoted naively as "80,000 pages" would have assumed 80,000 credits and understated usage by about three times.

Put the assumptions in the quote itself: "Includes up to 240,000 API credits of collection. Additional collection required by changes to the target site is billed at cost." One sentence converts a surprise into a change request.

Before quoting, spend an hour and a few hundred of the free credits pulling a sample of pages. You will learn the render share, whether the site challenges plain requests, and roughly how large the pages are. That hour is the cheapest insurance in freelancing.

Once you run recurring jobs for several clients on one flat plan, you need a fair way to split the bill. Three resources are shared, and each needs a different rule.

Threads are a shared pool. A 100-thread Starter plan does not become 100 threads per client. If two clients' jobs run at the same hour, they compete. Schedule recurring jobs in separate windows where possible, and cap each job's concurrency in code so one runaway job cannot starve the rest.

Whitelist slots are a per-machine budget. Starter includes 5 slots, meaning 5 source IPs can be authorised. Spend them on stable egress points such as the VPS or servers your jobs run on, not on laptops and short-lived CI runners, and use username and password authentication for everything that moves around. What IP whitelisting is for proxies explains the trade-off.

Cost is best split by thread-hours. Log, per job run, how many threads it held and for how long. Thread-hours are simple to record and track what actually consumed the plan's capacity, which bandwidth does not on an unmetered plan.

A minimal allocator that turns a month of run logs into invoice lines:

import csv
from collections import defaultdict

PLAN_COST = 75.00  # SparkProxy Starter, per 30-day period

# runs.csv columns: client,job,threads,minutes
usage = defaultdict(float)
with open("runs.csv", newline="") as f:
    for row in csv.DictReader(f):
        usage[row["client"]] += int(row["threads"]) * int(row["minutes"]) / 60

total = sum(usage.values())
for client, thread_hours in sorted(usage.items(), key=lambda kv: -kv[1]):
    share = thread_hours / total
    print(f"{client:<18} {thread_hours:>8.1f} thread-h  {share:>6.1%}  ${PLAN_COST * share:>7.2f}")

With three clients at 40%, 35% and 25% of the month's thread-hours, the $75 plan splits into $30.00, $26.25 and $18.75. Clear, defensible and easy to attach to an invoice.

Two decisions to make up front and state in writing:

• Idle capacity. If your jobs used a small fraction of the plan, clients should not pay for the whole plan between them unless you agreed that. Many freelancers bill a fixed monthly infrastructure fee per retainer instead and treat the plan as their own overhead, which is simpler once you have three or more steady clients.
• Markup. Passing cost through at exactly cost undervalues the time you spend managing credentials, monitoring and troubleshooting. A stated handling percentage is normal and far better received than a hidden one.

If your provider supports separate sub-user credentials, give each client job its own. It makes per-client usage visible and lets you revoke one job without touching the others. Our guide to sub-users and credential rotation covers how to structure them.

Credit-based APIs make pass-through billing almost free to administer, because each response states what it cost. SparkProxy's Scraping API returns an X-Credits-Used header on plain responses and a credits_used field in the JSON envelope, and it echoes back a tag parameter you set. Put the client identifier in tag and log both.

import csv, datetime, requests

API = "https://scrape.sparkproxy.io/api/v1"
KEY = "YOUR_API_KEY"

def fetch(url, client, render=False):
    r = requests.get(API, headers={"X-API-Key": KEY}, timeout=120, params={
        "url": url,
        "render_js": str(render).lower(),
        "tag": client,
    })
    credits = int(r.headers.get("X-Credits-Used", 0))
    with open("credit_ledger.csv", "a", newline="") as f:
        csv.writer(f).writerow([datetime.date.today(), client, url, r.status_code, credits])
    return r

At month end, sum the ledger by client and multiply by your plan's price per credit. On Starter that is $49 divided by 250,000, roughly $0.0002 per credit. Two details keep the ledger honest:

• The API refunds credits automatically when a job fails with a server-side error or a 530 after its retries, so failed jobs log zero or are refunded. A 200 response containing a block page or an empty template is still a charged request, so your parser should flag those to decide whether the client or you bears them.
• Development runs belong in the ledger too, under the client's tag, if your contract says development collection is billable. If it does not, tag them separately so you can see what the job really cost you.

This is the section freelancers usually learn the hard way. A proxy account belongs to whoever signed up, and the provider holds that person responsible for every request sent through it, no matter which client it was for.

If one client asks you to collect something the provider's acceptable use policy bans, such as logged-in personal data, credential testing or anything touching payments, and you run it on your shared account, the consequence is not limited to that job. A suspended account stops every client's pipeline at once, and you will be explaining downtime to people whose work was entirely legitimate.

Four habits keep that risk proportionate:

1. Never hand a client your credentials. Running jobs for a client is a service. Giving them a login to your plan is redistribution, which SparkProxy's terms prohibit without written permission and many other providers restrict as well. The same terms treat sharing one plan's credentials across users or machines to get around its thread allocation as a fair usage breach, so keep every job inside the concurrency you paid for.
2. Screen jobs against the provider's terms before you accept them, not after the account is flagged. Providers that ask about your use case at signup are telling you what they will check later; why proxy providers require KYC and use-case approval explains the reasoning.
3. Keep request rates polite per target, whatever the client's deadline. Hammering a small site is the kind of traffic that generates abuse reports, and it is avoidable. Our ethical scraping and rate limiting guide covers sensible defaults.
4. Move higher-risk or high-volume clients onto their own accounts. Isolation is worth more than the convenience of one bill.

None of this replaces legal advice, and requirements vary by country. These are the clauses that most often decide whether a proxy problem becomes a dispute.

The lawful use clause does not make an unlawful job acceptable, and it does not transfer the provider's terms away from you if the job runs on your account. It does make the client's responsibility for how the data is used explicit.

Retainers end, or clients hire in-house. A job built for handover from the start moves in an afternoon. One built around your personal account can take days.

Build for handover from the first commit:

• Read proxy and API settings from environment variables, never from code. The client replaces the values, nothing else changes.
• Keep the gateway host, ports and authentication method in one config file with comments on why each was chosen, for example sticky port 11002 because the job logs in, or rotating port 11000 because it does not.
• Document the observed limits: the concurrency the target tolerates, the time windows the job runs, the retry rules. This is the most valuable page you will hand over.
• Run both accounts in parallel for one cycle before switching yours off, and compare output counts.

The mechanics of cutting over without a gap are covered in how to switch proxy providers without downtime, which applies equally to moving between two accounts at the same provider.

Whichever row you are in, the pattern is the same. Know what every job consumes, write down who pays for it, and keep one client's problem from becoming everyone's outage. For the wider cost trade-off between the two SparkProxy products, see web scraping API vs self-managed proxies.