DEV Community: Singapore Mobile Proxy

Reselling mobile proxies through an API without paying for ports nobody uses (Python)

Xavier Fok — Mon, 28 Sep 2026 04:49:20 +0000

If you resell proxies, the expensive bug isn't a failed provision. It's a port that keeps billing after your customer has left.

We run Singapore mobile proxies on physical SIMs (one modem per port), and in September we opened a reseller API on top of them. This post walks through wiring it into a shop in Python: create a port when an order is paid, extend it on renewal, cancel it on churn, and run a nightly job that catches the ports your own database forgot about. The same shape works for most proxy APIs, so skip the Singapore bits if they don't apply to you.

All the code is in this repo, with a Node version too.

The client

The API takes one header, x-api-key, and JSON bodies. Errors come back as {"detail": {"message": ...}}, sometimes with a code. Wrap that once so the rest of your shop can except on status codes:

import requests

BASE = "https://singaporemobileproxy.com/api/reseller/v1"


class ResellerAPIError(Exception):
    def __init__(self, status, detail):
        self.status = status
        self.detail = detail if isinstance(detail, dict) else {"message": str(detail)}
        super().__init__(f"{status}: {self.detail.get('message')}")


class Reseller:
    def __init__(self, api_key, timeout=60):
        self.s = requests.Session()
        self.s.headers["x-api-key"] = api_key
        self.timeout = timeout

    def _call(self, method, path, **body):
        kw = {"timeout": self.timeout}
        if method == "POST":
            kw["json"] = {k: v for k, v in body.items() if v is not None}
        elif body:
            kw["params"] = body
        r = self.s.request(method, BASE + path, **kw)
        if r.status_code >= 400:
            try:
                detail = r.json().get("detail")
            except ValueError:
                detail = r.text
            raise ResellerAPIError(r.status_code, detail)
        return r.json()

Timeout is 60 seconds, not 10. Creating a port means configuring a real modem, and a short client timeout is how you end up with a port that exists on our side and not on yours.

Order paid: create the port

def fulfil(api, order):
    try:
        res = api._call("POST", "/ports",
                        bandwidth_gb=order.tier_gb,   # 200, 500 or 1000
                        days=order.days,              # 30 for a monthly plan
                        telco=order.carrier,          # "singtel", "m1" or None
                        label=f"order-{order.id}")
    except ResellerAPIError as e:
        if e.status == 402:   # past your credit limit; the message says how many fit
            return order.hold("reseller credit limit: " + e.detail["message"])
        if e.status == 503:   # no free modem right now, nothing billed
            return order.retry_in(minutes=15)
        raise
    port = res["ports"][0]
    order.attach(port_id=port["id"], http=port["http"], socks5=port["socks5"],
                 rotation_link=port["rotation_link"])

Three things in there matter more than they look.

days=order.days sets an end date. The port runs through that date (Singapore time) and is removed at 00:05 the next morning. Without it the port runs until you cancel, which is what you want for a customer on auto-renew and exactly what you don't want for a one-off 7-day order.

label is your order id. When something goes wrong, GET /ports hands you back your own ids, so you're never matching ports to orders by hostname.

503 means nothing was created and nothing was billed. Retrying is safe. The one I'd treat carefully is a timeout on your side, because then you don't know. Don't blindly retry that. Run the reconcile below first.

Before a big order, check headroom:

acct = api._call("GET", "/account")
print(acct["available_usd"], "of", acct["credit_limit_usd"], "left this month")

available_usd already subtracts what your live ports will still bill until month end, so if it says a port fits, it fits.

Renewal and churn

def renew(api, order, days=30):
    api._call("POST", f"/ports/{order.port_id}/end-date", add_days=days)

def churn(api, order):
    api._call("POST", f"/ports/{order.port_id}/cancel")

add_days extends from the current end date, or from today if the port has none. The cancel only marks the port cancelled after the proxy server confirms the removal. If it can't confirm, you get a 502 and the port is still live and still billing, so a failed cancel has to go back on your queue, not into a log file nobody reads.

Rotation

Your customer gets rotation_link and can hit it themselves. If you'd rather keep that server-side:

api._call("POST", f"/ports/{port_id}/rotate")            # new IP now, 5 min cooldown per port
api._call("POST", f"/ports/{port_id}/auto-rotate", minutes=30)   # 0 turns it off

A rotation takes about 20 seconds on our modems. I check the egress before and after with the proxy itself rather than trusting the 200:

def egress_ip(port):
    proxy = f"http://{port['login']}:{port['password']}@{port['host']}:{port['http_port']}"
    return requests.get("https://api.ipify.org?format=json",
                        proxies={"http": proxy, "https": proxy}, timeout=20).json()["ip"]

The nightly reconcile

This is the job that saves money. Once a night, list every live port and compare against your orders:

def reconcile(api, db):
    live = api._call("GET", "/ports", status="live")["ports"]
    for p in live:
        order = db.order_for_label(p["label"])
        if order is None or order.status in ("cancelled", "refunded"):
            print("orphan, still billing", p["daily_cost_usd"], "/day:", p["label"], p["id"])
            # cancel it, or flag it for a human if you're not ready to auto-cancel
        elif order.port_id != p["id"]:
            print("order points at a different port:", order.id, p["id"])
    live_ids = {p["id"] for p in live}
    for order in db.active_orders():
        if order.port_id not in live_ids:
            print("customer paying for a port that isn't live:", order.id)

Both directions matter. The first loop finds ports you pay for and nobody uses. The second finds customers paying you for something that isn't there, which is the one that turns into a chargeback.

Start it read-only. I'd run it for a week printing, not cancelling, before letting it touch anything.

What I haven't covered

The modem-trial endpoints (swap-options and swap-trial) let you move a customer's port to a different modem for 10 minutes and keep or revert it. That's a post of its own, and the rules around cross-server moves (they change host, port and login) are easy to get wrong. The reference spells them out.

StarHub isn't on sale right now, so telco takes singtel or m1. GET /plans returns free stock per carrier, and it's worth showing that in your own checkout rather than selling a carrier that's out.

Wholesale prices and how to apply are on the reseller page.

IP Geolocation Isn't Enough for Regional App Testing

Xavier Fok — Tue, 22 Sep 2026 08:38:08 +0000

You point your test at a proxy in the right country, the app store shows the right storefront, and you ship. Then support tickets come in from real users on actual carrier networks seeing a different payment flow than what you tested.

I run a mobile proxy network on real SIM cards in Singapore, and this came out of running it. The gap usually isn't the IP's country. It's the IP's ASN classification. Platforms that do regional testing at scale check whether an IP belongs to a "hosting," "residential," or "mobile" range, and a VPN or datacenter exit almost always lands in "hosting" no matter what country it geolocates to.

Here's a script that checks that classification directly instead of trusting the country field alone:

import os
import requests

PROXY_URL = os.environ["PROXY_URL"]  # e.g. socks5h://user:pass@host:port

session = requests.Session()
session.proxies.update({"http": PROXY_URL, "https": PROXY_URL})
session.headers.update({"Accept-Language": "en-SG,en;q=0.9"})

ip_data = session.get("https://ipapi.co/json/", timeout=15).json()
print("IP:", ip_data.get("ip"))
print("Org:", ip_data.get("org"))
print("Mobile:", ip_data.get("mobile", "not reported"))

the country check passes, the classification doesn't

When your app makes a request through a proxy, the server on the other end doesn't just read the IP's country. It reads the IP's ASN, and IP intelligence providers classify most ASN blocks as roughly "hosting," "residential," or "mobile." A VPN exit or a datacenter proxy in the right country still resolves to a "hosting" ASN, because that's genuinely what it is. A consumer SIM issued by an actual carrier resolves to "mobile," because that's genuinely what it is too.

This matters because platforms that maintain IP reputation scoring (which by now includes most app stores, ad networks, and payment processors) use that classification as a signal independent of the country field. Your test session can show the correct storefront and still get routed through a different code path than a real subscriber would see, because the country check passed but the carrier check didn't. You won't notice in testing. You'll notice when a support ticket describes a payment flow you never saw.

reading the ASN instead of the flag

The script above checks org and mobile from an IP intelligence API. That catches the obvious case: a datacenter IP shows a hosting company in org and nothing in mobile, a carrier IP shows the carrier's registered ASN name and mobile: true. A few fields worth reading closely in the response:

org: the ASN's registered organization; you want a carrier name, not a hosting company
mobile: a boolean some providers report separately from org, worth checking even when org looks right
country: the field everyone checks first and the one that matters least here

If you need to go further and confirm which carrier specifically, not just mobile-or-not, checking a proxy's ASN before you trust it covers the WHOIS lookup in more detail than fits here.

don't stop at the storefront

A clean ASN doesn't guarantee the rest of the flow behaves correctly. Extend the same session to check what you actually care about:

# continues using `session` from above

store_resp = session.get(
    "https://play.google.com/store/apps",
    timeout=15,
    allow_redirects=True,
)
print("store url:", store_resp.url)

cdn_resp = session.get(os.environ["CDN_URL"], timeout=15)
geo_headers = ["cf-ipcountry", "x-amz-cf-pop", "x-geo", "x-country"]
for key, value in cdn_resp.headers.items():
    if key.lower() in geo_headers:
        print(f"{key}: {value}")

The storefront URL tells you which region the app store resolved you into. The CDN headers tell you which edge and geo-routing bucket actually served the response, which matters if your app pulls region-specific assets or feature flags from a CDN rather than from the store itself.

For flows that involve login, cart, or checkout, keep the same session and the same proxy connection for every step. A proxy that rotates IP on every new connection hands you a different IP mid-flow, breaks session cookies, and sometimes trips fraud checks that a real single-session user would never hit.

the DNS leak that undoes all of it

Worth checking explicitly: if you're using SOCKS5, make sure DNS resolution happens through the proxy, not locally. In requests, that's the difference between socks5h:// and socks5://: the h routes the hostname lookup through the tunnel. Without it, your traffic exits from the right IP but the DNS query that preceded it left from your real location. Some platforms cross-reference the two and flag the mismatch even when the HTTP request itself looks clean.

what actually bit us running this on real hardware

Real carrier IPs sit behind carrier-grade NAT, and carriers reassign addresses on their own schedule as part of normal CGNAT operation. That's standard, documented behavior, not a fault in any particular proxy. The practical effect: a sticky session that's supposed to hold one IP for the length of a test can still get reassigned mid-flow if the test runs long enough, because the reassignment happens at the carrier level, underneath the proxy layer entirely. We've had multi-hour automated test runs lose their IP partway through for exactly this reason. If you're running anything longer than a few minutes against a mobile carrier IP, build in a check that confirms the IP hasn't changed before you trust a multi-step result.

the tradeoff you're actually making

Datacenter proxies are faster. Sub-100ms round trips are normal. A real SIM going through an actual carrier network typically lands somewhere between 80 and 350ms depending on signal conditions at the moment you test. For geo-testing, that difference almost never matters, because you're checking correctness of a code path, not throughput. For a high-volume automated pipeline making thousands of requests an hour, it might, and that's worth weighing against how accurately the test needs to reflect what a real subscriber sees.

If your platform makes any decision (payment method, feature flag, content variant) based on whether a connection looks like a real mobile subscriber, testing that decision from a hosting-classified IP will tell you the storefront works and nothing about whether the decision itself is correct.