Skip to main content
GET
Export ODCS

Import & Export

Data contracts can be imported and exported using the Open Data Contract Standard (ODCS) v3.1.0 format. Both JSON and YAML are supported, with smart merge and full replace modes for updates. For which ODCS fields an import keeps, how quality rules become test cases, and how exports differ from the Bitol JSON Schema, see ODCS Import and Export. The createTestCases parameter, the odcsImportReport in validation responses, and quality rules that run as test cases require OpenMetadata 2.0.3 or later.

Export to ODCS

Export by ID (JSON)

GET /v1/dataContracts/{id}/odcs

Export by ID (YAML)

GET /v1/dataContracts/{id}/odcs/yaml

Export by FQN (JSON)

GET /v1/dataContracts/name/{fqn}/odcs

Export by FQN (YAML)

GET /v1/dataContracts/name/{fqn}/odcs/yaml
string
UUID of the data contract.
string
Fully qualified name of the data contract.
string
Fields to include in the export. Defaults to owners,reviewers,extension,schema,sla,security.
Export ODCS

Import from ODCS

Create from ODCS JSON

POST /v1/dataContracts/odcs

Create from ODCS YAML

POST /v1/dataContracts/odcs/yaml

Create or Update from ODCS JSON

PUT /v1/dataContracts/odcs

Create or Update from ODCS YAML

PUT /v1/dataContracts/odcs/yaml
string
required
UUID of the entity to attach the contract to.
string
required
Type of the entity (e.g., table, topic, apiEndpoint).
string
default:"merge"
Import mode for PUT endpoints: merge (preserves existing fields not in the import) or replace (fully overwrites the contract).
string
Schema object name to import for multi-object ODCS contracts. If not specified, auto-selects based on entity name.
boolean
default:"true"
Whether the contract’s ODCS quality rules become test cases on the table. With false, the rules are stored with the contract without running, and test cases already linked to the contract stay linked, in replace mode too. Creating test cases requires the Create Tests permission on the table. Without it, an import with createTestCases=true returns 403 and writes nothing.
Import ODCS
Import ODCS
Import ODCS
An import reads past values it can’t represent. It leaves them out and imports the rest. Only the blocking issues listed under Validate ODCS YAML reject the request.

Preserving ODCS-Only Fields

ODCS documents can carry data OpenMetadata doesn’t model directly, such as element-level authoritativeDefinitions and transformSourceObjects. Rather than dropping this data, OpenMetadata stores it as a passthrough and restores it on export. ODCS quality rules are stored the same way, whether or not they also run as test cases, so an export returns them word for word.
A plain PUT /v1/dataContracts that omits these fields from its payload leaves them untouched—only an explicit empty array in the payload clears them, the same way PUT /odcs?mode=replace does with a document that omits them. A PATCH that explicitly removes them also works.
Current limitations:
  • The contract page doesn’t show these passthrough fields. Quality rules that run show up as the contract’s test cases. The import report lists every rule, including the ones that don’t run.
  • If the schema element an extension is attached to can’t be matched on export (for example, it was renamed or removed), authoritativeDefinitions fall back to the contract level rather than being lost. transformSourceObjects have no such fallback. For an unmatched element, they’re dropped instead.
  • Several other ODCS attributes aren’t mapped yet and don’t round-trip: businessName, classification, examples, customProperties, transformLogic, transformDescription, logicalTypeOptions (except maxLength, which round-trips through the column’s dataLength), and element-level tags. For the full list, see Field Mapping.

Parse ODCS YAML

Preview an ODCS YAML contract without importing. Useful for inspecting multi-object contracts. POST /v1/dataContracts/odcs/parse/yaml
Parse YAML
Response

Validate ODCS YAML

Preview an ODCS YAML import against a target entity without creating anything. The response reports what the import keeps, changes, and leaves out, and what each quality rule becomes. The UI’s import dialog shows the same report. POST /v1/dataContracts/odcs/validate/yaml
string
required
UUID of the entity to validate against.
string
required
Type of the entity.
string
Schema object name for multi-object contracts.
boolean
default:"true"
Whether the import you’re previewing would create test cases from the quality rules. Pass the same value you’ll import with, so the report matches the import.
Validate YAML
Validate YAML
Response
The response is a ContractValidation. valid matches odcsImportReport.canImport.

Import Report Fields

Each issue has these fields: Each quality rule entry has these fields: These issues are blocking:
  • An unsupported apiVersion, a kind other than DataContract, or a missing or invalid status.
  • A contract column the table doesn’t have, or a column listed twice.
  • An objectName that isn’t in the document, or a missing entity.
  • Quality rules that would create test cases the caller may not create. Validate and import with createTestCases=false to keep the rules without running them.
A document with missing required fields returns 200 with valid: false and a blocking issue. Malformed YAML returns 400.

Supported ODCS Versions


Error Handling