Every facility team that connects a CMMS to another system eventually faces the same decision: write the integration yourself, or use middleware to do it. Both can work, and both can become expensive when chosen for the wrong reasons. The real cost sits in maintenance, monitoring, and change, not in the first connection. A sound API strategy starts with clear criteria, and it helps to begin with a CMMS that exposes clean asset and work order data so that either path has solid records to build on.
Facility API Strategy
When to Build, When to Buy Middleware
Integration cost is decided long before code is written. Use five practical criteria to choose between custom APIs and an integration platform for your facility systems.
Build
Custom code, full control, your team owns it
or
Middleware
Connectors and tooling, shared responsibility
What Facility Integrations Actually Involve
- Work orders and assets exchanged with a building management system or IoT platform.
- Purchase orders, invoices, and parts data shared with finance and procurement systems.
- Employee, vendor, and location records synchronized from HR and real estate tools.
- Tenant requests, badge or visitor data, and energy meters feeding into maintenance workflows.
Why the decision is harder than it looks
A single integration is easy to justify. Ten integrations across several sites, each with different vendors and versions, create an ongoing operational workload.
Definitions Worth Agreeing On
API
A defined interface that lets one system read or write data in another.
Middleware
Software that sits between systems to move, transform, and route data.
iPaaS
Cloud integration platform with connectors, mapping tools, and monitoring, offered as a service.
API gateway
A control point for security, traffic limits, and access to APIs you publish.
These are not the same thing
An API gateway manages access to your own interfaces. An iPaaS builds and runs integrations between systems. Many projects need one, both, or neither.
The Five-Criteria Decision Framework
1
Number and variety of endpoints
Two stable systems favor a direct build. Many systems, many vendors, or frequent additions favor middleware with prebuilt connectors.
2
In-house skills and capacity
Building is viable only if developers are available for support years from now, not just for the launch.
3
Change frequency
Vendor updates, API version changes, and new sites create rework. Middleware often absorbs some of that change.
4
Security and compliance needs
Consider authentication, audit logs, data residency, and who approves access to building and business systems.
5
Total cost over time
Compare license, development, hosting, monitoring, and support across three to five years, not the launch invoice.
Scoring Guide: Which Way Does Each Criterion Lean?
| Criterion | Leans Toward Build | Leans Toward Middleware |
|---|---|---|
| Endpoints | One or two stable, well-documented systems | Many systems, mixed vendors, growth planned |
| Skills | Dedicated developers with support time | Small IT team or reliance on contractors |
| Change | Rare updates and predictable schedules | Frequent version changes or new sites |
| Security | Highly specific controls you must own | Standard controls and shared audit tooling |
| Cost | Low volume and simple logic | Many flows where reuse spreads the cost |
How to use the table
Score each row for your situation. If most rows lean the same way, the decision is clear. Mixed results suggest a hybrid approach.
The Hidden Costs on Each Side
Custom Build
- Ongoing maintenance when either system changes.
- Error handling, retries, and monitoring that must be written and staffed.
- Documentation and knowledge held by a few people.
- Security reviews and patching handled internally.
Middleware
- Subscription costs that grow with connectors or volume.
- Vendor dependency and a learning curve for the platform.
- Connectors that cover common cases but may miss custom fields.
- Data passing through another provider, which needs review.
A Simple Decision Path
Do the systems already offer a supported connector or native integration?
If yes, use it first. Custom work should fill gaps only.
Is the flow simple, stable, and limited to two systems?
A small direct API integration may be the leanest choice.
Will you add systems or sites within two years?
Favor middleware or a shared integration layer to avoid repeating work.
Can you support and monitor custom code for the long term?
If not, treat build as high risk and reconsider.
Start With Clean Maintenance Data
Reliable integrations depend on consistent assets, locations, and work order records. Oxmaint helps you organize that foundation before you connect anything.
API Design Practices That Lower Long-Term Cost
- Use stable identifiers for assets, locations, and vendors, and never depend on names alone.
- Prefer webhooks or event notifications over constant polling where supported.
- Handle failures with retries, queues, and clear error logs.
- Version your interfaces and document changes before they reach users.
- Limit permissions to the data each integration actually needs.
Plan for reconciliation
Data drifts even in good integrations. Schedule periodic checks that compare record counts and key fields between systems, and assign someone to resolve differences.
Governance: Who Owns Each Integration
Business owner
Defines what the integration must achieve and approves changes to it.
Technical owner
Maintains mappings, credentials, and monitoring, and handles incidents.
Security reviewer
Approves access scope, data handling, and vendor risk.
Facility operations
Confirms the data is usable in daily maintenance decisions.
Where the Maintenance Software Fits
Assets and locations
Give integrations a stable record to attach data to.
Work orders
Receive requests and events, then track labor, parts, and closure.
Preventive schedules
Turn usage or condition data into planned tasks.
Inventory and reporting
Connect parts use and outcomes to purchasing and management views.
Ask vendors these questions
- Which APIs and integration options are available, and how are changes announced?
- What limits apply to request volume, and how are errors reported?
- Which fields can be read and written, including custom fields?
Warning Signs You Chose the Wrong Path
Signs a build is straining
- One developer holds all the knowledge.
- Failures are found by users, not monitoring.
- Every vendor update triggers emergency fixes.
Signs middleware is not fitting
- Most flows need custom scripts anyway.
- Costs rise faster than the number of benefits.
- Required fields cannot be mapped.
Frequently Asked Questions
Is middleware always more expensive than building?
No. Building looks cheaper at first, but support and change costs add up. Compare total cost over several years.
What does iPaaS mean for a facility team?
It is a cloud service for building and running integrations without writing everything from scratch.
Can I mix building and middleware?
Yes. Many teams use middleware for common flows and custom code for unusual needs.
What should be ready before starting an integration?
Consistent asset IDs and clear ownership. Organize your assets in Oxmaint first.
How do I compare integration options for my sites?
Score the five criteria and review with your IT team. Book a demo to discuss your case.
Make Integration Decisions on Evidence
Bring your systems list and integration goals, and see how Oxmaint's assets, work orders, and reporting can support the approach you choose.
