Validate Configuration
Checks whether a structured JSON body is a well-formed FMV1 configuration, WITHOUT applying any changes. The body is the structured FMV1 configuration shape (the same body import accepts). Use this to check for errors before running an import.
It is a true dry run — it performs no writes.
It checks configuration shape only. It does not examine the company’s
stored records: no records are read, so the response time does not depend on
how much data the company holds. isValid: true means the configuration is
well-formed — it makes no claim about whether stored records conform to it.
To ask that second question — would my already-stored records still fit? —
start a data validation run:
POST /configuration/data-validation-runs kicks off a background scan of
every stored record (against a candidate configuration you send, or against the
live configuration if you send no body), and
GET /configuration/data-validation-runs/{runId} reports its progress and
counts. Use validate first for a fast, data-free shape check, then a run
when you need to know which stored records a configuration would break.
The checks it runs are the config-shape ruleset import also runs: the spec
pass (entity selectors, field references, locations, …), the rater and
form-template existence checks, and the uniqueness/projectability gates. Note
that a clean result here is necessary but not sufficient for a successful
import: import additionally compares the incoming configuration against the
company’s current one and refuses changes that would reshape existing data
(dropped fields, changed types or cardinality, dropped option-set values)
unless ?force=true is passed. Validate does not run that comparison.
Findings are located in the JSON config itself, never by a spreadsheet
cell: each finding carries a path — a JSON path into the config body, e.g.
fields[3].cardinality. Fetch /configuration/schema for the
machine-readable JSON Schema of the body.
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
Body
A COMPLETE configuration body (the same body import accepts). A
delta/patch body is rejected with a 400 — typed changes go to the
patch endpoint (POST .../configuration/patch).
Field definitions, keyed by entity + reference id.
Page definitions.
Card definitions.
Placements of cards onto pages.
Option-set type declarations.
Custom-object type declarations.
Option sets and their options.
Custom-object sub-field definitions, joined to object types.
Object-primitive sub-field definitions (Address / Date / Currency).
Field placements (the layout) onto cards.
Rating workflow definitions.
Per-entity invariant conditions enforced on every write.
Forms-logic rules (quote-flow auto-add rules). Optional — existing payloads predate the "Forms" tab; absent ⇒ no rules.
Smart tags — the named values resolved into generated documents. Optional: existing payloads predate the slice, and absent ⇒ no smart tags, which is also how a company that has not yet moved to this format is recognised.
Omitted from an export when the company has none, rather than emitted as an empty array.
Declared export columns — the tenant-facing column set of each export surface (the seven entity exports plus the bordereau). Optional: existing payloads predate the slice, and absent ⇒ no declared columns, which is also how a surface that still offers every configured field is recognised.
Activation is per surface: a surface with at least one row here resolves its whole tenant column set through those rows, in the order they appear; a surface with none behaves exactly as it did before this section existed.
Omitted from an export when the company has declared none, rather than emitted as an empty array.
Response
Validation completed
Result of validating an FMV1 configuration JSON body. errors collects
config-shape findings; isValid is true when every one of them is clean. It
reports whether the CONFIGURATION is well-formed and makes no claim about the
company's stored records, which are not read.
Whether the configuration passed every config-shape check
List of validation errors (empty when isValid is true)
Validation warnings — reported, never gating: isValid depends on errors
alone. A warning flags something worth a look that is nonetheless a valid
configuration, such as smart-tag rows sharing a key across form types whose
content has diverged.
