Integrations: configuration or development?

If you already run a facility-management system, a BMS historian, or a monitoring platform, and you want that data to show up on the building graph — for most cases this is configuration, not a development project.

The rest of this section is written for that reader: someone who is not building a module and does not want to. (If you are building one, start at Getting started instead.)

Three levels, and what each actually costs

	What you do	Who does it	Effort
1. Post data over HTTP	Your system sends values keyed by a room identifier to one endpoint. No SDK, no package, no module.	Whoever maintains the source system	Hours. One endpoint, one payload shape.
2. No-code flow builder	Wire it in n8n with our Building OS nodes: schedule, retry, transform, branch — all in the tool's UI.	An operations engineer	Hours, and no code at all.
3. Your own module on the SDK	Only when you need your own screen inside the platform and your own logic behind it.	A developer team	Days, plus a release cycle.

The common case is level 1. "Our tickets and our sensor readings should appear on the plan, coloured by status" is one endpoint per data set. Nobody writes platform code — not you, not us.

Level 3 exists because some partners genuinely want to ship a product surface of their own inside Building OS. It is not the price of admission for getting your data in.

Which level do you need?

• "I want our rent status / occupancy / CO₂ per room to colour the floor plan." → Level 1, Into the twin.
• "Our monitoring system streams pressure and temperature readings and I want them live on the twin." → Level 1 (telemetry), same page.
• "Same thing, but I'd rather not write a cron job or a retry loop." → Level 2, same contract, driven from n8n. (Readings can also arrive over MQTT — see Into the twin.)
• "When a ticket changes state in your system, our system should hear about it." → Out of the twin — read it before you plan, because outbound is thinner than inbound today and that page says exactly where the edges are.
• "Tickets should exist in both systems and stay in step." → Both ways, which is mostly about deciding which side owns the record before you write anything.
• "I want our own workspace, with our own screens, inside Building OS." → Level 3: Your first module.

What "one endpoint" looks like

A data layer is one value per room, on top of the building graph. Create the layer once, then upload values as often as you like:

# 1. Create the layer (once)
curl -X POST "$TV_API/api/v1/buildings/$BUILDING_ID/data-layers" \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"key":"fm-open-tickets","name":"Открытые заявки","valueType":"NUMBER"}'

# 2. Upload values (as often as you like) — keys are room identifiers
curl -X PUT "$TV_API/api/v1/buildings/$BUILDING_ID/data-layers/$LAYER_ID/values" \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"keyBy":"externalId","values":{"3lPQxG$0v9zRZ1mB7kYtE2":4,"1aBcDe$FgHiJkLmNoPqRs":0}}'

That is the whole integration for a "how many open tickets per room" layer. The full contract — value types, bulk limits, what comes back — is on Into the twin.

Where the line falls

We do	You do
The building graph: rooms, storeys, equipment, and their identifiers.	Decide which of your records maps to which room.
The endpoints, their auth, their validation, their storage.	Call them, on your own schedule, from your own system.
Rendering the layer on the 2D plan and the BIM model.	Choose the value type and (optionally) the legend.
Issue the credentials and the sandbox.	Keep the credentials in your secret manager.

You do not need our people on the call to add a layer, and you do not need to wait for a platform release. Once you hold a credential and a buildingId, everything on these pages is available to you.

In this section

• Into the twin — pushing data in: layers keyed by room, and time series from sensors.
• Out of the twin — webhooks, the live event socket, and an honest account of what is not yet deliverable outward.
• Both ways — syncing tickets, and deciding which side owns the record.
• Identity — how a row in your database finds the right room. This is where integrations actually break.
• Getting access — credentials, a sandbox, and what is gated today.