An engineering firm prescribes an asset management platform to its client partly because of a line in the sales deck: open API, integrates with any system. Months later, the client asks to connect the platform to its SAP so that maintenance data can feed corporate indicators. The firm requests the API documentation from the vendor and receives, at best, a PDF listing endpoints that do not quite match what the system does in production; at worst, a contact form and the word roadmap. The integration taken for granted at the prescription stage becomes a custom development the vendor quotes separately, and the client looks at the firm that recommended the tool.
This scene repeats because "integrates with everything" is the easiest claim to put in a proposal and the hardest to verify once the contract is signed. For an engineering firm, though, the API is not an accessory feature checked at the end. It is what determines whether the firm can fold the platform into its own workflow — the BIM, CAD and GIS environments it already runs — and connect it to the client's systems, be it an ERP, a SAP or a SCADA layer. The difference between a real API and a promised one is the difference between integrating in hours and rewriting in months, and that difference is always paid by whoever prescribed.
Having an API is not the same as having a documented API
It pays to be precise about what is being assessed, because the word API is used for very different things. A system exposing some endpoint does not mean it is integrable with any guarantee. What makes a platform integrable is a public interface, documented under a standard and versioned. The reference standard is OpenAPI, maintained by an independent initiative and designed precisely so that humans and machines understand a service's capabilities without accessing source code or inspecting network traffic. An API described under OpenAPI 3.0, with authentication under a recognised scheme such as OAuth 2.0 — defined in RFC 6749 — is something that can be read, tested and integrated predictably. An API that exists only as a sales description, with no public documentation behind it, is an intention, not a capability.
The distinction matters because the cost of discovering it at the wrong moment is high. If the firm assumes the integration exists and promises it to the client as part of the deliverable, it is exposed to a risk it does not control: that on the day of connecting to SAP, the vendor cannot show documentation covering the entities needed. And the entities needed in asset management are specific: assets with their geometries, work orders, field readings, operational events. An API that documents the product catalogue but does not expose the asset geometry is useless for the use case that matters.
How to verify before prescribing
Protection against this surprise is built in the selection phase, with concrete checks a firm can fold into its process at no cost. The first is to ask for the URL of the OpenAPI documentation and confirm that it exists, is public and is versioned. If the vendor cannot show it and points to a call with their technical team, that is already an answer. The second is to review that the documentation covers the entities the use case needs, not only the generic ones. The third is to run, during the pilot, a real call against real data and confirm it returns what the documentation promises. The fourth is to verify the existence of webhooks or outgoing events for the relevant operational facts, because a serious integration is not just about querying data but about the system signalling when something happens.
To this is added the geospatial dimension, which for distributed network assets is not optional. The platform should import and export in standard formats and, where appropriate, expose services conforming to the Open Geospatial Consortium specifications, so that geometry and topology move between systems without loss. Maptainer publishes its API under OpenAPI 3.0 with OAuth 2.0 authentication and webhooks for operational events, but the criterion holds for evaluating any platform a technical office considers prescribing: what is asked for is not a promise of integration, but the URL where that integration is documented and can be tested.
What changes for the engineering firm
Treating the API as a hard technical criterion, rather than a box in the proposal, changes the firm's position with its client. A platform with a documented, standard API folds into the technical office's stack without friction and connects to the client's systems in hours, which turns an integration into a bounded task rather than a parallel project of uncertain outcome. The deliverable stops being an island and becomes a piece that fits the client's data ecosystem, which is exactly what an industrial client values when deciding whether to renew its trust in the firm.
There is also a consequence of independence worth keeping in view. An open, well-documented API is the guarantee that data can leave the platform for wherever the client decides, today or in three years. The firm that prescribes on that criterion not only solves the integration of the present; it protects its client from being trapped in the future, and protects its own recommendation from ageing badly. Interoperability, seen this way, is not one technical feature among others: it is a way of managing the risk of the prescription.
Before the next prescription
The useful question for a technical office about to recommend a platform is not whether the vendor says it has an API. It always will. The question is concrete and answered in a minute: what is the public URL of your OpenAPI documentation, and does it cover the entities this client will need to integrate? If the answer is a sales call rather than a link, the promised integration does not yet exist, and prescribing on something that does not exist passes to the client a risk the firm could have checked before signing.