Mastering Maximo Integration Architecture: REST APIs, MMI, and MAS in 2026
The Integration Landscape Has Shifted
If you last touched Maximo integrations in the 7.6.0.x era, the landscape has changed dramatically. The OSLC-centric approach that dominated for a decade has been joined -- and in many cases superseded -- by a new generation of REST APIs, a dedicated management interface, and a containerized deployment model that demands rethinking how integrations are built, secured, and scaled.
This article maps the current integration architecture for IBM Maximo Application Suite (MAS) as of mid-2026. We cover the three pillars every integration architect needs to understand: the NextGen REST/JSON API, the Maximo Management Interface (MMI), and the infrastructure patterns that keep everything running in production.
The NextGen REST/JSON API: What Changed
The NextGen REST API, introduced in Maximo 7.6.0.2 and now the default integration surface in MAS, represents a complete rewrite of the older OSLC REST APIs. IBM sometimes calls it the "REST/JSON API" because of its end-to-end support for the JSON data format.
The key difference from legacy OSLC: you do not need to configure OSLC resources. A vanilla Maximo installation with users and groups is all you need to start using the NextGen API. This alone eliminates hours of object structure configuration that used to be a prerequisite for any integration.
Core Capabilities
The NextGen API provides capabilities that go well beyond simple CRUD:
Advanced Filtering with `oslc.where`
The `oslc.where` query parameter maps to the Maximo QBE (Query By Example) framework and supports filtering on attributes of the main MBO or related MBOs. You can use range filters, SynonymDomain and MaxTableDomain-based filters, timeline filters for date ranges, and classification attribute searches for objects like Assets and Locations.
code blockSelective Attribute Retrieval with `oslc.select`
Rather than pulling entire object structures, you specify exactly which attributes to return. This reduces response payload size dramatically -- critical when integrating with mobile clients or high-volume data pipelines.
code blockRelated Object Navigation and Inlining
The API simplifies traversal to related MboSets using relationship names directly in the GET URI. You can also inline related data within the response using the `oslc.select` clause with dot notation, avoiding the N+1 query problem that plagued older integration patterns.
code blockBulk Operations
The API supports processing multiple resources with multiple operations (create, update, delete, actions) in a single transaction. This is a significant efficiency gain for integrations involving large data volumes -- think nightly syncs from an ERP system or bulk asset imports from an acquisition.
Attachment Handling
Attachments can be fetched, created, updated, and deleted as part of the object structure JSON. The `DOCLINKS` object and its `DOCUMENTDATA` non-persistent attribute must be included in your object structure if you intend to submit or retrieve document content inline.
Workflow Engine Interface
External systems can interact with Maximo workflows -- handling task nodes, input nodes, interaction nodes, wait nodes, and condition nodes. This enables orchestration patterns where an external BPM or RPA tool drives Maximo workflows through API calls.
Metadata Support with JSON Schema
The API uses JSON Schema to describe resources, providing metadata that helps integrating systems understand data structure and constraints. Schema information is accessible via dedicated routes or can be inlined in query responses.
When to Use `/api` vs `/oslc`
A common point of confusion: the NextGen API exposes two URL patterns.
| Path | Authentication | Use Case |
|------|---------------|----------|
| `/maximo/api/` | API Key | Machine-to-machine integrations, external clients |
| `/maximo/oslc/` | x-access-token, LTPA token | Browser-based sessions, existing OSLC consumers |
When you authenticate with an API key, use `/api`. When you authenticate with a session token (LTPA, x-access-token), use `/oslc`. The underlying capabilities are identical; the path prefix determines the authentication mechanism.
The Maximo Management Interface (MMI)
The Maximo Management Interface is a cornerstone of MAS that many organizations overlook. It is not just another API layer -- it is a management interface that consolidates operational insight from every member server in your Maximo deployment.
What MMI Provides
Built on a REST API framework, MMI delivers structured, JSON-based data about your MAS environment. Every endpoint follows a consistent structure, starting from the root URL and extending into member-ID-specific resources.
Key capabilities include:
- Server health monitoring: Track CPU, memory, and response times across all MAS pods
- Object structure visibility: Inspect which object structures are active, their configuration, and their performance
- Work order tracking trends: Monitor work order volumes, backlog, and processing times
- Inventory and spare parts availability: Check stock levels and reorder points across warehouses
- System default locale and configuration: Verify consistent configuration across environments
MMI and Observability
MMI connects seamlessly with Prometheus and Grafana for visualization and alerting. A typical setup involves:
1. Configuring `mxe.oslc.webappurl` to point to the correct management interface server
2. Setting up a Prometheus scrape config targeting MMI health endpoints
3. Building Grafana dashboards for real-time visibility into MAS health
4. Defining alerts for high HTTP error rates, latency spikes, or pod resource pressure
The JSON output from MMI endpoints can be consumed by any monitoring tool, custom scripts, or integration middleware. This makes MMI the bridge between MAS operations and enterprise observability platforms like Instana, Dynatrace, or the ELK stack.
Access Control
MMI uses Maximo's role-based access controls. Signature options within the logging application determine which users can access which MMI endpoints. This means you can safely expose MMI to operations teams without granting them access to transactional Maximo data.
API Key Authentication: The New Standard
MAS progressively replaces older authentication mechanisms like `MAXAUTH`, BASIC, or direct LDAP login with API Key-based authentication. This is the recommended approach for all machine-to-machine integrations.
Configuration
API Keys are created in Maximo Manage under Administration > Integration > API Keys. Each key is associated with a specific user and inherits that user's permissions. Keys can be configured to expire automatically and can be revoked at any time.
Best Practices
Never hardcode or expose API Keys. Store them in a secrets manager (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager) or at minimum in environment variables. Never commit them to Git repositories or include them in client-side code. Set reasonable expiration dates and rotate keys periodically. A 90-day rotation cycle is a good starting point. Automate the rotation process where possible. Restrict privileges. The user associated with an API key should have only the roles required for that specific integration. Do not reuse a single super-user key across all integrations. Maintain an API Key inventory. Track who owns each key, what integration it serves, when it was created, and when it expires. This is essential for audit readiness and incident response. Separate keys by environment. A key for the development environment should never work in production. Cross-environment key reuse is a common security finding in MAS audits.
Common Security Pitfalls
The most frequent issues seen in enterprise MAS deployments:
- Over-permissive roles attached to API keys (e.g., MAXADMIN for a read-only reporting integration)
- Lack of audit trails for API Key creation and revocation
- Shared keys between Dev, Test, and Production environments
- Keys embedded in integration scripts that are then committed to version control
To mitigate these, organizations should enforce governance policies and automated audits across environments. A simple quarterly review of all active API keys -- who owns them, what they access, when they were last used -- catches most problems before they become incidents.
Infrastructure Sizing for MAS on Kubernetes/OpenShift
MAS runs on Red Hat OpenShift, which means integration architects need to think about infrastructure differently than they did with traditional WebSphere deployments.
Recommended Sizing
Based on IBM's MAS Performance Guidance, here are the baseline recommendations:
| Component | Minimum | Recommended |
|-----------|---------|-------------|
| Worker node vCPUs | 8 | 16 |
| Worker node RAM | 32 GB | 64 GB |
| Persistent storage per node | 300 GB | 500 GB |
| DB2 storage class | SSD, dedicated | SSD, dedicated, IOPS provisioned |
| Network latency (pod to DB2) | < 5ms | < 2ms |
Resource Requests and Limits
Every MAS service should have configured resource requests and limits. Without them, a single misbehaving pod can starve other services on the same node.
code blockHorizontal Pod Autoscaling (HPA)
Enable HPA for services that experience variable load, particularly `maximo-api` and `maximo-ui`. A typical HPA configuration scales based on CPU utilization:
code blockMessage Tracking for Troubleshooting
The Maximo Integration Framework (MIF) includes a Message Tracking feature that records incoming and outgoing REST payloads and metadata. Enable this in production -- the storage cost is minimal compared to the debugging time it saves.
Message Tracking facilitates:
- Correlation of failed transactions with application logs
- Debugging API latency or authentication failures
- Audit trails for compliance requirements
- Performance analysis of integration patterns
Centralize logs using OpenShift's Logging Operator or an ELK stack. Define alerts for high HTTP error rates (4xx, 5xx) and latency spikes above your SLA thresholds.
Automation Scripts in Integration Channels
Automation Scripts (Jython, Python, JavaScript) are a powerful way to implement business logic in integration channels without redeploying EAR files. When used in Enterprise Services, Publish Channels, or Object Structures, they allow deep customization of data flows.
Choosing the Right Launch Point
| Launch Point | When to Use |
|-------------|-------------|
| Before (inbound) | Validate or transform incoming data before Maximo processes it |
| After (inbound) | Enrich records after Maximo creates/updates them |
| Before (outbound) | Filter or transform data before it leaves Maximo |
| After (outbound) | Log or audit what was sent |
Script Optimization Patterns
Avoid unnecessary loops and queries. Use efficient MBO iteration with `getMboSet()` and filter at the database level rather than in application code. Centralize error handling. Use `MXLoggerFactory` to capture exceptions in `integration.log`:
code block
