Frameworks

The Frameworks endpoints expose the framework registry your organization has set up: which frameworks you operate under, their versions, the hierarchical structure of each version, and the coverage links that connect framework requirements to controls, evidence, and other work in your workspace.

This is a read-only surface in v1. Creating, updating, and retiring frameworks happens in the Novantra UI (see the Frameworks user guide).

For shared conventions (auth, errors, pagination, ID format, reason field), read v1 conventions first.

Scope required

Endpoints

List frameworks

GET /api/v1/governance/frameworks
Authorization: Bearer <access-token>

Query parameters:

Response:

{
  "frameworks": [
    {
      "id": "frwk_01HXY...",
      "frameworkKey": "info-sec",
      "name": "Information Security Standard",
      "description": "International information security management framework.",
      "status": "active",
      "sourceKind": "standard",
      "createdAt": "2026-04-15T08:21:43.000Z",
      "updatedAt": "2026-05-20T11:03:12.000Z"
    },
    {
      "id": "frwk_01HXZ...",
      "frameworkKey": "internal-patient-policy",
      "name": "Internal Patient Data Policy",
      "description": "Board-approved organization policy on patient data handling.",
      "status": "active",
      "sourceKind": "internal",
      "createdAt": "2026-04-15T08:25:11.000Z",
      "updatedAt": "2026-04-15T08:25:11.000Z"
    }
  ],
  "pagination": {}
}

List framework versions

GET /api/v1/governance/frameworks/versions
Authorization: Bearer <access-token>

Query parameters:

Response:

{
  "versions": [
    {
      "id": "fver_01HXY...",
      "frameworkId": "frwk_01HXY...",
      "versionKey": "2024",
      "versionLabel": "2024 publication",
      "status": "active",
      "sourceKind": "standard",
      "createdAt": "2026-04-15T08:22:01.000Z",
      "updatedAt": "2026-04-15T08:22:01.000Z"
    }
  ],
  "pagination": {}
}

List framework nodes

GET /api/v1/governance/frameworks/nodes
Authorization: Bearer <access-token>

Framework nodes are the hierarchical structure inside a version (domains, sections, controls, requirements). They can nest arbitrarily; parent-child is expressed via parentNodeId.

Query parameters:

Response:

{
  "nodes": [
    {
      "id": "fnod_01HXY...",
      "frameworkVersionId": "fver_01HXY...",
      "parentNodeId": null,
      "nodeKey": "domain-mgmt",
      "nodeType": "domain",
      "referenceCode": "MGMT",
      "title": "Information Security Management",
      "description": "Top-level governance domain.",
      "status": "active",
      "sortOrder": 100,
      "createdAt": "2026-04-15T08:31:00.000Z",
      "updatedAt": "2026-04-15T08:31:00.000Z"
    },
    {
      "id": "fnod_01HXZ...",
      "frameworkVersionId": "fver_01HXY...",
      "parentNodeId": "fnod_01HXY...",
      "nodeKey": "mgmt-1",
      "nodeType": "section",
      "referenceCode": "MGMT 1",
      "title": "Information Security Steering Committee",
      "description": "Establishment of and reporting from the information security steering committee.",
      "status": "active",
      "sortOrder": 110,
      "createdAt": "2026-04-15T08:31:15.000Z",
      "updatedAt": "2026-04-15T08:31:15.000Z"
    }
  ],
  "pagination": {}
}

nodeType is free text describing what kind of node this is in the framework’s own vocabulary (domain, section, control, requirement, family, etc.). Don’t hardcode a fixed list in your client; new node types may appear in different frameworks.

List coverage links

GET /api/v1/governance/frameworks/coverage-links
Authorization: Bearer <access-token>

Coverage links connect a framework node to a record in another module (a control, an evidence claim, etc.).

Query parameters:

Response:

{
  "coverageLinks": [
    {
      "id": "fcvl_01HXY...",
      "frameworkNodeId": "fnod_01HXZ...",
      "targetModuleKey": "controls",
      "targetResourceType": "control",
      "targetResourceId": "ctrl_01HXY...",
      "targetVersionId": null,
      "coverageRole": "implements",
      "coverageStatus": "active",
      "createdAt": "2026-04-20T14:08:33.000Z",
      "updatedAt": "2026-04-20T14:08:33.000Z"
    }
  ],
  "pagination": {}
}

coverageRole is one of implements, evidences, informs, supersedes. targetModuleKey and targetResourceType together identify the kind of object the framework node is connected to; targetResourceId is the specific record. See Attaching records to governed subjects in the conventions page for the shape.

Real-case integration: pulling framework structure into a warehouse

A financial services firm wants to maintain a parallel view of its compliance landscape in its enterprise data warehouse, alongside customer activity, risk metrics, and operational telemetry. Their data team writes a nightly job that walks Novantra’s Frameworks endpoints and lands the rows in their warehouse.

The job:

1. Calls GET /api/v1/governance/frameworks and stores each row in a dim_compliance_framework table keyed by id.
2. For each framework, calls GET /api/v1/governance/frameworks/versions?frameworkId={id} and stores versions in dim_compliance_framework_version.
3. For each version, calls GET /api/v1/governance/frameworks/nodes?frameworkVersionId={id}, paginating until exhausted, and writes nodes into dim_compliance_framework_node with parent_node_id preserved so the warehouse keeps the hierarchy.
4. Pulls coverage links with GET /api/v1/governance/frameworks/coverage-links and lands them in fact_compliance_coverage_link.

The service account is granted exactly governance.frameworks:read. The job runs nightly, uses cursor pagination, and respects X-RateLimit-Remaining to throttle if the read volume grows.

Downstream, the data team can join warehouse facts (incidents, audit events) against framework nodes to answer questions like “show me every control-related ticket from last quarter, broken down by framework section.”

Related

• Frameworks user guide - what the frameworks module does and when to reach for it.
• v1 conventions - shared request and response patterns.
• Authentication - service accounts and scopes.