Work Order Integration in MAS 9: The REST/JSON API, Kafka Events, and Where MIF Still Fits

🎯 Who this is for: Integration developers and architects who move work order data in and out of Maximo — and just heard from a teammate that "the old work order endpoint changed" in MAS 9.

Series: Part 6 of 6 (Series Finale) — MAS 9 Work Order Operations: The Missing Pieces | Read time: 22 minutes

The Integration Surface Moved — For Work Orders Specifically

Here is the message that lands in your inbox after an upgrade: "The integration team says the old work order endpoint changed — did it?"

Short answer: the recommended front door for work order integration moved. The work order object didn't change — WORKORDER and its MXWODETAIL object structure are the same records you've always integrated. What changed is how IBM wants you to reach them, and which access patterns are now on the deprecation list.

This is the series finale, and it's deliberately narrow. We are only covering work-order-scoped integration here — the endpoint you hit for a WO, the events a WO publishes, and where MIF fits for WO data specifically. The full integration framework — API key management, the broader OSLC surface, MIF architecture, event-driven patterns across every object — is its own subject, and we cover it properly in the MAS INTEGRATION series (start with API-First Architecture and Event-Driven Transformation). If you want the platform-wide picture, go there. This post is the work order slice.

Three things to know, in order of how often you'll use them:

  1. The JSON API at /api/os/mxwodetail is the recommended path for all new WO integrations.
  2. Kafka events publish WO changes for near-real-time, subscribe-don't-poll integrations.
  3. MIF still works for your existing WO integrations — but it's no longer where the investment goes.

📊 Old World vs. MAS 9

Work order integration pattern — Legacy Maximo — MAS 9

Preferred API — /maxrest/rest MBO endpoints — `/api/os/mxwodetail` JSON API (lean=1)

OSLC — /oslc/os/mxwodetail — Still works, but JSON API preferred

Near-real-time events — JMS / polling — Kafka WO topics (Strimzi on OpenShift)

Object Structure — MXWODETAIL — Same — still functions for MIF

Publish Channels / Enterprise Services — Primary integration path — Still fire, but no new investment

RMI for WO access — Supported — Deprecated — rewrite to REST

Direct SQL for WO queries — Common — Restricted — use REST or automation scripts

API authentication — Basic auth — API keys (basic auth deprecated)

<aside>

💡 Key insight: Nothing on the outbound-still-works side of this table needs your attention today. The rows that matter are the deprecated ones — RMI, direct SQL, basic auth. If any of your WO integrations lean on those, they are the migration backlog. Everything else is "leave it alone."

</aside>

🔌 The JSON API for Work Orders

The JSON API is the recommended method for every new work order integration in MAS 9. It's built on the object structure model, so the endpoint you care about is the one that exposes the work order object structure: `/api/os/mxwodetail`.

The one flag you'll use constantly is `lean=1`. It tells Maximo to strip the OSLC namespace wrappers out of the response and give you flat, readable JSON — the difference between a payload you can parse in one line and one buried under rdf: and spi: prefixes. Add it to every call.

Query work orders

Filter with oslc.where and shape the returned columns with oslc.select. Here's a query for all approved work orders, returning just the fields you need:

GET /api/os/mxwodetail?lean=1&oslc.where=status="APPR"&oslc.select=wonum,description,status,location,assetnum

That returns a lean JSON list of approved work orders with only wonum, description, status, location, and assetnum — not the entire fat WO record. oslc.select is how you keep payloads small and fast; ask for the columns you'll actually use.

Create a work order

POST a JSON body to the same endpoint. At minimum you need a siteid, a description, and a worktype; the rest of the WO fields ride along in the same body:

POST /api/os/mxwodetail?lean=1
Content-Type: application/json

{
  "siteid": "BEDFORD",
  "description": "Pump P-2047 vibration alarm",
  "worktype": "CM",
  "wopriority": 2,
  "assetnum": "P-2047",
  "location": "PUMPHOUSE-A",
  "classstructureid": "1234"
}

Maximo creates the work order and returns the new record. This is the pattern that replaces "insert a row and hope the triggers fire" — you go through the object structure, so the business rules run.

Change work order status

Status changes don't go through a plain field update — you invoke the work order's changeStatus method through the API so the status transition logic runs. POST to the specific work order by its workorderid:

POST /api/os/mxwodetail/{workorderid}?lean=1&action=wsmethod:changeStatus
Content-Type: application/json

{
  "status": "APPR",
  "memo": "Approved by REST API integration"
}

The action=wsmethod:changeStatus parameter is the important part: it routes the call through the work order's status-change method rather than blindly stamping the status field, so state validation and side effects behave exactly as they would in the UI.

<aside>

💡 Key insight: Prefer wsmethod:changeStatus over a direct write to the status attribute. A raw field update can bypass the transition logic; the method call honors it. When an integration "sets a work order to COMP but nothing downstream fired," a bypassed status method is usually why.

</aside>

What changed from the legacy endpoints — and why

If your integrations point at `/maxrest/rest/mbo/workorder` (the classic MBO REST layer), those are the endpoints being left behind. The move is to the object-structure-based `/api/os/` surface for a real reason: the object structure enforces the same integration processing, cross-object rules, and security that MIF uses, so a REST create and a MIF create behave consistently. The old /maxrest MBO endpoints operated closer to the raw object and are the legacy path.

Two more deprecations to note on the WO integration surface:

  • RMI for WO access is deprecated — rewrite any RMI-based work order access to REST.
  • Basic auth is deprecated — authenticate with API keys, not a username/password on every call. (API key management is a platform topic; see the MAS INTEGRATION series for setup.)

OSLC still works. /oslc/os/mxwodetail remains functional if you have OSLC-based integrations; the JSON API is simply preferred for new work.

📡 Kafka Events for Work Orders

Polling the REST API on a timer to catch work order changes is the pattern MAS 9 wants you to retire for high-volume, time-sensitive flows. The replacement is event-driven: let the work order tell you when it changed.

Here's how it fits together for work orders:

  • Configure a Kafka provider under External Systems, the same place you've always defined integration endpoints.
  • Maximo publishes an event every time a work order is created, updated, or changes status — the same three lifecycle moments you'd otherwise poll for.
  • External systems subscribe to the WO-specific Kafka topics and react as changes happen, instead of asking "anything new?" every thirty seconds.
  • On MAS 9 the Kafka broker itself is provided by Strimzi on OpenShift — it's part of the platform, not a separate cluster you stand up by hand.

The canonical use case is real-time WO status sync with an ERP system: a work order moves to COMP in Maximo, an event fires, and the ERP updates the associated cost or maintenance record within seconds — no batch job, no polling window. For high-volume WO integration, this scales better than the old JMS-based approach.

<aside>

💡 Key insight: Kafka is the answer when latency and volume both matter. If you sync a handful of WO changes a day, the REST API on a schedule is fine. If you sync thousands of status changes an hour into an ERP, that's the workload event-driven Kafka was built for. Match the mechanism to the volume — don't Kafka-ify a nightly batch.

</aside>

If event-driven integration is new to your team, the pattern (topics, subscribers, at-least-once delivery) is covered in depth in the MAS INTEGRATION series — this post just tells you that work orders are a first-class publisher on it.

🗂️ MIF Still Works — Here's Where It Fits

Now the reassurance, because integration developers hear "the surface moved" and immediately worry their production MIF flows are about to break. They aren't. The Maximo Integration Framework still works for work orders:

  • The `MXWODETAIL` Object Structure still functions for inbound and outbound WO integration.
  • Publish Channels still fire on work order events.
  • Enterprise Services still receive inbound WO data.
  • Interface Tables still work where direct database access is available.

Everything you built on MIF for work orders keeps running. There is no forced cutover, no end-of-support cliff announced for these in the work order roadmap. Your outbound Publish Channel that pushes completed WOs to a data warehouse tonight will push them tomorrow night too.

The single caveat IBM does add: new integrations should use the REST API, not MIF. That's it — a direction of investment, not a deprecation of what exists.

One environment note worth flagging: Interface Tables depend on database access, and in sealed or SaaS-style MAS deployments you may not have it. If your MIF integration relies on reading or writing interface tables directly, confirm your environment still exposes the database before you count on that path in a cloud upgrade.

<aside>

💡 Key insight: "MIF still works" and "build new integrations on MIF" are two different statements. The first is true; the second isn't the recommendation. Keep your working Publish Channels; don't author a brand-new one when a REST call or a Kafka topic does the job.

</aside>

🧭 The Migration Posture

Pull the pieces together and the posture is refreshingly simple. You don't need a big-bang integration rewrite for MAS 9 — you need a rule for new work and a rule for old work.

For new work order integrations:

  • Use the JSON API (/api/os/mxwodetail, lean=1) for request/response — query, create, and status-change flows.
  • Use Kafka events for near-real-time, high-volume, subscribe-don't-poll flows.
  • Authenticate with API keys, never basic auth.

For existing work order integrations:

  • Leave working MIF alone. Publish Channels, Enterprise Services, and the MXWODETAIL object structure keep running.
  • Migrate only the deprecated pieces — RMI-based WO access, direct SQL WO queries, and basic-auth API calls are the actual backlog.
  • Sanity-check Interface Tables against your deployment model if you're moving to a sealed/SaaS environment.

<aside>

💡 Key insight: Treat this like the BIRT rationalization from Part 5 — it's a triage exercise, not a rebuild. Sort every WO integration into "works, leave it," "deprecated, rewrite it," and "new, build it the MAS 9 way." Most of your catalog lands in the first bucket.

</aside>

Key Takeaways

  • The JSON API at `/api/os/mxwodetail` with `lean=1` is the recommended path for all new work order integrations — query with oslc.where/oslc.select, create with a JSON POST, change status with action=wsmethod:changeStatus.
  • The legacy `/maxrest` MBO endpoints, RMI access, and basic auth are deprecated; move to the object-structure JSON API and API keys. OSLC (/oslc/os/mxwodetail) still works but the JSON API is preferred.
  • Kafka events publish WO create/update/status changes for near-real-time integration; external systems subscribe to WO topics, and Strimzi on OpenShift provides the broker.
  • MIF still works — MXWODETAIL object structure, Publish Channels, and Enterprise Services keep running for existing integrations; IBM just isn't investing there.
  • The migration posture is: build new integrations on REST/Kafka, leave working MIF alone, and migrate only the genuinely deprecated pieces.

References

Series Navigation

Previous: — Part 5 — Work Order Reporting in MAS 9

Next: — You have reached the end of the series — Back to the series index

About TheMaximoGuys: We help Maximo developers and teams navigate the move to MAS 9 with practical, no-hype guidance grounded in how the platform actually behaves.

Published by TheMaximoGuys | July 2026