Why US numbers cannot be split into mobile and landline

The North American plan hands mobiles and landlines the same blocks. What a number can still tell you, what the block holder proves, and what porting breaks.

Ask most phone APIs whether +1 415 555 0142 is a mobile and you get a confident answer. Ask where the answer came from and the confidence fades. In the North American Numbering Plan, the plan that covers the United States, Canada and most of the Caribbean, the number itself does not say. This guide explains why, what the open data can still prove, and how Spaw reports the difference so you never build a policy on a guess.

The plan does not separate them

Every North American number is an area code, a three-digit central office code and four subscriber digits. The plan hands out numbers to carriers in 10,000-number blocks, one per central office code, and since the late 1990s in 1,000-number thousands-blocks inside pooled codes. NANPA, the plan's administrator, describes the mechanism on its central office codes and thousands-blocks page (https://www.nanpa.com/numbering/co-codesthousands-blocks, accessed 5 September 2026).

What the plan never did is reserve ranges for a service type. A block goes to whichever carrier applied for numbers in that rate centre, and a wireless carrier's block sits next to a cable company's block with nothing in the digits to tell them apart. Contrast the United Kingdom, where Ofcom's numbering scheme sets aside the 07 range for mobile services and publishes the allocation of every block (https://www.ofcom.org.uk/phones-and-broadband/phone-numbers/numbering-data, accessed 5 September 2026). A UK number wearing 07 is a mobile number by construction. A US number wearing 415 is a San Francisco number and nothing more.

That is why libphonenumber, the numbering metadata behind Android and behind Spaw, answers fixed_line_or_mobile for every geographic North American number. It is not a gap in the data. It is the honest reading of the plan.

What the block holder can prove

The plan does not encode the service type, but the regulator knows who holds each block. NANPA publishes a daily report of every assigned central office code with the holder's operating company number and name (https://www.nanpa.com/reports/co-code-reports, accessed 5 September 2026), and the Canadian Numbering Administrator publishes the same table for Canada (https://www.cnac.ca/co_codes/co_code_status.htm, accessed 5 September 2026). Spaw syncs both weekly. The report Spaw synced on 4 September 2026 listed 204,808 assigned codes across the fifty states, the District of Columbia and the territories.

A holder named "Cellco Partnership dba Verizon Wireless" or "T-Mobile USA, Inc." allocates its blocks to handsets. A holder named "Bandwidth.com CLEC" or "Onvoy" is a wholesaler whose numbers back apps, softphones and SMS-receiving services. When the holder's name settles the question, Spaw settles line_type with it and says so:

"line_type": "mobile",
"line_type_source": "block_allocation",
"carrier": "CELLCO PARTNERSHIP DBA VERIZON WIRELESS - NJ",
"carrier_source": "block_allocation",
"block_status": "allocated"

When the holder's name settles nothing, because the holder is a regional telephone company that sells both landlines and mobile service, or a name nobody can classify, the answer stays fixed_line_or_mobile with line_type_source: "numbering_plan". Spaw never promotes a guess to a fact. In the tables synced for this guide, roughly a quarter of assigned US codes belong to holders whose name marks them as wireless carriers and about a tenth to wholesalers; the rest keep the plan's answer.

Pooling adds one more caveat. In a pooled code, the thousands-blocks inside it can belong to different carriers, while the public report names the holder of the code as a whole. For most codes the two agree; for some, the block-level holder differs from the code holder. Spaw reads the code-level report today and labels the answer accordingly.

Porting breaks the link between block and carrier

Number portability lets a subscriber keep a number while changing carrier, and it lets a landline number move to a mobile carrier and back. The block does not move with it. A number ported from a cable company to a wireless carrier still sits in the cable company's block, and every allocation table on earth will still list the cable company as its holder.

This is the reason Spaw reports the block holder as carrier with the note that it is the original allocation, and why line_type_source: "block_allocation" means "the block holder is a wireless carrier", not "this handset is on a wireless network today". For a number that was ported after it was allocated, both fields can be stale. Nothing in open data corrects that. Only a query into the carrier networks, the HLR or number-portability lookup that Spaw exposes behind hlr: true, can say who serves the number now and whether it was ported, and it is reported in its own fields, ported and current_carrier, so the two sources are never blended.

What Spaw claims, and what it does not

line_type is the numbering plan's type, except when a North American block holder settles it. line_type_source always says which.
carrier is the block holder as the regulator lists it, or the prefix metadata where no table covers the region. Both are the original allocation.
Neither field is port-aware. A confident mobile-or-landline answer for a ported number is a guess, and Spaw does not make it.
valid: true means assignable under the plan and, where a table is installed, inside an allocated block. It does not mean a handset is switched on.

How to use the answer

Branch on the pair, not on line_type alone. Treat mobile with block_allocation as a strong signal that an SMS will arrive, treat voip with block_allocation as a reason to look at is_virtual and the risk score before sending a one-time code, and treat fixed_line_or_mobile as unknown rather than as a landline. A signup form that rejects every fixed_line_or_mobile number would reject a large share of real US mobiles.

For a CRM you clean once, the block holder is a good enough sort key: group by carrier and line_type_source, and let the sales team see which contacts were in wireless blocks. For a workflow that must know whether a text message will land, budget for the live check on the numbers that matter and keep the free answer for the rest.

What to do next

Read the phone intelligence guide for every field and where it comes from.
Check the request and response on the POST /api/v1/phone reference.
See what the same tables say when nobody holds the block in what an unassigned block means.
Turn the flags into a signup policy with stop OTP abuse with block data and disposable numbers.