Myrspoven AI-API

myCoreAI exchanges data and setpoints with each building over one of a few surfaces — the first-party Myrspoven AI-API, a third-party BMS/SCADA vendor API, or the Myrspoven edge running on-premise. This page describes each surface and points to vendor documentation where a third party owns the API.

For the conceptual data-flow model, see Getting started with system integration.

Available API surfaces

Myrspoven AI-API (first-party)

The Myrspoven cloud exposes a first-party HTTP API for exchanging building data with myCoreAI — reading current values and setpoints, discovering signals, writing setpoints, and uploading signal data. A connector on the building side integrates by calling this API; for example, the SmartConnector running in Schneider EcoStruxure Building Operation (EBO) uses it to read optimized setpoints and push building values back.

The API is documented in the OpenAPI reference in this section, which is authoritative for endpoints, request/response schemas, and authentication.

Third-party BMS/SCADA APIs

Some BMS and SCADA platforms expose their own HTTP or vendor API — for example Siemens Desigo and Web Port. Where one is used, myCoreAI integrates over that API to discover points, read real-time and historical values, and write setpoints. The API surface — endpoints, schemas, parameter formats — is owned by the vendor, and the vendor's documentation is the authoritative reference. Integration scope, credentials, and enablement are arranged with Myrspoven during onboarding.

Myrspoven edge (on-premise)

Where connecting through a connector or a reachable vendor API isn't viable, the Myrspoven edge runs in the building owner's environment, connects to the BMS locally, and exchanges data with the Myrspoven cloud. The edge communicates outbound only — it pulls the setpoints and work it needs and posts values and results back — so no inbound firewall openings are required on the building side.

Authentication and credentials

The Myrspoven AI-API uses OAuth2 bearer tokens. A client ID and secret are issued by Myrspoven and shared through a secure channel — never over email or chat. The OpenAPI reference documents the token flow.

Where a third-party vendor API requires authentication (typically a service account for write access), credentials are created on the vendor side and shared with Myrspoven through a secure channel. Read-only endpoints on some platforms operate without authentication. Writes always require a dedicated service account.

Required scopes and permissions are specified by Myrspoven per integration during onboarding.

Environments

Integrations are configured per building against a single production environment. Changes that would affect a live building are coordinated with Myrspoven, and the safe way to test is to pause writes for the building under test.

Error handling

For the first-party Myrspoven AI-API, response codes and error schemas are documented in the OpenAPI reference. For third-party surfaces, error handling follows the conventions of the vendor that owns the surface. When myCoreAI cannot reach the BMS it stops writing setpoints and the BMS continues to run on its own logic — the building keeps operating normally; only optimization pauses until the connection is restored.

Rate limits

Read and write cadence is agreed per building during startup. Reads typically run every one to five minutes; setpoint writes run on a fixed cadence — typically every 15 minutes — stepping through the latest optimization output. Where a third-party vendor imposes its own rate limits, they are documented by the vendor and tuned in coordination with Myrspoven.

Getting help

For integration needs beyond the surfaces described here, contact Myrspoven directly.