List supported IDs

The /id-types endpoint describes which kinds of entity IDs our engine understands, how those IDs are validated, and which registries participate in their verification.
Coverage is not limited to a static list of countries or formats. Instead, the system exposes a structured catalogue of ID types that reflects the current state of supported registries, validation strategies, and geographic reach.

This catalogue is intended to be consumed programmatically and used to drive routing, validation, and trust decisions in downstream systems.

If you are using an official SDK, the same coverage data is available through the SDK tooling. See Domain graph for cached and offline access to the coverage view.

Requesting the catalogue

The endpoint accepts GET or POST requests.
Parameters may be provided via path segments, query parameters, or JSON body fields.

1
### JSON body (recommended):
2
POST https://api.verifyvat.com/v1/id-types
3
Content-Type: application/json
4
{
5
    "country": "{country-filter}",
6
    "id": "{id-filter}",
7
    "region": "{region-filter}",
8
    "validation": "{validation-filter}"
9
}
10

11
### or with path segments:
12
POST https://api.verifyvat.com/v1/id-types/:country
13
Content-Type: application/json
14
{
15
    ### only validation is supported in this case:
16
    "validation": "{validation-filter}"
17
}
18

19
### or with query parameters:
20
GET https://api.verifyvat.com/v1/id-types?country={country-filter}&validation={validation-filter}&region={region-filter}

If no filters are provided, the full global catalogue is returned.

Filtering the results

The catalogue supports multiple filters, all of which can be used individually or combined.

All filters accept a single string, a comma-separated list, or an array of strings:

1
### a single string:
2
POST { "region": "EMEA" }
3

4
### a comma-separated list
5
GET "?country=NO,IT"
6

7
### an array of strings
8
POST { "validation": ["registry", "syntactic"] }

Understanding the response

The response uses the common envelope described in Response envelope. Inside data, the types[] array contains the list of supported ID types matching the filters, or the full list if no filters were applied. Each entry describes one ID type that the engine can process. This is what you pass into Verify an ID as the type field.

Type object

Source object

Coverage directly affects how to interpret verification outcomes. See Cross-registry checks for how evidence is combined, and Verify an ID for how coverage, origin, and issues[] influence decision-making.

Developer patterns

Dynamic onboarding forms

Instead of maintaining per-country rules, request the list scoped by country. You can use the result to render country-appropriate pickers, apply formatting masks using format, and route directly to Verify an ID using the returned id type.

Programmatic routing for verification

If your system receives { id, country }, a predictable flow is:

1. Call the endpoint scoped by the country to retrieve which ID types are relevant.
2. Compare the user input against format hints to narrow down candidates.
3. Verify using the chosen type.

A similar approach can be achieved via Infer the ID type, which applies the same coverage data but with built-in heuristics to infer the most likely type.

Coverage-aware trust strategies

Use sources[].coverage to set expectations about negative outcomes:

• With full coverage, outcome: "unconfirmed" from verification is typically definitive.
• With partial coverage, outcome: "unconfirmed" can be a false negative, and your workflow should treat it as degraded evidence rather than proof of non-existence.

Building internal validators and schemas

Many teams snapshot the catalogue to generate internal schemas, validators, and UX constraints, then refresh it periodically to track coverage evolution. See Domain graph if you want a cached and offline-friendly view through the SDK.

Real-world example