Reference · built on requestConnectorBuilding management platforms

KODE OS

Buildings, devices, points, history, and AssetOps work orders from KODE OS, with point writes you approve.

About

KODE OS is a building operations platform from KODE Labs. It holds a portfolio of buildings, each with areas, datasources (the BAS, meter, IoT, and third-party integrations feeding it), devices, and points. A point is either a data point such as a temperature reading or a control point such as a fan command. AssetOps adds work orders with categories, issue types, vendors, teams, and priorities. The Public API is REST with JSON bodies at api.kodelabs.com/kodeos/api/v1, secured by OAuth 2.0 service accounts.

Through Fibric, an operator reads points and history, then proposes a point write with a priority and duration, or drafts a work order. Nothing is sent until you approve it, and the note on each write says why.

This is a reference listing. It documents what Fibric would read from KODE OS and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Buildings in the service account's portfolio and the areas inside each, paged with page and limit
  • Datasources per building: the BAS, IoT, meter, and third-party integrations feeding KODE OS
  • Devices per building, each with its points, point kinds, and paths
  • Points by building or device, or up to 200 pointIds per call to the points query endpoint
  • Timeseries per building filtered by deviceId, pointId, from, and to, plus the latest value for up to 200 points
  • Point write fields: which fields a write takes, their data types and options, and which are MANDATORY
  • AssetOps work orders with comments, attachments, and the valid vendors, teams, assignees, categories, issue types, and priorities

Proposed actions

  • Target capability: propose a point write with priority, duration, value, and a note, sent only after you approve it
  • Target capability: propose a batch of point writes through the datasource batch-write endpoint
  • Target capability: draft a CORRECTIVE_MAINTENANCE or SERVICE_REQUEST work order with category, issue type, priority, and assignees
  • Target capability: update a work order's dates, title, description, vendor, team, or assignees with the full payload
  • Target capability: invoke a datasource action such as DISCOVER once you approve it

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Propose a setpoint override that expires

    When a zone sits off setpoint, the operator drafts a write with priority, a duration, and the value, plus a note. You approve; the override ends on its own.

    With Setpoint Drift

  • Raise a filter-change work order from run hours

    Read fan run-time points as timeseries, and when hours pass the threshold, draft a CORRECTIVE_MAINTENANCE work order with the right category, issue type, and team.

    With Filter Change

  • Start equipment later on mild mornings

    Compare outside air and zone temperature history with the schedule, then propose a later start written to the control point for that morning only.

    With Optimal Start

  • Keep work orders from going stale

    List AssetOps work orders by dueDate and priority, read their comments, and propose the ones to chase or reassign.

    With Work Order Aging

Requirements

  • A KODE OS environment (for example acme.kodelabs.com) and a Service Account with the permissions the connector needs
  • A Private Key JWT credential with its public key registered on the Service Account, or a Client Secret
  • Access tokens from the token endpoint, sent as a Bearer header on every request and revoked when no longer needed
Authentication
OAuth 2.0 client credentials on a KODE OS Service Account, by Private Key JWT (RS512) or Client Secret, exchanged at api.kodelabs.com/oauth2/v1/token for a one-hour Bearer token.

Limits

  • Rate limits per environment: 5 requests per second, 100 per minute, 500 per hour; any exhausted window returns 429
  • Timeseries queries must span 2 days or less; longer history takes repeated calls
  • Point queries and latest-value reads take at most 200 pointIds per request
  • Work order updates require the full payload and cannot change workType or linkedSource

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request KODE OS ↗

Questions and answers

How does a point write work in KODE OS?
In two steps. First read the point's write fields, which list each field, its data type, its options, and whether it is MANDATORY, OPTIONAL, or CONDITIONAL. Then post actions such as priority, duration, and value, with an optional note. Fibric shows you the exact payload before it sends.
Which authentication does the connector use?
OAuth 2.0 client credentials on a KODE OS Service Account. Private Key JWT signed with RS512 is the method KODE Labs recommends; a Client Secret with client_secret_basic or client_secret_post also works. Tokens come from api.kodelabs.com/oauth2/v1/token, last 1 hour, and can be revoked early.
How far back can Fibric read history?
Each timeseries call covers a from-to window of 2 days or less, filtered by building, device, or point. Longer ranges take several paced calls under the 500-per-hour limit. History can also be pushed into a KODE API datasource with a unix timestamp per value.
Ask about KODE OS

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.