An email address can have the right syntax, a domain that accepts mail, and an inbox whose existence is still unknown. A phone number can fit its country's numbering plan while the line is disconnected. A street address can match a building without confirming an apartment inside it.
All three can reasonably be called valid, depending on the question. That is where integrations get into trouble. The application asks whether it can take an action, but the check only establishes one fact about the input.
Before choosing an endpoint, finish the sentence: "I need to know this because I am about to..." Store a consistently formatted value? Suggest a correction? Send a message? Match an address to a record? Those actions need different evidence.
Separate the checks
Parsing identifies the parts of a value. An address parser can separate a house number, street, city, and postal code. A name parser can separate parts of the supplied name. Neither operation establishes who lives at the address or whose name it is.
Normalization gives a value a consistent representation. A phone number written with spaces and parentheses can become an international number suitable for storage. Keep the input as well when you need to show the person what changed. A normalized value is easier to compare; it has not gained proof of ownership.
Validation checks a defined set of rules. An email can pass syntax rules. A phone number can fit a numbering plan. The useful question is which rules the field represents, not whether the API happens to call it valid.
Verification checks an additional claim against evidence beyond the input's shape. Does the domain have a mail route? Did a mailbox check return a result? Is a phone number assigned? Does an address match an official record? Each answer has its own scope and can be unknown.
Enrichment adds other facts alongside those checks: a country's currency, a number's carrier, or a place's coordinates. Useful extra information should remain separate from the verdict your application needs. A missing coordinate does not automatically invalidate an address.
Read the field that answers the question
These examples use the ParseAPI 2.0.0 contract. An existing integration should select its API version explicitly before adopting another version's fields.
| Question | Relevant field | What the answer establishes |
|---|---|---|
| Does this email have valid syntax? | Email valid | The address passes the syntax check. |
| Does its domain accept mail? | Email domain_valid | The domain has a mail route. |
| What did the mailbox check find? | Email deep.deliverable | A mailbox-existence result; it can be unknown. |
| Does this number fit the numbering plan? | Phone valid | The number passes numbering-plan validation. |
| Is the number assigned? | HLR live | Assignment at the last status check. |
| Was the handset reachable? | HLR connected | Reachability at the last check, when that question could be answered. |
| Does this US address match official records? | Address registered | A match to an address record or mapped street-number range. |
An email domain's mail setup does not identify a particular inbox. A positive mailbox result does not prove the person filling in a form controls it. If the action requires proof of control, that needs a separate step, such as having the person complete a confirmation sent to the address.
Phone assignment and reachability are also separate. A number can be assigned while its handset is unreachable. A landline may have a known assignment result and unknown handset reachability. The phone-status explanation shows why these fields are independent.
For a US address, registered can describe a building or mapped street-number range. It does not establish postal deliverability or confirm a supplied apartment. A range match can have null coordinates. Use the Address reference to understand what the match represents before turning it into a shipping decision.
Keep unknown as its own result
The most damaging shortcut is often a Boolean conversion. false and null both fail a JavaScript truthiness check, but they carry different information. One is a negative answer. The other is an unanswered question.
Here is an illustrative response excerpt for an address whose syntax passed but whose mailbox check did not establish an answer:
{ "valid": true, "deep": { "deliverable": null } }
The mailbox field could instead contain true or false when the check has an answer. Preserve all three states when storing the result, so an unavailable answer does not become a failed address in your database.
Preserve that distinction when adapting the response for your interface:
// Application display states, not additional API fields.
function verdictState(value) {
if (value === true) return "positive";
if (value === false) return "negative";
return "unknown";
}
const mailboxState = verdictState(result.deep?.deliverable);
This also leaves the display unconfirmed when deep is absent or empty. Those cases deserve different diagnostic information: a request without deep=true did not ask for the mailbox result, while a requested field can be null because its check did not complete. Keep the request options and original response if your workflow needs to distinguish them. One route. Two depths. explains the response shapes.
A request error is another state. A 401, 429, or 503 response is not a negative verdict about the input. Handle the HTTP status and error first; only read validation fields from a successful response. Some checks can successfully return HTTP 200 with an unknown result. Transport success and a positive data verdict are independent.
Put checks where their answer becomes useful
While someone types, the useful action is usually a small correction or suggestion. Keep their text editable. Ask for country context when a national phone number needs it, and show an email typo suggestion without silently replacing the address. A suggestion can be useful without being authoritative.
When the person submits a form, decide which checks are actually required for that form. A shared support@ inbox may be a perfectly good business contact. A consumer email address may be appropriate for a personal account. Email's role, free, and disposable flags describe different properties; collapsing them into one invalid flag hides the policy you are applying. The email-field guide separates those questions.
When a workflow needs an additional check, request it deliberately. Mailbox verification uses Email's deep=true option. Phone formatting, carrier information, and line status are separate operations. Choose the work because its answer changes what the application does next, and review the applicable allowance or quote before running it across a file.
For an import, preserve the original rows and source identifiers. Put normalized values and check results in separate columns, then decide what to do with positive, negative, and unknown results. The multiple-phone-column walkthrough includes a small file you can use to follow that process without losing track of the original cells.
Keep the result tied to what was checked
A result belongs to the input and context used for that check. If a user changes the phone number or its country, the earlier result should stop describing the current field. If a newer search finishes before an older one, the older response should not overwrite it. The same rule applies to manual edits after selecting an address suggestion.
Keep enough application context to explain the decision: the submitted value, the country or other scope, the normalized value, which check ran, and the result. A timestamp you record when receiving a response is a receipt time. It is not automatically the time the underlying fact was observed.
Mailbox and line-status results may be reused. Assignment and reachability can change, so treat them as observations with the documented freshness behavior. A successful response received now is not a promise about the next delivery attempt. The Email and HLR references describe those checks and their reuse periods.
The application still has a decision to make. It can ask for a correction, offer another contact method, retain an unconfirmed value, or route a record for review. Keeping the individual answers intact makes that decision understandable and lets you change the policy later without having discarded the evidence.