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 National Telephone Numbering Plan sets aside 071 to 075 and 077 to 079 for mobile services (version with effect from 22 April 2025, https://www.ofcom.org.uk/siteassets/resources/documents/phones-telecoms-and-internet/information-for-industry/numbering/other/national-numbering-plan.pdf, accessed 27 September 2026) and Ofcom publishes block-by-block allocation tables (https://www.ofcom.org.uk/phones-and-broadband/phone-numbers/numbering-data, accessed 5 September 2026). A UK number starting 071 to 075 or 077 to 079 is a mobile number by construction; the rest of 07 is personal numbering (070) and radiopaging (076, apart from the Isle of Man's 07624), as UK number ranges in a phone lookup sets out range by range. 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 NANPA's daily and the Canadian table weekly, and what each table holds today is summarised on the phone facts pages for the United States and Canada. NANPA's code report of 26 September 2026 lists 198,523 allocated codes across the fifty states, the District of Columbia and the territories, 197,177 of them in the states and the District of Columbia; the 6,504 codes it marks unavailable, such as the N11 and 555 service codes, are not counted.
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 NANPA's code report of 26 September 2026, 60,319 of the 198,523 allocated codes (30%) belonged to holders on Spaw's wireless list and 28,638 (14%) to holders on its VoIP list, lower bounds because a holder not on the list settles nothing; the rest keep the plan's answer at code level, unless the number's own thousands-block settles it (below).
Pooling adds one more caveat: in a pooled US code the blocks of a thousand inside it can belong to other carriers than the code's holder, so carrier, carrier_code and a line_type settled by the holder describe the holder of the number's own block where NANPA's thousands-block report lists it, as number pooling: why a US code's holder is often not your block's holder explains with the figures and the exceptions.
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, an HLR or number-portability lookup, can say who serves the number now and whether it was ported. The API reserves that query behind hlr: true and reports it in its own fields, ported and current_carrier, so the two sources are never blended. The live carrier-network check (hlr: true) is not enabled on the service: hlr_checked answers false and nothing extra is charged.
What Spaw claims, and what it does not
line_typeis the numbering plan's type, except when a North American block holder settles it.line_type_sourcealways says which.carrieris 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: truemeans 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, no open table can say, and the live check is not enabled on the service. Send, then report the delivery receipt your SMS provider returns through POST /api/v1/phone/feedback: a number that failed scores higher on your own next lookup, and one that failed for good lands on your suppression list, which batch and bulk runs answer free.
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.
- See the calling code, an example number of each line type and the regulator's table for any country in phone facts by country.