Mobile Proxies for Automation: Rotation as an API Call, SOCKS5 With UDP, No Data Meter

Mobile proxies for automation have a different job from proxies for browsing. Nobody is going to click a dashboard button at three in the morning; a scheduler is going to call an endpoint, check the exit address, run a batch and move on. NeonProxies is built around that loop. Each line is a real USB modem, 4G/5G router or phone with its own AT&T, T-Mobile or Verizon SIM in one of eight US metros, reserved for one customer, exposing HTTP(S) and SOCKS5 with UDP, with a rotation endpoint your code can hit as often as it likes. Data is unlimited so your pipeline can plan on bandwidth instead of rationing it. Below: how the rotation API works, how much concurrency one line will take, how sticky sessions behave for bots that log in, how many accounts to put on a line, and what it costs from $5 a day.

Pricing by cadence

Daily, weekly or monthly, 4G or 5G. Every row has the API, SOCKS5 with UDP, unlimited data and unlimited rotation. The cadence is the only parameter.

Create an account Plans on the homepage

Built for schedulers, not for browsing

A proxy that is going to live inside a cron job, a Playwright worker or a queue consumer needs three things a human browser never asks for: an address change it can trigger programmatically, a protocol it can speak natively, and bandwidth it does not have to count. NeonProxies lines are shaped around those three. The rotation endpoint returns in the time it takes the modem to drop and re-acquire a carrier session. SOCKS5 and HTTP(S) are both on the line, with UDP over SOCKS5. And every plan is unlimited data, so a scraper that runs all night does not wake you with an overage.

The hardware behind that is deliberately boring: one modem, one consumer SIM, one customer, racked in a US city. There is no pool rotation that hands your worker a different device per request, which is good, because pooled addresses arrive with somebody else's history. Your automation gets one carrier line it can reason about and as many fresh addresses from that line as it wants.

The result is a proxy you can treat as a parameter. City, carrier, hardware and tier are settings you pick at checkout; everything after that is an API.

The rotation API: one GET, new address

Every line comes with a personal rotation link. Hit it with a GET from any language and the modem renews its carrier session and comes back with a new address from the same carrier in the same metro. That is the whole integration. Wire it between batches, call it when a target returns a block page, or put it on a timer in the dashboard so the address changes every N minutes without any code at all. The same operation is exposed in the API alongside line status and the current exit address, so a worker can rotate, confirm, and proceed.

Rotation is unlimited and uncounted. There is no daily budget of IP changes, no cooldown you have to track and no surcharge. The practical limit is the carrier handshake itself, which is a few seconds, so a well-behaved pipeline rotates per batch rather than per request and spends the saved seconds on actual work.

The new address stays in the metro you bought. A Phoenix line rotates to another Phoenix address, which matters when your automation is doing geo-sensitive work and a surprise jump to another state would poison a run.

Concurrency per line, and when to add a line

A line is one carrier connection, so the real constraint on concurrency is bandwidth divided by what each session pulls. A 4G LTE line delivers a steady 20 to 45 Mbps; a 5G line delivers 50 Mbps and more. Lightweight HTTP scraping with small responses will happily run dozens of parallel sessions on a single 5G line. Headless browsers loading full pages with images and scripts want far fewer per line, because each one is a real browser pulling real assets.

The other constraint is not ours, it is the target's. Many platforms count sessions per address, so beyond a point more concurrency on one line means more friction, not more throughput. The automation-friendly answer is horizontal: more lines, one per metro or one per account group, each with its own rotation link. Because lines are self-service and priced flat, scaling from one to ten is a checkout, not a negotiation.

HTTP(S), SOCKS5 and UDP for every tool in the stack

Each line listens for HTTP(S) and for SOCKS5 on its own ports. HTTP(S) is what most scraping libraries and browser automation frameworks expect. SOCKS5 is for everything else: custom TCP clients, emulators, mobile apps under test, and the tools that need UDP, which SOCKS5 carries on these lines. Nothing has to be tunnelled or wrapped.

Authentication is by username and password or by whitelisting the address of the machine running the job, and you can switch methods from the dashboard without touching the other. Whitelisting is the usual choice for servers, since it keeps credentials out of environment variables and config files entirely.

Sticky sessions for bots that log in

Not every bot wants rotation. Anything that signs in, holds a session cookie and comes back later needs the address to stay put, and on a NeonProxies line that is the default behaviour: do not call rotate, and the carrier address stays as long as the carrier keeps the lease, typically hours and often much longer. A sticky session is therefore not a feature you enable, it is what happens when your code does nothing.

The pattern most account automation settles on is one line per group of profiles, sticky during the session, rotated between sessions or between groups. The rotation link makes that a single call at the boundary, and the dashboard timer can enforce a maximum stickiness if you want a hard ceiling without writing the logic yourself.

How many accounts on one line

Technically there is no limit; the line is yours and we do not inspect what runs on it. Practically the answer comes from the platform you are automating. A handful of accounts per address on a sticky session is what most networks tolerate without raising velocity flags, and rotating between groups gives each group a fresh carrier address. Spreading groups across lines in different metros adds geographic diversity on top.

Carrier addresses help here more than any other address class. Because the carrier's network translation puts thousands of ordinary subscribers behind the same public address, platforms are slow to act against it, and a bot that behaves like a phone on a phone's address is hard to separate from the crowd. That reputation is the carrier's; the behaviour is yours to keep sane.

Speed and unlimited data your cron jobs can plan around

Predictability matters more to automation than peak numbers. A 4G LTE line sustains 20 to 45 Mbps and a 5G line sustains 50 Mbps and up, and the data behind them is unlimited: no meter and no overage line on the invoice. The ceiling is the carrier's radio in that city at that hour, which is the same ceiling a phone on the same tower would see.

Fair use applies in the ordinary sense: run the line continuously, but do not do anything that would get a real subscriber's SIM suspended by the carrier. For very large jobs, parallel lines are faster than one hammered line anyway.

Metros, carriers and hardware as parameters

At checkout you set the metro, the carrier and the hardware, and each is a real choice. Metros are New York, Los Angeles, Chicago, Houston, Phoenix, Miami, Boston and North Carolina, each with a page below on how its addresses geolocate. Carriers are AT&T, T-Mobile and Verizon, from what is racked where you want. Hardware is a USB modem for most pipelines, a 4G/5G router for workers that must run for weeks without a restart, or a real phone for targets that fingerprint the device and not only the address.

Metro is the one parameter you can change after the fact: a self-service move between our cities is free from the dashboard and completes in a couple of minutes, with the new address belonging to the new metro. The modem keeps its ports and credentials, so your config does not change.

What a line costs by cadence

Hourly is for smoke tests: $2 for the first two hours on 4G and $2 per extra hour, $3 and $3 on 5G, up to four hours per purchase, never auto-renewing. Keep the line for the full day and the hours already paid come off the daily price. A day is $5 on 4G or $7 on 5G. A week is $30 or $35. Thirty days is $68 or $82, the cheapest per day and the term where auto-renew makes sense for a pipeline that never stops.

There are no fees beyond those: rotation, API access, SOCKS5, UDP and metro moves are included at every cadence. Payment is by card, PayPal, crypto, Zelle or wire, and the line activates the instant payment clears.

Getting wired in

Create an account at the hub, add balance, pick cadence, tier, metro, carrier and hardware, and read host, ports, credentials and your rotation link off the screen. Drop them into your config, run a request to the IP checker on the tools page to confirm carrier and city, and let the scheduler take over. If a line does not work for your target within the first 24 hours of a first order, message support and we fix it or refund it. Our support engineers are on around the clock and understand modems as well as code.

Mobile proxies for automation: engineering questions