Three different questions hide inside the word validation. One asks whether the number is shaped like a real number. One asks whether a network answers for it at all. One asks whether the person you are talking to holds it. Each needs a different check. Each leaves something unknown.
What can a format check tell you?
That the number belongs to a range a carrier is allowed to assign.
Google's libphonenumber treats a range as valid when carriers are free to hand its numbers to subscribers. Its FAQ:
A valid number range is one from which numbers can be freely assigned by carriers to users.
Validity says nothing about whether a particular number has been handed out or answers. The same page:
Do not rely on libphonenumber to determine whether numbers are currently assigned to a specific user and reachable.
So a format check answers a question about the numbering plan. It says nothing about whether the range has been assigned to anyone, and nothing about whether a phone rings.
Dialing is not a substitute test either. The FAQ gives two reasons a call can connect to a number that is not valid. Some countries ignore extra digits on the end, so 1800 MICROSOFT reaches a shorter number. During a renumbering, some operators keep old numbers working after they have stopped working generally.
What does a network lookup add?
The parts of the answer that only a network holds.
A lookup asks carrier and number-intelligence sources about a specific number rather than about its range. That moves several questions from unknown to answered:
| Check | What it returns | What it still leaves open |
|---|---|---|
| Format | The number parses and sits in an assignable range | Whether the range is assigned to anyone |
| Line type | Whether the number is mobile, fixed line, VoIP, toll-free or machine-to-machine | What service the range is allocated to at finer precision |
| Serving network | The network answering for the number now, and the one that issued it | Whether a handset is switched on |
| Porting state | When the number last moved network | Nothing about the subscriber |
| Presence | Whether the number is registered and able to receive traffic right now | Who is holding the handset |
| Possession | Nothing. A lookup never asks the person | Whether your user controls the number |
The last row is the one that matters for a signup flow. No lookup establishes possession, because a lookup never involves the person.
What only a verification challenge can prove?
That whoever is in your flow can receive traffic at that number.
The libphonenumber FAQ treats a challenge as the only workable answer, because numbering practice differs too much between countries for anything else to settle it:
This is not technically feasible without such a verification step given the complicated international world we live in, with varying standardization practices in different regions.
Sending a code and accepting it back is therefore a different kind of check from the two above. It costs a message and a round trip. It is also the only one that ties the number to the person in front of you. What does OTP mean covers the code itself, and the Verify guide covers running the challenge.
How do I read a check nobody could answer?
As unknown, which is not the same as no.
A number whose presence could not be determined is not an unreachable number. Treating the two alike blocks customers whose networks simply did not answer.
Bird keeps them apart in the response. Each property you request reports its own status:
ok: the property was answered and its value is present.unavailable: no answer arrived, so the block isnull.inconclusive: an answer arrived that does not resolve the property.
Only ok carries a value. A presence block with status: ok and reachable: false is a real negative, because the network answered and reported the number as unreachable.
So branch on ok first. Treat everything else as not answered. The status vocabulary is an open enum, so an unrecognized value is a future status rather than an error. Branching on ok therefore stays correct as the vocabulary grows.
How do I look one up on Bird?
Send the number to the lookup endpoint. Read the blocks you asked for.
POST /v1/lookup/phone-number takes a phone_number and an optional type array. Every lookup returns the serving and issuing networks, the porting state, the country and the line type. The type array adds classification, porting, presence, roaming, sim_swap or score, each billed separately and only when it is delivered. The lookup does not contact the number.
Reusing an Idempotency-Key returns the stored result rather than performing and billing a second lookup. The lookup guide covers the flow and the API reference covers the fields.
In short
Valid means the range exists, not that the number is in use.
Google's phone number library defines a valid range as one from which carriers can freely assign numbers to users.
A connected call does not prove a number is valid.
Some countries ignore extra trailing digits, and some operators keep old numbers working through a renumbering long after they stop working elsewhere.
Only a challenge proves possession.
Sending a code and getting it back is the one check that establishes who holds the number, which is why verification exists as a separate step.
An unanswered check is not a negative answer.
Bird reports each requested property with its own status, so a property nobody could answer stays distinguishable from one answered no.