API surface
The API exposes a small, focused set of endpoints used to interpret entity identifiers, verify them, and inspect coverage and registry integrations.
Each endpoint addresses a specific concern and can be used independently, although most integrations combine them as part of a single flow.
The official SDKs provide typed access and reasoning helpers on top of the same endpoints, as described in the SDK overview. If your language is not supported, the SDK repositories can be used as reference implementations.
Core endpoints
The following endpoints form the core surface used in most integrations.
Verify an ID
POST /verify
Validate an entity identifier and retrieve registry-backed evidence and normalised data.
This endpoint performs syntactic validation, registry lookups, optional expansion through linked identifiers, and result normalisation. Registry responses are combined following the principles described in Cross-registry checks and normalised according to Data normalisation. Raw values are preserved for auditability, while normalised fields are provided for day-to-day use.
See Verify an ID for a detailed breakdown of inputs, outputs, and interpretation.
Infer the ID type
POST /infer-type
Analyse a raw identifier and infer the most likely identifier type, optionally constrained by country or region.
This endpoint is typically used when identifiers originate from user input or external systems, and is often called immediately before verification.
See Infer the ID type for usage details and examples.
List supported IDs
POST /id-types
Return all supported identifier types, grouped by country, region, and validation strength.
This endpoint is commonly used to drive dynamic onboarding flows and validation logic, allowing applications to adapt to coverage without hardcoding assumptions.
See List supported IDs for the full response structure.
List data sources
POST /sources
Return all registry integrations, including coverage, supported identifier types, and operational status.
This endpoint provides visibility into which registries contribute data and under which conditions, including degraded or cached paths.
See List data sources for operational details.
Response and data behaviour
All endpoints return structured responses following shared rules for envelopes, merging, normalisation, and freshness.
- Response envelope › understand the common response structure.
- Cross-registry checks › see how evidence from multiple registries is merged.
- Data normalisation › learn how fields, addresses, and dates are standardised.
- Caching and stale data › understand freshness, caching, and fallback behaviour.
- Error handling › interpret API-level and domain-level errors.
Operational information
The following sections cover operational and contractual aspects of the API:
- Billing › usage limits and billing model.
- Security › API key handling and operational guidance.
- Legal notes › terms, disclaimers, and compliance information.