Integrations & API

The CMMS that connects
to the rest of your stack.

A CMMS doesn't live in isolation. Your vendors are in your ERP. Your users come from your identity provider. Your sensor data comes from hardware you already own. We built the integration layer first — not as an afterthought.

Our thesis

System of Record — the foundational concept

For every entity in the system, exactly one system is the authoritative source. When your vendors are mastered in NetSuite, we sync them — but NetSuite owns the legal record. When someone edits the vendor name in our UI, we block it and point them to the source of truth.

Get this wrong and you get data drift, mysterious overwrites, and angry phone calls at month-end. We model it explicitly, per entity type, per hub — with field-level ownership for cases where two systems each own different parts of the same record.

Internal SoR

We're authoritative. You create and edit here.

e.g. Work orders, PM templates, criticality scores, audit log

External SoR (full)

Another system owns the record. Our copy is read-only with a "managed by" badge.

e.g. Vendors from NetSuite, users from SCIM/Workday

External SoR (field-level)

Ownership split per field. NetSuite owns name and tax ID; we own the maintenance contact.

e.g. ERP vendors with CMMS-specific fields

Baked API

Anything you can do in the app,
you can do in the API.

API parity isn't a feature — it's an architectural commitment. We build the API and the UI against the same domain layer. There are no UI-only shortcuts, no undocumented endpoints the app uses but customers can't, no features that only work through the browser.

This means your automation team, your data team, and your integration partners have full access to everything — not a subset of the product with “API access” slapped on it.

  • Every object accessible via REST — assets, work orders, PMs, parts, meters, users, vendors
  • Versioned endpoints — v1 is stable; breaking changes only in new major versions
  • Webhook-driven events for all state changes — no polling required
  • Service account tokens with scoped permissions for automations and integrations
  • Rate limits published transparently — no hidden throttling surprises
  • OpenAPI spec published — generate client SDKs in any language
REST API — same as the UI

# Create a work order

POST /api/v1/work-orders

# Anything the UI can do

asset_id: "asset_abc123"

type: "corrective"

priority: "high"

assigned_to: "user_xyz"

failure_code: "MEC-BRG-FAT"

# Response

id: "wo_1047"

status: "open"

created_at: "2026-05-04T09:31:00Z"

# Same permissions model as the UI

# Same audit log entry as the UI

# No second-class endpoints

For AI-native teams

MCP server — point Claude at your CMMS

We expose Sympl CMMS as a Model Context Protocol (MCP) server. Connect Claude, Cursor, or any MCP-compatible AI tool directly to your maintenance data — and let it read, query, and act using natural language.

Your reliability engineer asks: “Find every pump that failed within 90 days of installation across all sites, with the supplier name.” Claude executes the right API calls against your actual data and returns the answer. You keep your preferred AI tool; we expose the data and actions cleanly.

Setup

1
Settings → Connect AI Assistant → create MCP token
2
Add token to your Claude / Cursor MCP config
3
Your CMMS data and actions are available to your AI tool

MCP tokens carry the permissions of the user or service account they are issued to — not a flat API key with blanket access. Every MCP-initiated read or write is attributed in the audit trail just like a UI action.

📖 Resources (read)

list_assetsget_assetsearch_assetsget_work_ordersget_pm_templatesget_meter_readingsrun_report

✏️ Tools (write)

create_work_orderupdate_work_orderassign_work_orderrecord_meter_readingcreate_assetupdate_asset_criticality

💬 Prompts

"Summarize this asset's failure history""Draft a compliance evidence pack for audit X""What PMs are overdue on the west campus?"

Tool catalog is generated from the OpenAPI spec — new endpoints become MCP tools automatically.

Workflow engine

When X happens under Y conditions, do Z.

A first-class workflow engine built into the platform — not a separate product, not a Zapier dependency. Configure automations in plain language with a card-based builder. Every customer's maintenance process is slightly different; workflows are how you make Sympl CMMS yours.

The model is Event → Conditions → Actions. A domain event fires (PM overdue, work order completed, asset criticality changed). Conditions filter it (only Class A assets, only Site B, only failure code “seal leak”). Actions execute (assign a follow-up WO, notify a Slack channel, send an escalation email, call a webhook).

When

PM overdue by 7 days on a Criticality A asset

Then

Escalate to reliability manager + post to #maintenance-alerts Slack channel

When

Failure code "seal leak" recorded on a centrifugal pump

Then

Check if same failure in last 90 days → if yes, auto-create an RCA work order

When

Work order completed with parts used below reorder threshold

Then

Create a procurement task and notify the parts manager

When

Inbound webhook from SCADA alarm on asset

Then

Create high-priority work order against the alerting asset (human approval step)

Workflow builder

Active

Trigger

PM work order becomes overdue

Condition

Asset criticality = A or B

Overdue by ≥ 3 days

NotifyEmail reliability manager
NotifyPost to #maintenance-alerts
UpdateEscalate work order priority to Urgent

What workflows can trigger

EmailSlack messageWork order createWork order updateWebhook callEscalationProcurement task

Workflows that outgrow the builder extend via webhook out → Zapier / Make / n8n.

Event-driven

Webhooks in and out

Outbound webhooks fire on any state change — work order created, PM overdue, asset criticality changed, meter reading anomaly detected. Subscribe any endpoint.

Inbound webhooks accept events from BMS systems, SCADA, and telematics — an HVAC alarm from Schneider EcoStruxure becomes a high-priority work order automatically. Human approval step before auto-close.

  • Signed payloads with HMAC verification
  • Configurable retry with exponential backoff
  • Delivery log with status and response per event
  • Filter by entity type, event type, or site

Outbound event example

POST https://your-endpoint.com/cmms

event: "work_order.overdue"

work_order_id: "wo_1047"

asset: "Pump P-201"

priority: "high"

overdue_by_hours: 36

assigned_to: "Jane Smith"

Inbound — BMS alarm → WO

Schneider EcoStruxure → HVAC alarm: AHU-3 high temp

↓ Creates WO-1051 · Priority: High · Asset: HVAC AHU-3

Connect anything

Native connectors + iPaaS

Native integrations for the tools maintenance teams already use. iPaaS connectors for the long tail — if it's in Zapier or Make, it connects to Sympl CMMS.

Sl

Slack

Available

Work order notifications, PM reminders, and overdue alerts sent to channels or DMs

Pa

PagerDuty

Available

Incidents trigger work orders; work order close-out resolves the incident automatically

Ne

NetSuite

Available

Vendor and PO sync with field-level SoR assignment — NetSuite owns the legal record, we own the maintenance context

Sa

Samsara

Available

Fleet telematics feeds odometer and runtime readings directly into meter-based PM triggers

Za

Zapier

Coming soon

No-code automation for 6,000+ apps — trigger on WO events, create assets from form submissions

Ma

Make (Integromat)

Coming soon

Visual workflow builder for complex multi-step automations involving CMMS events

n8

n8n

Coming soon

Self-hosted iPaaS for teams that want automation without data leaving their infrastructure

SA

SAP / ERP

Roadmap

Work order completion data out, purchase order data in — configurable SoR per entity type

API authentication

Two token types. Same permissions model.

Every API call — whether from your automation, your MCP client, or your own script — goes through the same auth, permission checks, and audit log as the UI. We have two token types for different contexts.

User API keys

Tied to your identity

Generated per user in account settings. Carry exactly your permissions — the same RBAC rules that apply when you log into the UI. Actions are attributed to you in the audit log.

  • Personal scripts and one-off automations
  • Testing and development against your own data
  • MCP tokens tied to your CMMS identity
  • Revoked automatically when the user is deactivated

Best for: personal use, development, MCP sessions where you want the AI acting as you

Service accounts

Independent principals

Machine identities not tied to any person. Survive team changes, off-boarding, and role shifts. You define the permission scope at creation — narrower than any user account for least-privilege automation.

  • Production integrations — ERP sync, iPaaS, webhook consumers
  • Scope locked at creation (e.g. read:assets write:work_orders only)
  • Named descriptively — "NetSuite sync", "Zapier connector"
  • Survive staff turnover; rotate tokens without re-credentialing

Best for: production automations, native connectors, iPaaS, any integration that runs without a human present

Both token types appear in the audit log with their identity clearly attributed. No integration can exceed the permissions of the token that issued it.

Goes well with

Platform & Modules

Compliance, Workforce, Capital Planning modules

AI Controls

MCP server uses the same AI control settings

Data Portability

Export-first complements API-first

Talk to us about your integration requirements

ERP coexistence, SCIM provisioning, BMS webhook ingestion, MCP setup — we've thought through the hard cases.

Request a demo