Import Configuration
Imports FMV1 configuration from a structured JSON body into the database. The body is the structured FMV1 configuration shape. This runs the full pipeline: validate, compare, and apply changes.
On success the response returns success: true. If validation fails, no
changes are applied and the endpoint returns a 400 with a
config-validation-failed error carrying the validation problems. The
validation errors are located by configuration coordinate (entity / field).
Breaking changes
A config that drops a field, or changes a field’s type or cardinality
(Single↔List), would reshape data already stored under the current config. In
that case the import is rejected with a 409 (fmv1-config-breaking-changes)
and nothing is written — unless one of the following applies:
- The instance holds no entity data. With no stored records to invalidate, the breaking-change check is skipped automatically and the import proceeds. (Common while onboarding a fresh instance.)
?force=trueis set. The import proceeds anyway and the existing entity data is left untouched — values for a dropped field remain in the stored JSON, and a type/cardinality change leaves old-shaped values behind.
Dry run
?dryRun=true runs this endpoint as a prediction: every gate a real
import runs is executed — the validation and the breaking-change check —
and then the request stops before persisting. Nothing is written: no
configuration version, no import history. So a 200 under dryRun means a
real import of the same body would be accepted, and a 400/409 means it
would be rejected for exactly that reason. force applies under dryRun
too, so ?dryRun=true&force=true previews the forced import.
Required permission: company.configuration:import. A force import
additionally requires company.entity-data:deleteAll, which is granted by
the SUPER_ADMIN role only — so only a SUPER_ADMIN key can force past the
breaking-change gate; a Configuration-Manager key that sets ?force=true
gets a 403.
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
Query Parameters
When true, bypass the breaking-change check and import even if the new
config would invalidate data already stored under the current config.
Existing entity data is left in place (not cleared) and may no longer
match the new config. Any value other than true (including omission) is
treated as false.
Almost never set this. Only use force when you are 100% certain
every existing record is forwards-compatible with the incoming config
(nothing stored will be invalidated) — e.g. a dropped field that no
record holds a value for. When unsure, clear the affected entity data and
re-import without force instead.
Requires the SUPER_ADMIN role (the company.entity-data:deleteAll
permission) — a non-SUPER_ADMIN key that sets this gets a 403.
When true, run the import but write nothing. Every gate a real
import runs is executed — the full configuration validation and the
breaking-change check, honouring force and whether the instance holds
entity data — and the request then stops before persisting. No
configuration version is written and no import history is recorded.
Because this is the same code path as a real import stopped one step
short, the answer is a faithful prediction of what importing this
exact body would do right now: 200 means the real import would be
accepted, 400 means validation would reject it, and 409
(fmv1-config-breaking-changes) means the breaking-change check would
reject it. Combine with ?force=true to preview the forced import
instead.
Any value other than true (including omission) is treated as false —
i.e. the import commits.
Optional compare-and-swap precondition. When supplied, the import is
admitted only while the company's configuration still has this content
hash — the value reported as contentHash by the metadata endpoint
(GET .../configuration/metadata). Omit it and no precondition is
applied.
The check runs inside the import's own transaction, so a caller that read the configuration and then imports cannot be raced by a concurrent configuration write: this turns read-then-import into one atomic operation rather than merely narrowing the window.
A mismatch is a 409 with code fmv1-config-expected-hash-mismatch and
nothing is written. The error body carries currentContentHash and
currentVersion, so you can re-read, rebase your changes onto the
current configuration and retry without an extra round trip.
currentContentHash is null when the company has no configuration
version at all — which is also a mismatch, never a pass.
The value must be a sha256 written as 64 lowercase hex characters;
anything else is a 400 (fmv1-config-expected-hash-malformed) rather
than a silently skipped precondition.
Evaluated under ?dryRun=true as well, so a dry run predicts this
verdict exactly as it predicts the validation and breaking-change ones.
^[0-9a-f]{64}$"9f2c0b1d4e6a8c3f5b7d9e1a2c4e6f80a1b3c5d7e9f0a2b4c6d8e0f1a3b5c7d9"
Body
A COMPLETE configuration body. To apply a small edit without sending
the whole config, use the typed-change patch endpoint
(POST .../configuration/patch) instead — this endpoint rejects a
delta/patch body with a 400.
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.
