Update any subset of a project's fields — data source connection, display name, language, timezone — and optionally replace its MDL. Send only the fields you want to change; an empty body is a 400.

MDL replacement works for both project types, but the write path differs by type. Everything else on this endpoint behaves the same either way.

Basic Usage

Request

{
  "displayName": "Revenue Analytics",
  "language": "EN",
  "timezone": "Europe/London"
}

Response

{
  "updatedProject": {
    "id": 123,
    "type": "POSTGRES",
    "projectType": "CLASSIC",
    "displayName": "Revenue Analytics",
    "createdAt": "2025-09-11T12:34:56Z",
    "updatedAt": "2025-09-12T09:02:11Z",
    "connectionInfo": {
      "host": "db.internal",
      "port": 5432,
      "user": "app",
      "password": "******",
      "database": "warehouse",
      "ssl": true
    },
    "language": "EN",
    "timezone": "Europe/London"
  }
}

Updating the Data Source

Pass type and connectionInfo to repoint the project, and testConnection: true to validate the credentials before they are saved. connectionInfo is merged into the existing one, so you can send just the fields that changed — unless you also change type, in which case supply the full connection.

An agentic project created without a data source is connected the same way: send type and connectionInfo on this endpoint.

Replacing MDL

Passing mdl replaces the project's models and columns, applies relationships and views on a best-effort basis, and re-deploys. The manifest is validated before anything is written, so a malformed one returns 400 and leaves the project exactly as it was — including the other fields in the same request.

Where the manifest lands depends on the project type:

• Classic projects — the manifest is stored in the database and deployed. If the deploy fails it is retried twice; a still-failing deploy is reported in mdlUpdate.warnings.deploy rather than failing the request, so the manifest is saved but not yet live.
• Agentic projects — the data model is Git-backed, so the manifest is persisted and committed to the project's shared-data repository, then deployed from there — the same path the modeling UI takes. The response adds mdlUpdate.commitSha for that commit.

Best-effort failures on either path come back as warnings alongside a 200, not as errors.

Request

{
  "mdl": {
    "models": [
      {
        "name": "orders",
        "columns": [
          { "name": "order_id", "type": "VARCHAR", "notNull": true },
          { "name": "amount", "type": "DOUBLE" }
        ],
        "primaryKey": "order_id",
        "tableReference": { "catalog": "memory", "schema": "main", "table": "orders" }
      }
    ],
    "relationships": [],
    "views": []
  }
}

Response (agentic project)

{
  "updatedProject": { "...": "..." },
  "mdlUpdate": {
    "commitSha": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0",
    "warnings": {
      "relationships": [],
      "views": ["View \"sales_by_city\" failed: question is required"]
    }
  }
}