List data sources

Every validation in VerifyVAT is backed by one or more registry integrations.
Some countries have a single authoritative source. Others combine tax authorities, business registers, licensing bodies, or global regulators such as GLEIF.

The /sources endpoint exposes this information programmatically.
It is the registry-centric counterpart to List supported IDs, which focuses on ID types.
Both endpoints describe the same dataset, seen from two different angles.

Use this endpoint when you need clarity on where our engines retrieves data from and how each registry contributes to validation.

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

When to use /sources

This endpoint helps you answer practical questions such as:

• Which registries power validations for a given market?
• Which data sources have full vs partial coverage?
• Which registries are active right now?
• Which ID types does a registry support?
• How does validation differ across countries or regions?

You can also explore the same dataset visually via the Sources and Coverage pages.

If your integration needs to document data lineage, choose optimal fallbacks, or provide transparency during audits, this endpoint is the right tool.

Calling the endpoint

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/sources
3
Content-Type: application/json
4
{
5
    "id": "{id-filter}",
6
    "coverage": "{coverage-filter}",
7
    "supports": "{supports-filter}",
8
    "active": "{bool}",
9
    "region": "{region-filter}",
10
    "country": "{country-filter}",
11
}
12

13
### or with path segments:
14
POST https://api.verifyvat.com/v1/sources/:country
15
POST https://api.verifyvat.com/v1/sources/:id
16
POST https://api.verifyvat.com/v1/sources/:supports
17
Content-Type: application/json
18
{
19
    ### only coverage is supported in this case:
20
    "coverage": "{coverage-filter}"
21
}
22

23
### or with query parameters:
24
GET https://api.verifyvat.com/v1/sources?country={country-filter}&coverage={coverage-filter}

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

Filtering the results

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

All filters (except active) 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 { "supports": ["no_vat", "it_vat"] }

Understanding the response

The response uses the common envelope described in Response envelope. Inside data, the sources[] array contains the list of registry integrations matching the filters, or the full list if no filters were applied. Each entry describes one registry that our engine can query, along with the ID types it supports.

This endpoint does not report runtime connectivity. The active flag only indicates that the integration is enabled in the system for your account, not whether the registry responded at this moment. This is important for Bring-Your-Own-License (BYOL) registries, where you may not currently have access.

Source object

ID type object (inside source.types[])

This corresponds exactly to the entries returned by List supported IDs, minus the sources[] field. It describes the ID types that this registry can contribute evidence for, along with their validation method and coverage level.

Real-world examples

Recommended usage

1. Use /sources to anticipate validation behaviour, it lets you see exactly which registries contribute to each ID type.
2. Pair it with List supported IDs, as the two endpoints describe the same dataset from different perspectives.
3. Cache /sources responses, since registry metadata updates infrequently.
4. Avoid assuming full coverage, as some registries only confirm validity while others provide full entity profiles.
5. Use region filters to bootstrap regional features, helping you scope new markets before routing IDs through /verify.