CMMS API Integration Patterns: How to Connect CMMS to ERP, OEE, and SCADA Without Breaking Things

Key takeaways

• CMMS API integration = connecting CMMS to ERP, OEE platform, SCADA, and other systems.
• Four common patterns: REST sync, webhooks, message queue, scheduled batch.
• Match the pattern to the integration: real-time WO events use webhooks; nightly parts inventory uses batch.
• Most CMMS integrations fail not from API design but from data quality mismatch between systems.
• Common integrations: WO from OEE downtime, parts from ERP, asset hierarchy sync, labor and cost to ERP.

Short answer: CMMS integration with other systems uses four common API patterns: REST for synchronous calls, webhooks for event-driven updates, message queue for asynchronous reliable delivery, and scheduled batch for high-volume periodic sync. The right pattern depends on the use case. Most integration failures come from data quality mismatch between systems rather than API design problems. See also MES vs CMMS.

The four patterns

1. REST API. Synchronous request-response. Get this work order. Update that asset. Suitable for user-driven actions and small operations.

2. Webhooks. Event-driven push. CMMS notifies subscriber when a WO is created, completed, or canceled. Suitable for real-time downstream updates.

3. Message queue. Asynchronous reliable delivery. CMMS publishes events to a queue; subscribers process at their own pace. Suitable for high-volume or unreliable downstream systems.

4. Scheduled batch. Periodic bulk sync. Nightly export of all PMs to ERP. Suitable for high-volume data with relaxed latency requirements.

Which pattern for which integration

OEE downtime → CMMS WO creation: webhook from OEE to CMMS, immediate.

CMMS WO completion → ERP cost posting: webhook from CMMS to ERP, near-real-time.

ERP parts inventory → CMMS: scheduled batch (nightly) for the full catalog, REST for individual lookups.

SCADA tag values → CMMS condition monitoring: message queue (MQTT) for high-volume stream.

Asset hierarchy sync between systems: scheduled batch (nightly) or REST on change.

User-driven WO creation: REST API.

Where integration fails

Not in the API design but in:

• Asset hierarchy mismatch (CMMS and ERP have different structures).
• Naming conventions differ across systems.
• Timing mismatch (CMMS expects daily; ERP delivers weekly).
• Data quality issues that surface only at integration.
• Field length differences that truncate silently.

These are data problems, not technical problems. Solve them upfront.

Common integration cases

1. OEE downtime → CMMS WO.

• OEE detects downtime event.
• If above threshold, OEE sends webhook to CMMS.
• CMMS auto-creates WO with asset, time, reason code.
• Maintenance dispatches.
• WO closure posts back to OEE for context.

2. ERP parts inventory.

• ERP exports parts catalog and inventory levels nightly.
• CMMS imports and reconciles.
• Individual parts lookups during WO execution use REST.

3. CMMS labor and cost to ERP.

• WO completion includes labor hours and parts cost.
• CMMS webhooks to ERP cost center accounting.
• ERP records the cost against the appropriate budget.

Authentication patterns

• API key. Simple, common for system-to-system. Rotate periodically.
• OAuth. User-driven access control. More setup but better for user-facing integrations.
• Mutual TLS. Both ends authenticate via certificates. High security; more complex.

Choose based on integration sensitivity.

Error handling

Three common patterns:

• Retry with backoff. Transient failures resolve themselves.
• Dead letter queue. Failed messages park for investigation.
• Compensating transactions. If step 2 of a multi-step integration fails, step 1 is reversed.

Production integrations need all three.

Common mistakes

1. REST for everything. Synchronous calls block; high-volume integrations need async.

2. No error handling. Failures pile up silently.

3. Tight coupling. Change in one system breaks the integration. Loose coupling tolerates change.

4. No monitoring. Integration silently fails; problems compound.

Documentation requirements

Every integration needs:

• API specification (OpenAPI / Swagger).
• Data mapping document.
• Error handling specification.
• SLA expectations.
• Owner contact info.

Without this, integrations become tribal knowledge that breaks on personnel changes.

How a modern CMMS supports integration

A modern CMMS offers REST APIs, webhooks, message queue support, batch import/export, and well-documented integration specifications.

Fabrico's CMMS provides REST, webhooks, message queue support, batch sync, and OpenAPI documentation for ERP, OEE, SCADA, and other integrations.

See how Fabrico captures this automatically — explore OEE for manufacturing or book a demo.

Related reading

• MES vs CMMS
• CMMS Asset Hierarchy
• CMMS Rollout Pitfalls
• CMMS vs FSM

Frequently asked questions

Is REST always the right choice?

No. Real-time events benefit from webhooks; high-volume from message queues; bulk from batch.

Should CMMS push to ERP or pull?

Push for time-sensitive (WO closure cost); pull for bulk reference (parts catalog).

What is the biggest integration failure mode?

Data quality mismatch between systems. Solve upfront.

Should I build custom integrations or use middleware?

Middleware (MuleSoft, Boomi) helps at scale. Direct integration works for simple cases.

How do I monitor integration health?

Track delivery rate, latency, error rate, and dead-letter queue depth. Alert on anomalies.