2026.10.c

🥥

Highlights

The 2026.12 release introduces the Risk Data Lake and Risk Data Refinery APIs.

Moody's publishes preliminary information to inform stakeholders ahead of the targeted Intelligent Risk Platform update. Note that these described features are not guaranteed for the next update or any subsequent updates and may be changed without notice. The definitive list of features will be provided in the Changelogs at the time of the official release.

Learn More

Risk Data Lake API

Check Auth Status

The Check Auth Status operation (GET /sql-editor/v1/auth/status) checks the authentication status of the client.

Get Catalogs

The Get Catalogs operation (GET /sql-editor/v1/catalogs) returns a list of catalogs.

A catalog is a collection of catalog schemas and is the first segment of a fully qualified table reference (catalog.schema.table).

Three catalogs are available by default:

A successful request returns a list of catalogs:

{
  "catalogs": [
    {
      "name": "string",
      "comment": "string",
      "type": "string"
    }
  ]
}

Get Catalog Schemas

The Search Catalog Schemas operation (GET /sql-editor/v1/catalogs/{catalog-name}/schemas) returns a list of catalog schemas.

A catalog schema is a collection of tables within a catalog. The risk_data_catalog contains the following schemas:

The catalogName path parameter specifies the name of the catalog. One of Risk_data_catalog, User_data, Tenant_data.

The user_data and tenant_data catalogs expose schemas for user-uploaded tables and views. Each catalog also provides an information_schema containing metadata about the catalog objects (analogous to INFORMATION_SCHEMA in a standard relational database).

A successful request returns a list of catalog schemas:

{
  "schemas": [
    {
      "name": "string",
      "comment": "string",
      "fullName": "string"
    }
  ]
}

Get Tables

The Get Tables operation (GET /sql-editor/v1/catalogs/{catalog-name}/schemas/{schema-name}/tables) returns a list of tables.

A table is the third level of the catalog.schema.table hierarchy and the primary unit of queryable data. There are three types of tables:

The catalog-name and schema-name path parameters are required.

The Get Tables operation returns up to 50 tables per page and supports pagination via a next-token parameter.

{
  "tables": [
    {
      "name": "string",
      "schema": "string",
      "fullName": "string",
      "type": "string"
    }
  ],
  "nextToken": "string"
}

Get Table

The Get Table operation (GET /sql-editor/v1/catalogs/{catalog-name}/schemas/{schema-name}/tables/{table-name}) returns column names, data types, and metadata for the specified table.

{
  "name": "string",
  "schema": "string",
  "fullName": "string",
  "type": "string",
  "columns": [
    {
      "name": "string",
      "nullable": "string",
      "dataType": "string"
    }
  ],
  "createdAt": 0,
  "owner": "string"
}

Import Data

The Import Data operation (POST /sql-editor/v1/catalogs/import-external-data) imports data.

This operation initiates a job create a new table from an uploaded file. End users trigger this through the SQL Editor Upload button, targeting either user_data (available to all roles) or tenant_data (Admin role only). The table appears in the Catalog Explorer once the import completes.

The required x-rms-resource-group header parameter specifies the ID of a resource group.

If successful, the operation returns a 202 Accepted HTTP status code response and the following response body:

{
  "columns": {
    "additionalProp1": "string"
  },
  "tableName": "string",
  "storageId": "string",
  "filePrefix": "string",
  "fileName": "string",
  "databricksCatalog": "string",
  "databricksSchema": "string"
}

The response object provides information about the table created in the category:

Execute Statement

The Execute Statement operation (POST /sql-editor/v1/statement) runs the specified SQL statement.

The required statement parameter defines a SQL statement.

The SQL Editor accepts Apache Spark SQL only. Queries are parsed against the Apache Spark 4.1 SQL grammar and validated against the Apache Spark SQL 4.0.1 built-in function allowlist. Any construct in the Spark SQL Reference is accepted; any vendor-specific extension is rejected at validation time before the query runs. To learn more, see Apache Spark SQL Reference.

The optional executionContext can be used to provide catalog and schema information.

The operation takes three optional parameters:

{
  "executionContext": "string",
  "statement": "string",
  "rowLimit": 0
}

Get Statement Status

The Get Statement Status operation (GET /sql-editor/v1/statement/{statement_id}) returns the status of specified SQL statement.

The required statement_id path parameter specified the ID of the statement.

Get status and, optionally, result chunks for a previously submitted SQL statement. If a next-token is provided, the corresponding result chunk is fetched.

{
  "statementId": "string",
  "status": "string",
  "result": {
    "nextToken": "string",
    "rowCount": 0,
    "data": [[{}]],
    "metadata": [
      {
        "name": "string",
        "type": "string"
      }
    ]
  },
  "error": {
    "code": "string",
    "message": "string"
  },
  "duration": 0
}

Validate Statement

The Validate Statement operation (POST /sql-editor/v1/statement/validate) validates the specified SQL statement.

Validates whether a SQL statement uses only portable Spark SQL syntax. Returns a result indicating whether the statement is accepted or denied, without executing it.

{
  "statement": "string"
}

Download SQL Result

The Download SQL Result operation (POST /sql-editor/v1/download-sql-result) executes the specified SQL statements and creates a job to download the result.

Submits a workflow job that executes the given SQL statement and produces a downloadable result file. Returns a workflow ID to track progress.

The required x-rms-requestid header parameter returns 202 Accepted and initiates a job. The request has been successful but the process continues in background.

The response body returns the executionContext and statement:

{
  "executionContext": "string",
  "statement": "string"
}

The response body returns the executionContext and statement:

Delete SQL Statement

The Delete SQL Statement operation (DELETE /sql-editor/v1/statement/{statement_id}) cancels the specified SQL statement.

Get Execution History

The Get Execution History operation (GET /sql-editor/v1/history) returns a log of the client's execution history.

{
  "data": [
    {
      "statement": "string",
      "status": "string",
      "executionTimeMs": 0,
      "submittedTime": "2026-07-01T02:01:05.245Z",
      "rowCount": 0
    }
  ],
  "metadata": {
    "totalCount": 0
  }
}

List Scripts

The List Scripts operation (GET /sql-editor/v1/scripts) returns a list of scripts.

A script is a named, saved SQL file stored in the SQL Editor workspace. Each script contains one or more Apache Spark SQL statements and may include script-scoped variables declared with DECLARE OR REPLACE VARIABLE statement. Scripts do not persist variable values across executions; variables are re-initialized each time the script runs.

This operation supports query parameters that enable the filtering and sorting of responses.

The response returns information about the scripts that match the filter parameters.

{
  "totalMatchCount": 0,
  "children": [
    {
      "id": 0,
      "name": "string",
      "type": "script",
      "folderId": 0,
      "createdAt": "2026-07-01T02:06:46.372Z",
      "modifiedAt": "2026-07-01T02:06:46.372Z"
    }
  ]
}

Get Script

The Get Script operation (GET /sql-editor/v1/scripts/id) returns the specified script.

A script is a named, saved SQL file stored in the SQL Editor workspace. Each script contains one or more Apache Spark SQL statements and may include script-scoped variables declared with DECLARE OR REPLACE VARIABLE statement. Scripts do not persist variable values across executions; variables are re-initialized each time the script runs.

The response returns information about the specific script including its content.

{
  "id": 0,
  "name": "string",
  "type": "script",
  "folderId": 0,
  "createdAt": "2026-07-01T02:04:41.569Z",
  "modifiedAt": "2026-07-01T02:04:41.569Z",
  "content": "string"
}

Create Script

The Create Script operation (POST /sql-editor/v1/scripts) creates a script.

A script is a named, saved SQL file stored in the SQL Editor workspace. Each script contains one or more Apache Spark SQL statements and may include script-scoped variables declared with DECLARE OR REPLACE VARIABLE statement. Scripts do not persist variable values across executions; variables are re-initialized each time the script runs.

Scripts are subject to the June 2026 migration requirement: any saved script that uses constructs no longer accepted (for example, VACUUM, OPTIMIZE, pipe syntax, or T-SQL–specific functions) must be updated to use standard Apache Spark SQL before September 30, 2026.

{
  "name": "string",
  "folderId": 0,
  "type": "string"
}

Replace Script

The Replace Script operation (Update /sql-editor/v1/scripts/{scriptid}) replaces the content of the specified script, i.e. the SQL statement itself.

{
  "name": "string",
  "content": "string"
}

The response returns information about script.

{
  "id": 0,
  "name": "string",
  "type": "script",
  "folderId": 0,
  "createdAt": "2026-07-01T02:10:08.476Z",
  "modifiedAt": "2026-07-01T02:10:08.476Z",
  "content": "string"
}

Patch Script

The Patch Script operation (PATCH /sql-editor/v1/scripts/{scriptid}) updates the specified script.

This operation supports renaming the script, moving the script to another folder in the same catalog, or to update the SQL statement itself.

The request body accepts three parameters: name, folderId, content:

{
  "name": "string",
  "folderId": 0,
  "content": "string"
}

Delete Script

The Delete Script operation (PATCH /sql-editor/v1/scripts/{scriptid}) deletes the specified script.

List Dashboards

The List Dashboards operation (GET /v1/reporting/dashboards) returns a list of dashboards.

A dashboard is a published version of a data analysis created in the Risk Data Lake reporting environment. Dashboards are interactive visualizations built from flexible reporting datasets and tenant data. Once published, a dashboard can be shared in the Shared folder, making it accessible to users with the Risk Data Lake Consumer or Contributor role.

This operation returns the dashboards available to the authenticated user. In the Data Explorer, Dashboards and Analyses are accessible under the Reporting area; shared dashboards are visible to users with the Risk Data Lake Consumer or Contributor role.

{
  "dashboards": [
    {
      "dashboardId": "string",
      "dashboardName": "string",
      "category": "string"
    }
  ]
}

For each dashboard the response returns the dashboardId, dashboardName, category:

Get Dashboard Embed URL

The Get Dashboard Embed URL operation (GET /v1/reporting/dashboards/{dashboardId}) returns the specified dashboard.

This required dashboardId query parameter specifies the ID of the dashboard. This operation also accepts an optional additionalDashboardIds query parameter that specifies an array of dashboard IDs. The optional origin header parameter specifies the calling application (scheme and host, for example https://app.example.com). Used to validate and generate an embed URL specific to the requesting origin.

The operation returns an embed URL for viewing a specific published dashboard. Dashboards published to the Shared folder are accessible in external Moody’s Insurance Solutions applications when organizations license both Risk Data Lake and those applications.

{
  "dashboards": [
    {
      "dashboardId": "string",
      "dashboardName": "string",
      "category": "string"
    }
  ]
}

The response returns details about the dashboard:

Get Analytics Design Environment URL

The Get Designer Embed URL operation (GET /v1/reporting/embed-url) returns the URL of the Analytics Design Environment.

The Analytics Design Environment URL provides Risk Data Lake Contributors the ability to create and modify analyses of tenant data dashboard datasets. The Analytics Design Environment provides access to flexible reporting datasets, tenant data dashboard datasets, and Risk Data Catalog source tables as visualization data sources.

The response returns the embedUrl, expirationTime, and status:

{
  "embedUrl": "string",
  "expirationTime": "string",
  "status": "string"
}

The response returns details about the dashboard:

Health Check

The Health Check operation (GET /health) checks the health of Risk Data Lake.