Dedicated Line API vs Per-GB Residential Pool API: What Changes in Your Code

Two kinds of proxy product expose themselves to developers in two different shapes. A dedicated mobile line, which is what Mobile Proxies US sells, is a resource: one SIM, one device, one exit IP at a time, listed by licence uuid, rotated on request, billed per day, week or month with no data meter. A per-gigabyte residential pool is a service: a gateway host and a username grammar that selects country, session and stickiness, billed per gigabyte transferred. Both have APIs; they are not interchangeable. This page compares them along the axes that show up in code: cost model, identity, control, observability, failure modes and fit by job.

Cost model: time versus bytes

A dedicated line costs a fixed amount per period: $5 a day, $29 a week or $66 a month on 4G; $6, $33 or $77 on 5G; hourly at $2 or $3 for the first two hours then the same per hour, up to four hours. Data is not metered. The cost of a test suite that downloads a gigabyte of assets is the same as the cost of one that downloads a kilobyte. Budgeting is a calendar calculation.

A residential pool costs per gigabyte. Every byte through the gateway, including retries, redirects, images you did not need and the HTML of a 403 page, is billed. Budgeting is a traffic estimate, and traffic estimates are wrong in one direction. Code written for a pool grows byte-saving logic (block images, abort on size, cache aggressively) that code written for a line does not need.

Identity: one address you hold versus a stream of addresses

A line has one exit IP until you ask for another. The address belongs to AT&T, T-Mobile or Verizon and is shared with that carrier's subscribers through NAT, so destinations classify it as mobile. Sessions can live for hours on the same address because the carrier keeps it. Your code holds a stable handle (the licence uuid) and the address is a property of it that changes only when you rotate or the carrier re-assigns.

A pool gives a different address per request by default, or a sticky session for a bounded window (commonly up to half an hour) selected through the username. The addresses are household connections in many countries, classified as residential, and you never hold one: the session can end on the pool's schedule, not yours. Code must handle address change as a normal event inside a session rather than a deliberate one between sessions.

Control surface: rotate and status versus session parameters

The line API is a small resource API. GET /proxies/my lists the lines; GET /proxy/status reads a line's current exit IP; a GET on rotation_link rotates it; POST /license/update-rotation-time sets a timer, and the dashboard or a click does the same by hand. The operations are about the device: is it connected, what address does it hold, give me a new one. There is no targeting parameter because the geography is a property of where the device physically sits; to change it you move the line between our eight metros, free, with the remaining time kept.

The pool API is mostly a credential grammar plus account endpoints. Country, state, city, ASN, session id and stickiness are encoded in the proxy username; account endpoints report balance and usage. The operations are about selection: give me an address with these attributes for this many minutes. Both are legitimate designs; they answer different questions.

Side by side

The table lists the properties as they appear to a developer integrating each product.

Observability and failure modes

With a line, the API tells you the thing that matters: the current exit IP, whether the modem is connected, when the plan ends, and an audited history of every address change. Failures are concrete and local: a 400 because a rotation fell inside the line's wait, a reset connection while the modem re-attaches, a slow cell at rush hour. Each has a correct handling: wait as the message says, retry after confirmation, accept mobile speed. A 404 from /proxy/status means the licence expired; a start-up check catches it.

With a pool, failures are statistical: some fraction of addresses in a given country are already flagged by your target, some sessions end before your flow does, and the budget runs out when a target starts serving large error pages. The handling is retry logic and per-request accounting. Neither set of failures is worse in the abstract; they belong to different jobs.

Which to call from your code

Call a dedicated line when the job is one identity doing a sequence of things: QA of a signup, checkout or app flow as a US mobile user; a long-lived account that must look like one phone; reproducing a user's report on their carrier and metro; measuring latency from a real US mobile client; webhook, SMS and verification flows that expect a US network; anything where unmetered transfer matters. Call a pool when the job is breadth: many addresses in many countries for public reads where no identity persists and the byte count is predictable.

Many teams use both, from the same dashboard: lines for the identity-bound and US-mobile-bound work, pool data for wide public reads. The dashboard's Buy Proxy page sells residential and mobile pool data by the gigabyte next to the lines, so the choice can be made per job rather than per vendor.

• Identity persists across requests: line.
• US mobile classification required: line.
• Heavy transfer, unpredictable byte count: line.
• Many countries, one request per address: pool.
• Thousands of parallel addresses for public reads: pool.
• Both patterns in one project: one of each, one dashboard.

Questions about per-GB pricing