# What IP-Intelligence APIs Actually See: We Checked Our Own 4G/5G Exit IPs Live

> Markdown version of [the article](https://simplyproxies.com/blog/what-ip-intelligence-apis-see-mobile-exit-ips.html), kept in sync with it.
> Published 17 September 2026 by Simply Proxies.

Every mobile proxy provider makes the same core claim: your requests exit through real devices on real mobile networks, so target sites see the same class of IP address as an ordinary phone user. It is a claim you can verify in about sixty seconds, with free public APIs and one curl command. No account, no dashboard screenshot, no trust required.

We run a UK mobile proxy service, so we did the obvious thing: we pointed three free IP-intelligence APIs at our own exit IPs and pasted every response below, unedited. The same test works against any provider you currently use or are evaluating. If the "mobile" in your mobile proxy is real, these APIs will say so. If it is not, they will say that too.

## The three APIs we asked

| API | Free tier | What it reports |
|-----|-----------|-----------------|
| ip-api.com | No key, 45 requests/minute, HTTP only | `mobile`, `proxy` and `hosting` booleans, ISP, organisation, ASN |
| ipwho.is | No key | Geolocation plus `connection.isp` and `connection.org` (the carrier view) |
| api.ipapi.is | No key, 10 fields per response when unauthenticated | WHOIS-first company and ASN data; the full response adds datacenter, VPN and abuse flags |

Each API builds its database differently: registry (WHOIS) records, BGP announcements, honeypots and threat feeds. That is the point. If one classifies an IP as mobile by accident, three independent classifications agreeing is a much stronger signal.

## The setup

Every command below ran on 17 September 2026 with curl 8.5.0 against the public HTTPS proxy endpoint. Substitute your own credentials (shown here as `USER:PASS`) from whichever provider's dashboard you are testing:

```bash
curl -sS -x "https://USER:PASS@proxy.simplyproxies.com:6889" \
  "http://ip-api.com/json/?fields=status,country,city,isp,org,as,mobile,proxy,hosting,query"
```

The response came back in well under a second:

```json
{"status":"success","country":"United Kingdom","city":"Leyton","isp":"British Telecommunications PLC","org":"EE Limited","as":"AS2856 British Telecommunications Limited","mobile":true,"proxy":false,"hosting":false,"query":"31.94.6.145"}
```

## Result 1: the classification

Three booleans in the middle of that response are the whole story:

- `mobile: true`: the address belongs to a cellular network, the same registration class as any UK smartphone on EE.
- `hosting: false`: the address is not in a datacenter, cloud or colocation range.
- `proxy: false`: the address did not appear in ip-api's proxy, VPN or Tor exit lists at query time.

The `org` and `as` fields back it up: `EE Limited`, `AS2856`. That is a consumer mobile carrier's autonomous system, not a hosting company's. This is what a genuine mobile exit looks like to the databases that anti-bot vendors, ad platforms and fraud-scoring systems license and build on.

## Result 2: the carrier view

ipwho.is returns geolocation plus the connection's ISP and organisation. Same proxy, new request:

```json
{
    "ip": "92.40.171.95",
    "success": true,
    "country": "United Kingdom",
    "country_code": "GB",
    "city": "London",
    "connection": {
        "asn": 206067,
        "org": "Mobile Broadband Service",
        "isp": "Hutchison 3G UK Limited",
        "domain": "talksolution.co.uk"
    }
}
```

(Response trimmed for width; the full payload also includes continent, flag, calling code and timezone objects.)

This exit landed on Three: `Hutchison 3G UK Limited` is Three's operating company. Across all the requests in this test session, our exits spanned three UK carrier networks (EE, Three and Vodafone), which matters because carrier diversity is what makes a mobile pool look like a population of real subscribers rather than one network's worth of infra.

The third API, ipapi.is, returned this for another exit:

```json
{"ip":"31.94.13.3","is_bogon":false,"company":"EE MOBILE","asn":"AS2856","city":"Royton","region":"England","country":"United Kingdom","lat":53.5651,"lon":-2.12267,"timezone":"Europe/London","docs":"https://ipapi.is/free-tier.html"}
```

Note the `company` value: `EE MOBILE`, straight from WHOIS records. Unauthenticated requests get this 10-field response; with a free account ipapi.is also returns `is_datacenter`, `is_vpn`, `is_abuser` and similar flags.

The `lat`/`lon` values are the database's estimate for the IP's registered network, not a device GPS fix: the same EE range resolved to Leyton (ip-api) and Royton (ipapi.is), two cities over 150 miles apart. Nothing on a device reports its location through the proxy.

## Result 3: rotation

Bare requests rotate across the pool. Three requests in a loop:

```bash
for i in 1 2 3; do
  curl -sS -x "https://USER:PASS@proxy.simplyproxies.com:6889" \
    "http://ip-api.com/json/?fields=query,mobile,isp"
done
```

```json
{"isp":"British Telecommunications PLC","mobile":true,"query":"31.94.32.113"}
{"isp":"British Telecommunications PLC","mobile":true,"query":"31.94.14.160"}
{"isp":"Hutchison 3G UK Ltd","mobile":true,"query":"92.40.171.95"}
```

Three requests, three different exit IPs, two carriers, `mobile: true` every time. This is the behaviour you want for scraping and polling workloads: per-request IP diversity without per-request setup, so per-IP rate buckets and IP-based blocklists keep missing you.

## Result 4: sticky sessions

Some jobs need the opposite: the same exit IP for a while. Appending `-session-<id>` to the proxy username pins consecutive connections to one device for a sliding window (2 hours by default, 5 minutes to 12 hours selectable). The syntax is documented in [our proxy docs](/docs#sticky).

Two HTTPS requests with the same session id:

```json
{"mobile":true,"query":"148.252.165.71"}
{"mobile":true,"query":"148.252.165.71"}
```

The same IP, on Vodafone's network this time. The equivalent on the SOCKS5 port:

```bash
curl -sS -x "socks5h://USER-session-apidemo:PASS@proxy.simplyproxies.com:6890" \
  "http://ip-api.com/json/?fields=query,mobile"
```

```json
{"mobile":true,"query":"31.94.14.160"}
{"mobile":true,"query":"31.94.14.160"}
```

One honest footnote: a session id pins within a protocol. The HTTPS port and the SOCKS5 port keep their own pinning state, so the same id does not guarantee the same device across both ports in the same window.

## The control: what a datacenter IP looks like

For contrast, the same two APIs queried from a datacenter server with no proxy at all:

```json
{"status":"success","country":"France","city":"Roubaix","isp":"OVH SAS","org":"OVH","as":"AS16276 OVH SAS","mobile":false,"proxy":false,"hosting":true,"query":"51.255.200.116"}
```

```json
{"ip":"51.255.200.116","is_bogon":false,"company":"OVH SAS","asn":"AS16276","city":"Roubaix","region":"Hauts-de-France","country":"France","timezone":"Europe/Paris"}
```

`mobile: false`, `hosting: true`, company `OVH SAS`. This is what a bare VPS, a typical VPN endpoint and most cheap "datacenter proxies" look like to the exact same databases. Many bot walls key on that one boolean before they ever look at your headers or fingerprints.

## What this test does and does not prove

We are the operator being tested, so the limits matter more than the highlights:

- **Point in time.** IP intelligence is continuously updated. `proxy: false` on our exits today is an observation from a live query, not a permanent guarantee, and any IP's standing can change as databases refresh.
- **Network type is not reputation.** `mobile: true` says the address belongs to a carrier network. Because carriers run CGNAT, thousands of ordinary subscribers share each mobile IP, which is precisely what makes mobile ranges awkward to blanket-block, but any individual IP can still carry abuse history from whoever used it before you.
- **No database sees everything.** ipapi.is states in its own FAQ that its proxy and VPN detection "does not detect residential proxies or unknown VPN providers". Classification is evidence, not omniscience.
- **Single vantage, single day.** Every command above is reproducible. Run them against your provider, from your network, today, and trust the responses over any marketing claim, including ours.

## Check any provider in 60 seconds

1. **Classification:** `curl "http://ip-api.com/json/?fields=mobile,proxy,hosting,org,query"` through the proxy. You want `mobile: true`, `hosting: false`, and a carrier-named organisation.
2. **Carrier and country:** `curl https://ipwho.is/` through the proxy. The ISP should be a mobile operator and the country should match what the provider promised.
3. **Rotation or stickiness:** run the first command three times. Either you get different IPs (rotating pool) or, with a session id, the same IP on purpose. Getting one IP with no session suffix means you are pinned whether you asked or not.
4. **Baseline contrast:** run the same commands without the proxy and compare. That is what your scraper looked like before.

If step 1 returns `mobile: false` or `hosting: true`, you are not on a mobile exit, whatever the plan is called.

## Summary

- Three independent, free IP-intelligence APIs classified our UK 4G/5G proxy exits as `mobile: true`, `hosting: false`, with consumer carrier ASNs (EE, Three, Vodafone) as the organisation.
- Bare requests rotated across three different exit IPs in three requests; `-session-<id>` pinned two consecutive requests to one IP on both the HTTPS and SOCKS5 ports.
- A datacenter control IP returned `mobile: false`, `hosting: true` from the same APIs, which is the classification most bot walls act on.
- The test is four curl commands and works against any provider. Run it yourself and prefer live responses over claims, ours included.

Last verified 17 September 2026