PERSON DATA · VALIDATION GUIDE

Legal name validation API

Build name-data workflows that preserve the supplied representation and explain the purpose of every comparison. A name is more than a pattern.

Explore the exampleRead the full guide

Real names. Not rigid assumptions.

structurepass
record_matchnot_checked
legal_identitynot_checked

ILLUSTRATIVE SIGNALS · NOT A LIVE RESULT

WHAT TO MAKE EXPLICIT

Design around the evidence.

A result becomes useful when its method, limits, and next action are visible together.

01 / SIGNAL DESIGN

Purpose-led collection

Display name versus a specific record name. Make the method and any unresolved context visible to the consumer.

02 / SIGNAL DESIGN

Respectful handling

Preserved spelling, case, and punctuation. Make the method and any unresolved context visible to the consumer.

03 / SIGNAL DESIGN

Limited comparisons

Similarity without an identity claim. Make the method and any unresolved context visible to the consumer.

What this does not establish

Name parsing and similarity do not establish a legal identity. There is no universal name pattern that proves whether a person’s name is legitimate.

Reference: W3C guidance on personal names. Reference links explain the underlying distinction; they do not imply a partnership or an enabled source connection.

A CONTRACT YOU CAN DISCUSS

Read the example.
Review the assumptions.

Switch between the fictional request and response. The example records structure separately and leaves real-world verification unperformed.

Proposed route: POST /v1/validate/legal-name. This is a design example, not an available network endpoint.

Open the full documentation
name.response.json
{
  "demo": true,
  "request_id": "sample_name_001",
  "status": "needs_review",
  "checks": {
    "structure": "pass",
    "record_match": "not_checked",
    "legal_identity": "not_checked"
  },
  "reasons": [
    {
      "code": "example_only",
      "message": "Fictional fixture; no real-world validation performed."
    }
  ],
  "next_action": "review_requirements"
}
LOCAL EXAMPLE · NO NETWORK REQUESTJSON / UTF-8

Legal name: fictional response example. These predefined signals illustrate a proposed contract, not a check of real data. View service scope.

PLAN THE NEXT STEP

Keep the workflow human.

Ask for correction.

Point to the missing context or affected field. Preserve the person’s intended value until a meaningful change is reviewed.

Make review explicit.

Separate incomplete evidence from negative findings. Assign ownership and provide a real path for resolving uncertainty.

Prepare for unavailability.

A dependency problem needs an operational route. Do not ask users to keep editing information that was never checked.

Read the detailed legal name guide

Explore another data family.

VALIDATION

Driver’s license validation API

Separate document structure, field consistency, and source comparisons.

Explore resource
VALIDATION

Passport validation API

Understand document fields and MRZ consistency without assuming authenticity.

Explore resource
VALIDATION

Home address validation API

Make address components clearer while preserving the destination that matters.

Explore resource
YOUR NEXT INTEGRATION

Make your next check
more meaningful.

Start with the right question. Build toward a clearer answer.

Explore the documentationTalk about your workflow