Bulk operations — managing 100+ proxies without losing your afternoon

The per-row dropdown on /proxies is friendly when you have five tunnels. At a hundred and forty it becomes purgatory. At some point you stop wanting to stop, change protocol, then restart one tunnel at a time, and you need a way to act on the whole fleet — or a precisely filtered slice of it — in a single shot.

Bulk operations are built exactly for that moment. The panel exposes them through a sticky selection bar that appears the instant you tick more than one row, and every action in that bar is also available on the REST API so your own provisioning scripts can drive the same logic. This guide covers both paths, the edge cases that bite at scale, and how to wire it all into an automated workflow.

Why row-by-row management breaks at scale

Every additional proxy you add multiplies the click-count for routine maintenance. Restarting a pool of twenty devices after a carrier outage, rotating IPs across a token group before a scraping run, or switching a batch from HTTP to SOCKS5 for a new client — each of these operations should take one action, not twenty separate ones. Without bulk tooling, operators end up writing fragile shell loops against the API or, worse, doing it by hand and missing some.

The panel's bulk system and the matching API endpoint eliminate that gap. Everything you can do per-row, you can do per-selection at any scale, with a consistent per-id result so you know exactly which items succeeded and which need a retry.

The selection bar in the panel

On /proxies, every row has a checkbox in its left gutter. Tick two or more and a sticky action bar slides up from the bottom of the table. Selections survive sorting and column filtering, so the most efficient workflow is: filter by tag, token, or protocol, select all on the filtered page, then act. Here is what each action does:

The matching API call

Every bulk action in the UI calls the same REST endpoint. You can call it directly from scripts, CI pipelines, or any orchestration layer:

POST /api/v1/proxies/bulk
Authorization: Bearer $KEY
Content-Type: application/json

{
  "action": "stop",
  "ids": ["px_8x2q...", "px_3KZL...", "px_NPJX..."]
}

Valid action values mirror the panel bar: start, stop, rotate, delete, and set_protocol. The last one takes an extra body field to name the target protocol:

{
  "action": "set_protocol",
  "protocol": "socks5",
  "ids": ["px_8x2q...", "px_3KZL..."]
}

The response is a per-id result map, not a single pass/fail. This is intentional: in a fleet of two hundred, you almost never want the entire batch to abort because one token was offline.

{
  "results": {
    "px_8x2q...": { "ok": true,  "state": "stopped" },
    "px_3KZL...": { "ok": false, "error": "token_offline" },
    "px_NPJX...": { "ok": true,  "state": "stopped" }
  },
  "summary": { "ok": 2, "failed": 1 }
}

A provisioning script should loop over results, collect the failed ids, and retry them once the offline mobile devices reconnect — rather than re-sending the full list.

Limits and what happens on the edge

One call accepts up to 200 ids. Larger fleets should be chunked client-side. The endpoint is fast but not streaming, and a very large single call can time out before the server has queued all orders on a slow connection. The 200-cap matches the panel's "select all on page" page size, so the two surfaces stay in sync without any client-side logic.

The endpoint is rate-limited to 5 calls per minute per personal API key. Customer API tokens — the scoped credentials you issue to reseller clients — cannot call /bulk at all. Bulk control is an account-owner primitive; customers interact with their assigned proxies through their own credentials. For the full distinction, read personal vs customer tokens.

Bulk stops are immediate — the edge severs the listener synchronously. Bulk starts are async — the endpoint returns once the orders are queued, but the listeners take 2–5 seconds each to actually bind on the edge server. If your script must wait for live confirmation, poll /api/v1/proxies?ids=... until all states flip to running.

Partial failure: the most common cause and the right fix

The single most common reason a row returns ok: false is the token being offline. A paired phone that has lost its connection cannot receive a rotation hint or complete a protocol change. The bulk endpoint surfaces this per-id rather than failing the whole call. The right response is to filter the failures by error type: token_offline items are safe to retry later; not_found items indicate stale ids that should be removed from your fleet manifest.

For pools that must stay available even when individual devices drop, consider automatic failover and token groups — the round-robin selection ensures traffic is never sent to a device that is not currently connected.

Integrating bulk operations into a workflow

The most effective pattern for automated fleet management is a three-step loop. First, retrieve all proxy ids using a list call to the API. Second, filter or group them by the criteria relevant to your task — protocol, tag, token, or last-seen time. Third, send the filtered ids to /bulk in pages of up to 200. Repeat the third step until no ids remain.

For programmatic provisioning — creating a fleet from scratch rather than operating an existing one — see creating tunnels programmatically with Python, which complements this guide end to end. To understand per-client controls like quota limits and thread limits, those are set at the client level, not via the bulk endpoint — they remain in place regardless of start/stop cycles.

Protocol choices at scale

When deciding which protocol to use across a large fleet, the set_protocol action makes it easy to experiment. HTTP and HTTPS are the right default for browser-driven scraping and most API clients. SOCKS5 is better when you need raw TCP forwarding — non-HTTP traffic, custom tooling, or any client that negotiates the protocol itself. You can read the full trade-offs in HTTP vs SOCKS5: which to pick. Because a bulk protocol change keeps the same port, you can switch a batch without updating any client configuration that references the endpoint — only the wire protocol changes at the proxy layer.

Get started

If you have not yet talked to the API, start with your first REST call to obtain your personal key and understand authentication. Once you are managing a meaningful fleet, the bulk endpoint is the single fastest way to operate it. Create an account to get access to the full panel and API, or explore the full feature set to see what else is available alongside bulk operations.