How to rotate mobile proxy IPs on demand: the rotation api explained

I run a hardware mobile proxy farm in Singapore. Real phones, real sim cards from Singtel, M1, and StarHub. So when I talk about rotating a mobile ip, I do not mean relabeling a datacenter address. I mean a real phone renegotiating its session with the carrier and coming back with a fresh ip from that carrier’s own range. Once you see rotation that way, the rest of this gets simple.

There are two ways a mobile ip rotates, and mixing them up is where most jobs quietly break.

Timed carrier rotation

The first way is timed carrier rotation. The ip changes on the carrier schedule, on its own, with nothing from you. Every real phone gets reassigned an address as the network manages its pool, and your proxy port just rides along. Over minutes or hours the exit ip drifts to a new one. It is steady and hands off, and it is fine for slow background work where you do not care exactly when the ip turns over. What it cannot do is react. You cannot tell timed rotation to change right now because a target just blocked you.

On demand rotation through a rotation url

The second way is on demand rotation, and that is the one this post is really about. You hit an endpoint, a rotation url tied to your port, and the gateway forces the modem behind it to grab a fresh carrier ip on the spot. No waiting for a schedule. At a high level the flow is: you send a request to the rotation url, usually carrying a token that proves the port is yours, the gateway tells the modem to drop and rebuild its carrier session, the carrier hands it a new ip, and your next request goes out on that address.

curl -X POST "https://gateway.example/rotate/<your-port-token>"

The detail that keeps this sane is that you never talk to the raw ip. You always connect to the same stable gateway host and port, and the ip behind it is what moves. That is why you can rotate all day and your connection string never changes. If you ever catch yourself hardcoding the raw mobile ip, stop, because the whole design assumes it is temporary.

When to rotate

Timing matters more than frequency. People obsess over rotating often when what actually protects them is rotating at the right moments. The good triggers:

• After you finish a task. The work on that ip is done, so get a clean one before the next unrelated job starts.
• After a soft block. If a target starts feeding you captchas or throttling an ip that was fine a minute ago, that ip is burned for that target. This is the single most useful trigger, and the reason on demand rotation exists.
• Between account sessions. If you run several accounts, each should sit on its own clean ip. Never let two of your accounts go out back to back on the same exit ip, because that footprint links them together.

When not to rotate

Never rotate in the middle of a login. Never rotate in the middle of a checkout. Think about what the site sees: you begin a login from one ip, and between the password and the second factor your address jumps to a different one. That looks like a session being hijacked mid flight, and it is an instant flag. Anything that has to feel like one continuous person, you finish on a single sticky ip first, then rotate after.

The loop: work, rotate, verify

The pattern I actually run is easy to say and easy to get wrong. Do the whole unit of work on one sticky ip. When the task is genuinely done, call rotate. Then confirm the exit ip really changed before you continue. That step is not optional, because rotation is neither instant nor guaranteed. The modem takes a few seconds to renegotiate, and once in a while it comes back on the same ip. Fire your next task too early and you may be running on the old burned address without knowing.

So the loop is: work on the sticky ip, call the rotation url, wait a few seconds, then check your exit ip back through the same port. If it reads the same as before, wait and check again instead of charging ahead. Only once you see a genuinely different ip do you let the next task start.

While you check, confirm one more thing in the same breath: that the new ip is still on a carrier asn. Look the address up and make sure the network owner is the mobile carrier, Singtel or M1 or StarHub, not some datacenter range that slipped into the path. A real mobile ip always traces back to a carrier. If it does not, you would much rather catch that in your own check than have a target catch it for you.

Respect the rotation rate limits

One rule keeps the whole setup healthy over time: respect the rotation rate limits. A real phone does not enjoy being told to renegotiate its carrier session every few seconds, and the carrier likes it even less. Space your rotations out, something on the order of a couple of minutes between calls on the same port rather than firing on every request. Rotate when you have a reason, after a task or a soft block, not on a frantic timer. Treat the line like the real device it is and it stays fast and clean.

Do all of this and rotation gets boring in the best way. You work on a stable sticky ip, rotate on real signals, verify every change, and stay on clean carrier ips that sites treat like any other phone.

Try it on real Singapore mobile ips

If you want this running on genuine Singapore mobile ips, that is what I sell from my own farm: real sg carrier ips, sticky sessions so a login holds on one address, on demand rotation through a rotation url, and dns that routes through the tunnel so you are not leaking your real location. Start a free trial of Singapore Mobile Proxy and use code YT30 for thirty percent off your first month.

Get new guides and videos first — join the Telegram channel.