Top-level `ConnectorConfigV3` shape

The root config object. Everything else lives under it.

Shape


{
  "version": "3.0",
  "entities": [],
  "flows": [],
  "settings": {}
}

Fields

Field	Type	Required	Default	Notes
`version`	`"3.0"` or `"3.1"`	yes		Pinned literal. Must equal `"3.0"` or `"3.1"`.
`entities`	array of Entity	no	`[]`	See entities.md.
`flows`	array of Flow	no	`[]`	See flows.md.
`settings`	object	no	`{}`	Free-form. See “Settings” below.

`version`

Pydantic literal: Literal["3.0", "3.1"]. Anything else fails with Input should be '3.0' or '3.1'. This pin is deliberate: it keeps draft writers explicit about the schema version they target.

"3.0" is the baseline reference documented across these pages.
"3.1" adds the bulk step actions (upsert_many, create_many, update_many, delete_many, associate_many) and four step fields used by them (items, chunk_size, output, reconcile). See the relevant rows in step-actions.md.

`entities` and `flows`

See the dedicated reference pages. Both default to empty arrays; a config with no entities and no flows is syntactically valid but does nothing.

`settings`

Free-form object. The current v3 runtime does not read any specific keys from here; it is reserved for connector-scoped options that future plans may introduce. The historical key scope_overrides from v2.1 has no v3 reader; do not depend on it under v3.

Validators

Rule	Failure message
`entities[].name` unique within the config	`entity names must be unique within a config`
`flows[].name` unique within the config	`flow names must be unique within a config`

Forward-compat caveat

ConnectorConfigV3 declares model_config = ConfigDict(extra="allow") at the top level. This means unknown top-level keys do not fail validation. Typos pass silently. Treat the table above as authoritative; do not introduce new top-level keys without a schema change.

Top-level ConnectorConfigV3 shape