Get Data Validation Run
Reports the progress and results of a data validation run started by
POST /configuration/data-validation-runs.
Poll this until status is succeeded or failed. The counts climb as the scan
progresses, so a poll mid-scan is a real partial reading, not a placeholder.
Statuses
queued— the run exists and is waiting for a worker. Its counts are all0. This is a normal state that every run passes through, not a stall: the run is recorded before the background work is dispatched.running— the scan is in progress; the counts climb.succeeded— the whole book was scanned.finishedAtis set,errorisnull.failed— the scan stopped early.finishedAtis set anderrorcarries the reason. Start a new run to retry.
The counts
recordsScanned is how many records the scan has classified so far. The other
three are independent, overlapping buckets — a record with an undeclared key
and a value that breaks is counted in both, so they do not sum to
recordsScanned:
recordsAdhering— records that would persist cleanly under the scanned configuration: no undeclared keys and no violations.recordsWithExtraKeys— records holding keys the scanned configuration no longer declares. Suspect, not necessarily fatal.recordsBreaking— records holding a value that would fail a write under the scanned configuration (a changed type or cardinality, an option-set key that no longer exists, a broken relational reference, a violated invariant).
There is deliberately no total and no percentage: producing a denominator
would mean counting every record of every entity type before the scan could
report anything. Treat recordsScanned as a monotonic progress signal, and the
terminal status as completion.
Per-record detail — which records and which fields — is not part of this response.
How long a run stays readable
A run’s status stays readable for as long as the run exists — nothing removes a run on a timer, and however long ago it completed this endpoint still reports it. A run’s age is never a failure: a run that exists is reported in full however long ago it finished, and no response reports a run as too old to read.
Required permission: company.configuration:export
This endpoint requires an API key created with the FMV1_CONFIGURATION_MANAGER role. See Authentication for how to create API keys with specific roles.
Authorizations
User-principal OAuth 2.0 Bearer authentication. Send a user-scoped Auth0 access token (audience = the app API audience) as Authorization: Bearer <jwt>. The request resolves to the user's identity and is authorized by their Role on the {companyId} in the path — the same role-based permissions the web app enforces. This is the path the MCP connector uses to act on a user's behalf; endpoints that accept it list both BearerAuth and ApiKeyAuth.
Path Parameters
Company identifier
The run identifier returned by POST /configuration/data-validation-runs. Runs are scoped to their company: a
run id belonging to another company returns 404, exactly as an id that
exists nowhere does.
Response
The run's current status and running counts
A data-validation run's current status and running counts. Fixed size: there is
no per-record findings list, and deliberately no total or percentage — the three
classification counts are independent, overlapping buckets and do not sum to
recordsScanned.
The run identifier
queued while the run waits for a worker (a normal state, not a stall), running mid-scan, then the terminal succeeded or failed
queued, running, succeeded, failed How many stored records the scan has classified so far
Records that would persist cleanly under the scanned configuration — no undeclared keys and no violations
Records holding keys the scanned configuration no longer declares (suspect, not necessarily fatal)
Records holding a value that would FAIL a write under the scanned configuration
Why the scan stopped; null unless status is failed
When the run was started
When the run's counts or status last changed
When the run reached a terminal status; null until then
