TL;DR

APIs are tricky, when compared to the rest of a system.

Of necessity they are not guaranteed to remain the same from version to version.

It is a 'paid support needed' product.

As of 2026.01 there are several calls documented that are special cases

Audit

Audit endpoints are not EAM/CMMS data and are even more than most API calls subject to change without notice (the documentation, being live will of course change if that happens).

Audit data is 'raw' data currently with no processing, no standardization. Their purpose is very different from the CMMS/EAM which do processing to a standard which makes them more likely to be compatible version to version.

We may end some 'processed' versions in the future and the raw ones may then disappear.

DataHub

These are not available through the API, but because the documentation is 'live', it is reading the code and listing these.

Automations

These have been fairly

Problem/Failure/Solution

These are old/outdated. They will disappear

PurchaseOrder

Some of these 'missing' / characters are new, replacing the buggy previous versions (changed in 2025), eventually the old ones will disappear

Some overall Thoughts:

As bugs are fixed, if you are taking advantage of the bug, the fix will 'break' it.

All of the API is subject to change. While we obviously try to keep it the same or as similar as possible from version to version, that applies more so with the EAM/CMMS data than anything else.

Use the _v value in many calls to check for upgrades that may be incompatible

For calls in general, it is a good idea to add bullet proofing by checking the _v that is returned.

If it isn't the one you expect/know/have tested with, you should have your code issue a warning or error, then go look to see what changed and whether it affects you in any negativeway. The Audit calls, returning raw data, don't return that because that is a 'version of the API call' which isn't in the raw data.

API Compatibility and Change Notice

The MCe APIs are actively maintained and evolve as the product is enhanced, corrected, and expanded. We make reasonable efforts to minimize unnecessary disruption to existing integrations; however, consumers of the APIs should not assume that all responses, behaviors, URLs, or data structures will remain unchanged indefinitely.

API Versions and Changes

API version changes most commonly indicate that additional information, capabilities, or fields have been introduced. Integrations should therefore be designed to tolerate additional fields and other non-breaking additions wherever practical.

A version change may also reflect a correction to existing behavior. This can include bug fixes, data corrections, changes to validation, or changes to a response that previously behaved differently than intended. As a result, an integration that depends on undocumented behavior, a particular bug, or assumptions about the returned data may require adjustment following an update.

Where practical, MCe provides detectable version or compatibility information that integrations can use to determine whether the API or a particular interface has changed. We recommend that integrations check this information where available and use a detected change as an indication that the integration should be reviewed or tested.

For some significant or intentionally incompatible changes, an older API URL or endpoint may eventually be removed. In these cases, requests to the obsolete endpoint will fail rather than silently returning potentially incompatible results.

Raw and Internal Data Interfaces

Some APIs expose data that is closer to MCe's underlying internal representation. Audit History is an important example.

These interfaces should be considered less stable than normal application-level APIs. Their schemas, values, formatting, relationships, interpretation, or underlying implementation may change as MCe itself evolves.

Although we attempt to avoid unnecessary changes, integrations using raw interfaces should be designed with the expectation that changes may occur between releases and that additional testing or adaptation may occasionally be required.

Where a documented, higher-level API is available for the same purpose, it should generally be preferred over relying directly on raw data structures.

Integration Recommendations

Consumers of the MCe APIs should:

• Avoid depending on undocumented behavior or assumptions about the internal implementation of MCe.
• Allow for additional fields or values to appear in API responses.
• Check API or interface version information where it is provided.
• Treat a detected version change as a reason to validate any assumptions made by the integration.
• Handle unavailable or retired endpoints as explicit integration errors.
• Apply additional defensive handling and testing when consuming raw interfaces such as Audit History.
• Test important integrations when deploying or upgrading to a new MCe release.

A change in version does not necessarily mean that an integration will stop working. In many cases it simply represents new functionality or additional information. It does, however, indicate that something relevant to that interface has changed and that integrations making assumptions about its behavior or data should take that change into account.

The goal of these practices is not to discourage API integration, but to allow MCe to continue improving and correcting the product while giving integrations practical ways to detect and respond to changes.