Validation APIs, with clearer boundaries.
A valid API response should say what happened—not ask your team to guess. Explore five data families and a shared language for their results.
Driver’s license
Separate document structure, field consistency, and source comparisons.
Passport
Understand document fields and MRZ consistency without assuming authenticity.
Home address
Make address components clearer while preserving the destination that matters.
Mobile number
Keep formatting, number-type signals, and possession in their own lanes.
Legal name
Respect real-world names. Make normalization and comparison transparent.
These pages provide implementation guidance and fictional examples. This website does not perform live checks, issue API keys, or claim source-provider coverage. Read the service scope.
Five questions. Not one boolean.
Use the narrowest description that accurately explains the check. Keep an observation separate from the decision your product makes.
| Layer | Question | What to document |
|---|---|---|
| Structure | Can the input be parsed under an explicit rule? | Input shape, required context, supported representation. |
| Normalization | Is there a more useful representation? | A proposed transformation, with the original meaning preserved. |
| Consistency | Do related values agree? | A named comparison between known inputs—not an independent source match. |
| Source comparison | Does a claim match a specified record? | A separately enabled, authorized method with documented coverage. |
| Holder linkage | Is the evidence connected to the applicant? | A distinct verification process, not an inference from formatting. |
The distinction between evidence validation and identity verification is discussed in NIST’s identity proofing guidance. The table above is a proposed integration vocabulary, not a claim of conformance to an assurance level.
Uncertainty is a useful result.
A source outage is not an invalid person. An unsupported input is not a mismatch. Preserve those differences in the response and the next action.
{
"demo": true,
"request_id": "sample_address_001",
"status": "needs_review",
"checks": {
"structure": "pass",
"postal_reference": "not_checked",
"residence": "not_checked"
},
"reasons": [
{
"code": "example_only",
"message": "Fictional fixture; no real-world validation performed."
}
],
"next_action": "review_requirements"
}Home address: fictional response example. These predefined signals illustrate a proposed contract, not a check of real data. View service scope.
Make your next check
more meaningful.
Start with the right question. Build toward a clearer answer.