OneForProxy bills for one thing: bytes moved through the gateway. Not requests, not IPs, not connections — bytes, in both directions. It's worth walking through why that's the unit, and what it means day to day.
Why bytes instead of requests
A flat per-request price has to pick one number for every request, but requests aren't the same size. A JSON API call that returns a few hundred bytes and a page load that pulls down images and scripts can differ by orders of magnitude in actual bandwidth — yet they'd cost the same under a per-request model. Price them per request and you either overcharge the light calls or undercharge the heavy ones; there's no single number that fits both.
Billing by byte sidesteps that: the cost of a request is proportional to what it actually transferred, whether that's a tiny status check or a large response body. A connection that fails before any data moves costs nothing, because nothing moved.
How usage is measured and settled
Traffic — upload and download together — is metered as it flows through the gateway and settled roughly every 30 seconds, showing up in your dashboard shortly after. There's no batching delay that hides usage until the end of the day, and no minimum charge per connection beyond the bytes it actually sent and received.
Quota first, then balance
Two ways to pay sit behind the same per-GB rate: a prepaid traffic package (a fixed block of GB bought up front) and a pay-as-you-go USD balance, topped up with USDT-TRC20. If you hold both, quota from a traffic package is always consumed first; your USD balance is only charged once that quota runs out. See Pricing for the current rate per GB and the package sizes available.
When neither quota nor balance is left, new connections are refused — you'll
see 402 over HTTP or the matching SOCKS5 reply — until you top up or buy
another package. Traffic already in flight during the last settle window is
still billed against whatever balance was available when it moved.
What counts as billed traffic
Billed bytes are upload and download together — the request you send out through the gateway and the response that comes back through it. There's no separate accounting for the two directions and no distinction based on content type, status code, or which targeting options were in the username; a byte is a byte regardless of whether it came from a JSON endpoint or an image.
Checking usage programmatically
The dashboard shows current balance and remaining quota, and the same numbers are available over the API for anything you'd rather check from a script:
curl -H "X-API-KEY: $KEY" "https://oneforproxy.com/balance"
# 200
{ "balance": 42.5, "currency": "USD", "quota_bytes_remaining": 5368709120, "price_per_gb": 3.0 }Create the API key under API keys in the dashboard and send it in the
X-API-KEY header, never in the URL — the same rule the Docs
page calls out for this endpoint. quota_bytes_remaining is prepaid package
quota; once it hits zero, further usage draws from balance at
price_per_gb.
Why this shape holds up under retries
Because billing tracks bytes and not call count, retrying a failed request doesn't multiply your cost the way a per-request price would — a retry that transfers the same response costs the same as one successful call would have, and a connection that never completed costs nothing at all. The number you're billed for is the number of bytes that actually crossed the gateway, full stop.
Related reading
- Billing and packages in the knowledge base covers topping up, package sizes, and reading the usage page in detail.
- Getting started walks through creating a credential and sending your first request.
- Pricing has the current per-GB rate, traffic packages and top-up minimums.