Proxy Reseller Program: How Massive Tracks and Controls White-Label Sub-Account Traffic

A proxy reseller program lets a company sell residential proxy access under its own brand while the traffic runs on another provider's network. At Massive, resellers do this through the Proxy Resellers API: they create a sub-account for each of their customers, allocate traffic to it in bytes, and read its usage back. Each sub-account gets its own login, the parent's username and its own joined by an underscore (parent_sub), so every request on the network stays tied to both the reseller and the end customer. This transparency report explains how that tracking works, what a reseller can see and control, which limits Massive applies on top, and what we found when we tested the API's front door without credentials.

Key Takeaways

• Resellers manage sub-accounts through the Proxy Resellers API (the /resellers endpoints on Massive's network API). Access is not automatic: the key "must be requested to Massive support" (Massive Docs).
• Every sub-account has its own credentials but stays linked to the parent. Its traffic is counted against its own allocation and attributed to the reseller.
• Resellers can allocate traffic, read per-account usage (cumulative, by time window, or daily for up to 90 days), block up to 100 domains per account, cap each session by size or duration, and disable an account.
• Daily usage comes from an hourly rollup and is "not suitable for live enforcement." Use used_bytes and limit_reached from the account list for allowance checks.
• In our test on October 19, 2026, requests with no key or an invalid key both returned 403 Forbidden, not the 401 listed in the API reference. Treat both as authentication failures.

How does a proxy reseller program work?

A reseller buys capacity from a network provider, then divides it among its own customers. The customers see the reseller's brand, prices, and dashboard. The network provider sees the traffic and needs to know whose it is.

That last point is why a reseller program is a transparency question as much as a commercial one. If resold traffic arrived on the network under one shared login, nobody could tell which end customer sent which request, which makes abuse reports hard to act on and usage hard to bill. Massive's design avoids that by giving every end customer a separate, linked identity.

How are reseller sub-accounts created and identified?

The reseller sends a POST /accounts request with a username, a password, and optionally an initial allowance in bytes (Create account). The API returns an account ID. From then on, the end customer connects to the Massive Network with these credentials:

username: <customerUsername>_<accountUsername>
password: <accountPassword>

The docs put it plainly: "The account will be linked to the customer but have own credentials to access the Massive Network." In the docs' own example, a reseller whose login is demo@joinmassive.com creates johndoe@example.com, and that customer connects as:

demo@joinmassive.com_johndoe@example.com

The docs add that "targeting params can be provided according to the Massive Network documentation," which appends keys such as -country-US to the username, as described in the geotargeting guide.

A helper that builds the name, tested against the docs' example:

def proxy_username(parent, sub, targeting=""):
    user = f"{parent}_{sub}"
    return f"{user}-{targeting}" if targeting else user

Because the parent's username is part of every sub-account login, attribution doesn't depend on the reseller reporting it. It is in the credential itself.

How is reseller traffic allocated and tracked?

Allocation is in bytes. A POST to an account's /allocations endpoint adds traffic to it, and the value "cannot be 0" (Allocate traffic). A GET on the same endpoint lists every allocation made, with a timestamp, which gives the reseller an audit trail of what it granted and when.

Usage can be read three ways, and the docs say which to use for what:

The account list is the one to watch for limits. The docs call it "the recommended way to monitor usage across subaccounts," and warn that polling the per-account usage endpoint for each customer "puts substantially more load on the API" (List accounts). Its used_bytes is "the figure the account allowance is enforced against," updated "near-real-time rather than instantaneous."

Daily usage has two caveats a reseller should pass on to its own billing team. It "is sourced from an hourly rollup," so it is complete only "through the end of the previous hour and is not suitable for live enforcement." And "the rollup begins on 2026-04-10, so days before that date return zeros" (Daily usage). "Days with no traffic are returned with zeroed counters, so the series is always contiguous and needs no gap handling."

A simple allowance report built from one GET /accounts call:

GB = 1_000_000_000  # the API counts bytes
def usage_report(accounts, warn_at=0.8):
    rows = []
    for a in accounts:
        limit, used = a.get("limit") or 0, a.get("used_bytes") or 0
        share = used / limit if limit else None
        flag = ("limit" if a.get("limit_reached")
                else "warn" if share is not None and share >= warn_at
                else "ok")
        rows.append({"username": a["username"], "status": a.get("status"),
                     "used_gb": round(used / GB, 2), "share": share, "flag": flag})
    return rows

We tested both helpers on the docs' example, a targeting suffix, and three edge cases (an account near its limit, one at its limit, and a disabled account with no allowance); every assertion passed. An account with a limit of 0 shows as "ok" because nothing has been allocated to it yet.

What controls does a reseller have over each sub-account?

Four, each set per account through the API:

1. Enable or disable. A POST to an account's /disable endpoint turns off its credentials, and /enable turns them back on. The status field in the account list shows which state each account is in (Disable account).
2. Domain blocklist. A PUT to /blocklist sets up to 100 domains, each up to 253 characters, that the account can't reach. Domains are "automatically deduplicated and sanitized" (Blocklist).
3. Inherit the parent's blocklist. Create an account with sync_with_parent: true, and its blocklist is merged with the reseller's own. The sub-account "can still have its own blocklist entries," and the docs describe the result as "merged with the parent's."
4. Per-session limits. A PUT to /session-limit caps a single session by traffic (for example "250mb") or duration (for example "15m"). "The proxy disconnects the session once it reaches either ceiling," and 0 turns a ceiling off (Session limit).

The inherited blocklist matters most for transparency. A reseller that promises its own customers it won't serve certain sites can enforce that promise once, at the parent, for every sub-account created with sync_with_parent: true.

What does Massive enforce on top of the reseller?

Sub-accounts authenticate against the same Massive Network as everyone else, so the network's own rules sit above anything a reseller configures. That includes the nine destination categories Massive blocks by default, such as banks, crypto exchanges, and gambling sites. The Resellers API has no setting for those categories. Per the blocked destinations policy, category exceptions are granted per customer "through Massive's customer due diligence process." It also includes domain blocking and the usage rules every customer agrees to.

Access to the Resellers API is gated as well. The Network API key "is not automatically enabled for this API," and enabling it "must be requested to Massive support" (Massive Docs). The authentication guide spells out the order: request access from support, and "once approved, you will receive your API key" (Authentication). No sub-account can be created before that.

Because every sub-account authenticates with its own login, and that login contains the parent's username, each sub-account's traffic is recorded under its own login. If you see abusive traffic from the network, our abuse reporting page explains how to report it.

What happens if you call the Resellers API without valid credentials?

We checked on October 19, 2026, with no account and no real key. We sent GET /resellers/accounts with no x-api-key header, then with an invalid key, and repeated the test on the daily usage endpoint and on the separate Reporting API.

Two takeaways. First, every request we sent got the same 403 body, so the response gave nothing away to a caller without a valid key. Second, the API reference lists a 401 "Operation not authorized" response on its endpoints (for example Create account), but the gateway answered 403 in every case. HTTP itself separates the two: 401 means the request lacks valid credentials, and 403 means the server understood it but refuses (RFC 9110, 15.5.2 and 15.5.4). A reseller's integration should treat 401 and 403 the same way: stop, check the key, and confirm Resellers API access was enabled. Until the reference and the gateway agree, handling both is the safe choice.

How is a reseller program different from a white-label proxy?

The terms overlap. "White-label proxy reseller" usually means the reseller's brand is the only one the end customer sees. Massive's docs don't use the phrase "white-label," but the sub-account design is what makes it possible: the end customer gets its own credentials and never needs a Massive login, while the parent's username in every sub-account login keeps each customer's traffic tied to the reseller.

The other common model is a single shared login that the reseller splits up in its own software. It is simpler to start, but it hides the end customer from the network, which makes per-customer limits, blocklists, and abuse handling the reseller's job alone.

What this report doesn't cover

This report covers the proxy side: sub-accounts on the residential network. Massive's Web Render API has a separate set of user and credit endpoints for partners that resell rendering, search, and AI calls; those balances are counted in credits, not bytes. For your own account's daily totals, the Reporting API returns connections and bytes per day. If you're new to the network itself, start with what a residential proxy is.

To set up a reseller account, contact Massive support and ask for Proxy Resellers API access.

The bottom line

• In Massive's proxy reseller program, each end customer has its own linked credentials, so traffic stays attributable to both the customer and the reseller.
• Resellers can allocate, measure, block, cap, and disable per customer. Use the account list for limits and the daily endpoint for reports.
• Network-wide rules, gated API access, and traceable logins sit above all of it. Treat 401 and 403 alike in your integration.

Sources

• IETF, "RFC 9110: HTTP Semantics"
• Massive Docs, "Get the allocation list"
• Massive Docs, "Authentication"
• Massive, "Blocked Destination Categories"
• Massive Docs, "Proxy Resellers API: Introduction"
• Massive Docs, "Create new account", "Get list of existing accounts", "Allocate traffic for an account"
• Massive Docs, "Get account usage", "Get daily account usage"
• Massive Docs, "Update domains blocklist", "Update per-session limit", "Disable account"
• Massive Docs, "Domain blocking"
• Massive, unauthenticated request test of the Resellers and Reporting APIs (first-party test)