整合

設施營運資料的整合, 進與出

透過 API、Webhook、匯出與專案範疇的實作,把 Infodeck 與設施團隊每天倚賴的系統連起來。

REST API、Webhook 與專案範疇實作。先做需求釐清。
app.infodeck.io
Integration paths
APIs, channels, and mapped data flows
api/v2
In product
REST API, webhooks, CSV, SSO
Configured
BMS, IoT, WhatsApp, LINE
Mapped
SAP, Oracle, legacy on-prem
Connected services
Bi-dir
REST API In product
Versioned endpoints OpenAPI spec, idempotent
Out
Event webhooks In product
Work orders, assets, requests, approvals Retries with exponential backoff
In
BMS / IoT protocols Configured
BACnet, Modbus, MQTT, OPC-UA Set up during onboarding
Out
Messaging channels Configured
WhatsApp, LINE, Telegram, Slack, Teams Configured for the deployment
Recent connector calls
WH
Webhook delivered
work_order.created, 200 OK
Just now
API
API request
GET /api/v2/assets
1m ago
BAC
BACnet event ingested
Chiller threshold, work request opened
12m ago
R
Webhook retry scheduled Backoff
External listener returned 502
18m ago
Audit log on every call TLS 1.3, AES-256 at rest
API Documentation →

Webhook 已送達

POST /work-orders, 200 OK

熟悉這幾個情境嗎?

"廠商承諾一鍵連接器,實際使用時就斷線"

"設施資料散落在 BMS、ERP、會計與試算表"

"範疇失控,因為沒人定義什麼是內建、什麼是實作"

"整合靜悄悄壞掉,直到報表錯了才發現"

在 Infodeck

REST API 與 Webhook 今天就能用,不需要先談範疇

CSV 匯入與匯出 涵蓋大多數團隊的資料搬運需求

BMS、IoT、身分與聊天 在實作階段設定

ERP、舊系統與本地系統 採專案範疇處理,先做需求釐清

三條實話路徑

內建、實作或 專案範疇

我們把產品內建、實作階段處理,以及需要專案範疇的事項分清楚。買方與業務在開始前就對齊,而不是事後才補。

1

產品內建

這些介面從上線第一天就可使用。有文件、有支援、不會因 Tenant 規模而改變。

  • REST API 含版本化端點
  • Event Webhook:工單、資產、需求、簽核
  • 營運紀錄涵蓋的 CSV 匯入與匯出
  • Google Workspace SSO
  • 電子郵件與應用內通知
2

在 Onboarding 由我方團隊設定

產品已具備的標準協定與工具,但需要對應到您的環境。實作是 Starter 以上各方案的標準項目。

  • BMS 與 IoT 協定:BACnet、MQTT、LoRaWAN(Modbus 與 OPC-UA 在 Roadmap)
  • Slack、Microsoft Teams 與簡訊派發規則
  • SAML SSO 提供者(Azure AD、Okta、其他)於實作階段設定
  • 排程式 CSV 或 SFTP 同步任務
3

先做需求釐清,再開始建

較大型的系統需要實際的計畫。我們會先確認可行性與工作量,再承諾範疇。沒有魔術連接器,沒有打勾就好的承諾。

  • SAP、Oracle、NetSuite、Microsoft Dynamics
  • 會計系統(Xero、QuickBooks、Sage)
  • 本地舊式 BMS、ERP 與客製 Middleware
  • 邊緣運算(隔離網段)與 AI 影像分析
app.infodeck.io/integrations
Webhook delivery API calls Sync jobs
200

work_order.created

POST https://example.com/hooks/wo

Just now
MSG

Requester update sent by channel

Fault status changed, tracking link delivered

2m ago
BAC

BACnet threshold event ingested

Chiller-03 temp > 28°C, work request opened

5m ago
Webhook listener active | audit log on every call
api/v2

API 與 Webhook

透過版本化的 REST 端點與 Event Webhook 推送與取出設施資料。冪等、有分頁、有文件。

身分與資料安全

傳輸 TLS、靜態 AES-256、Google Workspace SSO(SAML 提供者於實作階段設定)、可限制範圍的 API 金鑰,每一筆經驗證寫入皆有具名操作者的稽核紀錄。

專案範疇,不是空頭承諾

當連接器並非小事,我們會直說。先做需求釐清,再寫書面範疇,然後才開始建。

不同角色怎麼用

對每個團隊都 說實話

不灌水的承諾。每個角色從每條路徑可期待的事項:內建、實作或專案範疇。

IT 主管

範疇清楚,不會冒出意料外的整合

內建 API、Webhook 與 SSO 已能涵蓋大部分需求。其餘在需求釐清階段就講清楚,不會臨門一腳才補。

  • Google Workspace SSO(SAML 於實作階段設定)
  • 每筆經驗證寫入皆有稽核紀錄
  • 可限制範圍的 API 金鑰
營運經理

資料流到工作真正發生的地方

Webhook 在事件發生當下將設施事件推送到您的工具。ERP 與舊系統資料則透過專案範疇的同步處理。

  • 工單與簽核的 Event Webhook
  • 在實作階段設定 Slack 與 Teams 派發
  • 透過 API 或 CSV 匯出自訂儀表板
財務主管

不再人工複製貼上的成本資料

CSV 匯出已能應付月結。若需要更密集的對帳節奏,ERP 直接同步可在需求釐清時納入專案範疇。

  • 以 CSV 或 API 匯出成本報表
  • ERP 同步以專案範疇進行
  • 每筆匯出皆可稽核
開發者

API 優先,不會碰到意外的速率限制

REST API 含版本化端點、OpenAPI 3.0 規格與 Webhook 事件結構。

  • OpenAPI 規格在 docs.infodeck.io
  • 可限制範圍的 API 金鑰
  • 標準速率限制 Headers
今天的產品內建

整合的可用面, 直白說

不講「50+ 連接器」這種話。以下就是今天產品內建的範圍。任何更大的事項都是需求釐清後的專案範疇。

REST API

營運紀錄全面提供版本化 REST 端點。具分頁、冪等與標準錯誤格式。

Event Webhook

工單、資產、需求、簽核與佐證的事件推送,含指數退避的重試。

CSV 匯入與匯出

對資產、地點、使用者、工單與預防性保養排程進行批次匯入與匯出。

SSO

Google Workspace SSO 已就緒。Azure AD、Okta 與其他 SAML 提供者於實作階段設定。

BMS 與 IoT 協定

BACnet、MQTT 與 LoRaWAN Network Server(Modbus 與 OPC-UA 於 Roadmap)。在實作階段設定。

寫入稽核紀錄

每筆經驗證寫入皆記錄操作者、範圍、時間戳與 Payload Hash。

常見問題

整合 常見問題

誠實版,不是行銷版

Still have questions?

先做需求釐清,再寫範疇,再動工

告訴我們你想連接 什麼

我們會告訴您屬於內建、實作,還是專案範疇。沒有假連接器宣稱,也沒有意外加碼的範疇。

API 與 Webhook 文件在 docs.infodeck.io。較大規模的整合在需求釐清後納入專案範疇。

REST API
Event Webhook
傳輸 TLS + 靜態 AES-256
AWS multi-AZ