The Maximo Integration Framework and REST API: A Deep Dive for Architects

Understanding the Maximo Integration Framework

The Maximo Integration Framework (MIF) has been the backbone of Maximo's external connectivity for over a decade. Whether you are syncing work orders with an ERP, pushing asset updates to a GIS system, or receiving meter readings from IoT sensors, the MIF is the layer that makes it happen. With the shift to Maximo Application Suite (MAS), the integration landscape has evolved significantly, but the core concepts remain surprisingly consistent. Understanding these concepts is essential because they form the foundation upon which all Maximo integrations are built, from the simplest data export to the most complex bidirectional enterprise integration.

At its foundation, the MIF is organized around four core components: Object Structures, Publish Channels, Enterprise Services, and End Points. Each plays a distinct role in the integration pipeline, and understanding how they interact is essential for any architect designing Maximo integrations.

Object Structures define the data schema that Maximo exposes to external systems. Each Object Structure maps a set of Maximo application objects, such as WORKORDER, PO, or ASSET, and their fields to a named external schema. Object Structures control which fields are included in integration messages, which fields are required, and which Maximo business rules apply when data enters through the integration layer. The beauty of Object Structures is their reusability. The MXWO Object Structure, for example, can serve both outbound work order status updates to an external system and inbound work order creation requests from a field service platform. Pre-built Object Structures exist for all major Maximo business objects, and custom structures can be created for specialized use cases.

Publish Channels define outbound integration flows. When a qualifying event occurs in Maximo, such as a work order status change or a purchase order approval, the Publish Channel generates an XML or JSON message and delivers it to the configured End Point. Publish Channels are triggered by exits, which are Java classes or automation scripts that evaluate whether a specific record change should generate an outbound message. Most standard integrations use pre-built exits, but custom exit logic can implement conditional publishing, such as only sending purchase orders above a certain value to the external procurement system. This conditional publishing capability is particularly valuable for filtering noise and ensuring that only meaningful events trigger integration flows.

Enterprise Services handle inbound integration flows. An external system posts an XML or JSON message to the Enterprise Service URL, and the MIF processes it, validates it against the Object Structure, and creates or updates the corresponding Maximo record. Enterprise Services can invoke Maximo business rules, including validation, required field checks, and workflow initiation, just as if the record had been created through the Maximo UI. This means that data entering through the integration layer is subject to the same governance and validation as data entered manually, which is critical for data quality and compliance.

End Points define the external destinations for Publish Channel messages. End Point types include HTTP for REST or SOAP web service calls, JMS message queues for asynchronous reliable delivery, and flat file for batch integrations. For MAS cloud deployments, JMS end points can use embedded messaging or external message brokers such as IBM MQ or Apache Kafka. The choice of End Point type depends on the integration pattern: HTTP for synchronous request-response, JMS for reliable asynchronous delivery, and flat files for legacy batch processing.

<!-- Example: Object Structure MXWO (simplified) -->
<ObjectStructure name="MXWO">
  <Object name="WORKORDER">
    <Attribute name="WONUM" required="true"/>
    <Attribute name="STATUS"/>
    <Attribute name="DESCRIPTION"/>
    <Attribute name="ASSETNUM"/>
    <Attribute name="LOCATION"/>
    <Attribute name="REPORTEDBY"/>
    <Attribute name="STATUSDATE"/>
  </Object>
  <Object name="WORKLOG" relationship="WORKORDER_WORKLOG">
    <Attribute name="DESCRIPTION"/>
    <Attribute name="CREATEDBY"/>
    <Attribute name="LOGTYPE"/>
  </Object>
</ObjectStructure>

The three-layer processing model of the MIF provides clear separation of concerns. The Object Structure layer handles data definition and validation. The Integration layer, composed of Enterprise Services and Publish Channels, handles business rule processing and integration controls. The External System layer manages the connection to the outside world, including defining external systems, identifying applicable services and channels, and configuring integration control values. This separation allows each layer to be managed independently, which simplifies maintenance and enables teams to work in parallel on different aspects of the integration.

The Native REST API in MAS: A Paradigm Shift

MAS Manage introduces a native REST API that dramatically simplifies integration for modern applications. Unlike the MIF, which requires XML schema configuration and pre-published Object Structures, the MAS REST API follows standard RESTful conventions with JSON payloads and requires minimal pre-configuration in the Maximo application layer. This shift represents a significant reduction in the barrier to entry for integration developers.

The base URL pattern for the OSLC (Open Services for Lifecycle Collaboration) REST API is straightforward:

https://{mas-host}/maximo/oslc/os/{objectname}

This means you can query work orders, assets, or any other Maximo business object with a simple HTTP GET. The API supports filtering, field selection, pagination, and aggregation, making it suitable for both lightweight lookups and complex data extraction. Authentication is handled through API keys, which can be generated and managed through the MAS administrative interface.

# Query work orders in WAPPR status with field selection and pagination
curl -X GET \
  "https://mas-host/maximo/oslc/os/mxwo?oslc.where=status=%22WAPPR%22&oslc.select=wonum,description,status,statusdate,reportedby&oslc.pageSize=50" \
  -H "apikey: YOUR_API_KEY" \
  -H "Accept: application/json"

# Discover all available Object Structures (API endpoints)
curl -X GET "https://mas-host/maximo/oslc/os" \
  -H "apikey: YOUR_API_KEY" \
  -H "Accept: application/json"

The API also supports nested resource queries, allowing you to retrieve related asset and location information in a single call. This reduces the number of round trips needed for complex data retrieval, which is particularly important for mobile applications and integrations operating over constrained network connections:

# Query a specific work order with nested asset and location data
curl -X GET \
  "https://mas-host/maximo/oslc/os/mxwo?oslc.where=wonum=%22WO-1001%22&oslc.select=wonum,description,status,asset{assetnum,description,serialnum},location{location,description}" \
  -H "apikey: YOUR_API_KEY" \
  -H "Accept: application/json"

For organizations migrating from Maximo 7.6.x to MAS, the REST API represents a significant simplification. Integration developers no longer need to configure Enterprise Services or Publish Channels for basic CRUD operations. Instead, they can call the REST API directly, which is particularly powerful for building custom applications, mobile solutions, and real-time integrations with cloud services. The REST API also makes it much easier to integrate Maximo with low-code platforms like Microsoft Power Automate, IBM App Connect, or Zapier, since these platforms natively understand REST endpoints with JSON payloads.

The NextGen REST API, available in recent MAS releases, adds even more capabilities. Unlike the older OSLC REST APIs, the NextGen APIs are simpler to set up and use, requiring no additional OSLC resource configuration, and can work with a vanilla Maximo installation. They support advanced filtering, timeline-based queries, classification attribute searches, and aggregation functions that go well beyond what the original OSLC API offered.

# Timeline filter: Find work orders reported in the past 3 months
GET /oslc/os/mxwodetail?tlrange=-3M&tlattribute=reportdate

# Classification attribute search: Assets with SPEED >= 50
GET oslc/os/mxapiasset?attributesearch=[SPEED:>=50]

# Aggregation: Average labor hours for open work orders on an asset
GET /oslc/os/mxasset/{rest_id}?oslc.select=assetnum,openwo.actlabhrs._dbavg,openwo.actlabhrs._dbsum,openwo.actlabhrs._dbmax,openwo.actlabhrs._dbmin,openwo._dbcount

The aggregation capabilities deserve particular attention. Being able to compute averages, sums, maximums, minimums, and counts directly through the API eliminates the need for complex server-side queries or custom reporting code. For a maintenance manager who needs to understand the labor hours being spent on a specific asset, a single API call can return all the relevant statistics without any post-processing.

SAP Integration: From PI/PO to CPI

One of the most significant integration updates in 2026 is the modernization of the IBM Maximo Connector for SAP. Announced in March 2026 by IBM's Hari Krishna Mandalapu, the connector now supports SAP Cloud Platform Integration (SAP CPI) as its middleware layer, aligning with SAP's current cloud integration architecture while preserving all existing Maximo-SAP integration patterns, mappings, and functional behavior.

This is a critical update for organizations running both Maximo and SAP. The transition from SAP PI/PO to SAP CPI reflects the broader industry shift toward cloud-native integration platforms. SAP CPI provides better scalability, monitoring, and cloud connectivity than its on-premise predecessor, and it aligns with SAP's roadmap for cloud-first enterprises. SAP PI/PO has been approaching end-of-maintenance, and organizations that delay migration face increasing support risks.

The key characteristics of this update include:

• Support for SAP CPI as the integration middleware, replacing the older SAP PI/PO-based approach
• Updated artifacts aligned with SAP's recommended cloud integration patterns
• All existing business scenarios, mappings, and integration patterns continue to function without modification
• A modernized connector foundation that supports long-term CPI-based architectures

The connector is available now in the Maximo Application Suite February Feature Channel for non-production use, supported for MAS 9.1 and forward MAS versions, with production readiness planned with MAS 9.2 GA. This means organizations can begin CPI-based validation ahead of production rollout, de-risking the migration from PI/PO to CPI. The phased approach allows integration teams to validate their existing scenarios in the new middleware before committing to production cutover.

For integration architects, this update matters because it removes a significant technical debt burden. Many Maximo-SAP integrations were built on SAP PI/PO infrastructure that is approaching end-of-maintenance. The CPI connector ensures that Maximo integrations can move to a supported, cloud-ready middleware without rewriting the integration logic itself. The business scenarios, field mappings, and process flows remain unchanged. What changes is the transport layer underneath.

# Typical SAP CPI integration flow for Maximo work order sync
# 1. Maximo publishes work order via Publish Channel to CPI endpoint
POST https://sap-cpi-tenant.it-cpi001.hana.ondemand.com/http/maximo/wo-sync
Content-Type: application/json
Authorization: Bearer <CPI_OAUTH_TOKEN>
{
  "WONUM": "WO-1001",
  "STATUS": "APPR",
  "DESCRIPTION": "Pump overhaul - Building 4",
  "ASSETNUM": "PUMP-4A",
  "LOCATION": "BLDG-4",
  "PRIORITY": "1",
  "REPORTEDBY": "MAINT_LEAD"
}

# 2. CPI transforms payload to SAP PM order format and creates notification
# 3. SAP confirms back to Maximo via Enterprise Service with SAP order number
POST https://mas-host/maximo/oslc/os/mxwo
Content-Type: application/json
apikey: YOUR_API_KEY
{
  "WONUM": "WO-1001",
  "STATUS": "APPR",
  "SAPORDERNUM": "000001234567",
  "SAPNOTIFNUM": "00000987654"
}

The integration typically covers several business scenarios: purchase requisition sync from Maximo to SAP MM, goods receipt confirmation from SAP to Maximo Inventory, work order cost settlement from Maximo to SAP CO, and equipment master data synchronization in both directions. Each scenario uses the same CPI middleware but follows its own integration flow pattern within SAP CPI.

MAS Architecture: Core vs. Manage

Understanding the architecture of MAS itself is essential for integration planning. MAS is not a monolithic application. It is a suite of applications running on Red Hat OpenShift, with a clear separation between the platform layer and the business application layer. This separation has direct implications for how integrations are designed, deployed, and managed.

MAS Core is the foundational platform layer. It provides authentication and SSO through OpenID Connect (OIDC), user and role management, AppPoints license administration, workspace management, security services, the API and integration framework, and tenant management. MAS Core is what makes MAS a true multi-application platform rather than a collection of separate products. All API calls, whether from the REST API or the MIF, pass through MAS Core's security and routing infrastructure.

MAS Manage is the containerized evolution of Maximo Asset Management 7.6. This is where business operations run: Asset Management, Work Orders, Preventive Maintenance, Inventory, Purchasing, Service Requests, Job Plans, Contracts, Workflow, and Industry Solutions. MAS Manage is where most integration work happens, as it exposes the business objects and processes that external systems need to interact with.

The architecture supports multiple database options. Maximo Manage supports IBM Db2, Oracle Database, and Microsoft SQL Server. MongoDB stores user, application, and entitlement metadata, including OIDC registrations and user management data. IBM Event Streams, a fully managed Apache Kafka service, can be used for event-driven integrations that require high throughput and reliable delivery. IBM Cloud Pak for Data provides AI-infused services for business and IT operations, and it is required if you intend to integrate Maximo Manage with other application suites or leverage advanced analytics capabilities.

This modular architecture has significant implications for integration design. You can scale individual components independently, allocating more resources to MAS Manage during peak processing while keeping MAS Core lightweight. You can deploy MAS in a hybrid-cloud configuration, with some components on-premises and others in a public cloud. You can use Kafka-based event streaming for high-volume, real-time integrations such as IoT sensor data ingestion, or REST APIs for synchronous request-response patterns like work order lookups from a mobile app, or the MIF for traditional batch and JMS-based integrations that require guaranteed delivery.

The MCP Server: AI-Native Integration in MAS 9.2

The most significant integration innovation in MAS 9.2 is the introduction of the MCP (Model Context Protocol) Server. This is a fundamentally new way to integrate AI agents with Maximo, and it represents a shift from API-centric to capability-centric integration. The MCP Server was designed specifically for the emerging era of AI-native enterprise software, where AI agents need to interact with business systems without understanding the underlying technical complexity.

Traditional REST APIs were built for developers who understand HTTP methods and JSON payloads. AI agents, however, reason in business objectives. The MCP Server bridges this gap by exposing business capabilities that AI agents can understand and invoke, rather than raw API endpoints. Instead of asking an AI to construct the correct REST request with the right object structure, payload format, and authentication flow, the interaction becomes much closer to natural intent.

With the MCP Server, an AI agent does not need to know which endpoint to call, which object structure to use, how to build the payload, or which authentication flow applies. Instead, it simply requests a business capability, and the MCP Server translates that intent into the appropriate interaction with Maximo. The REST APIs remain the foundation of the platform, and the MCP Server is an additional layer designed specifically for AI-native interactions.

For integration architects, the MCP Server opens new possibilities. You can build AI agents that orchestrate across Maximo and other enterprise systems, using natural language intent rather than hardcoded API calls. You can create custom AI tools using Maximo Manage automation scripts, object structures, or workflows, and connect your own agents to the Maximo MCP server. This is particularly powerful for use cases like automated work order triage, where an AI agent can analyze incoming work requests, determine priority based on asset criticality and historical patterns, and create the work order in Maximo without any human intervention.

Practical Implications

For organizations planning Maximo integrations in 2026, several decisions loom. If you are migrating from Maximo 7.6.x to MAS, evaluate which existing MIF integrations can be replaced with native REST API calls. The REST API is simpler, more maintainable, and better suited for cloud-native architectures. However, MIF integrations that rely on JMS queues, flat files, or complex Publish Channel exit logic may still be the right choice for asynchronous, high-volume, or conditional integration scenarios. A migration assessment should categorize each integration by pattern and complexity before deciding on the target architecture.

If you are running both Maximo and SAP, the CPI connector update is a clear priority. Begin validating in non-production environments now, particularly if your SAP PI/PO infrastructure is approaching end-of-maintenance. The fact that existing integration logic remains unchanged significantly reduces migration risk. Create a validation plan that tests each integration scenario end-to-end through CPI before scheduling production cutover.

If you are exploring AI-driven integrations, the MCP Server in MAS 9.2 is worth investigating. It provides a standardized, supported way to connect AI agents with Maximo, and it aligns with the broader industry trend toward AI-native enterprise integration. Start with a pilot use case, such as AI-assisted work order triage or asset condition analysis, to evaluate the MCP Server's capabilities in your environment. IBM has indicated that the Maximo Assistant will be upgraded to a Granite 4.0 model, making the assistant more capable over time, so early adoption positions you to benefit from these enhancements.

For all integration work, invest in API monitoring and observability. MAS provides dashboards for API usage, but consider supplementing with tools like Postman for testing, Grafana for monitoring, and centralized logging for troubleshooting. Integration failures in asset management systems can have direct operational consequences, so proactive monitoring is essential. Establish alerting thresholds for integration queue depth, message processing time, and error rates.

Bottom Line

Maximo's integration landscape has never been more capable or more complex. The MIF remains a powerful tool for traditional integration patterns, the native REST API simplifies modern application connectivity, the SAP CPI connector modernizes a critical enterprise integration path, and the MCP Server opens entirely new possibilities for AI-driven integration. The key for architects is choosing the right tool for each integration scenario rather than forcing every integration into a single pattern. With MAS 9.2 generally available and the MCP Server now in production, organizations have a comprehensive integration toolkit that can serve both traditional enterprise connectivity needs and emerging AI-driven workflows. The organizations that succeed will be those that invest in understanding these capabilities, build a thoughtful integration strategy, and avoid the temptation to treat all integrations as the same type of problem.