For two decades, moving a system model from one vendor's tool to another meant exporting XMI and praying. Anyone who tried it knows how that usually ended: broken references, dropped stereotypes, and a day of cleanup before the model would even open. The language got most of the attention when SysML v2 was finalized, but the part that quietly fixes this old pain lives in a separate spec. It's the Systems Modeling API and Services, and it's where interoperability stops being a slide and starts being a thing you can call.
What the API actually is
When OMG finalized SysML v2.0 in July 2025, it shipped alongside two companions: the Kernel Modeling Language (KerML) and the Systems Modeling API and Services 1.0. That third piece is easy to skip past, but it changes the model from a file you pass around into a service you talk to over HTTP.
The spec defines a Platform Independent Model and two Platform Specific Models. One is a REST/HTTP interface that returns model data as JSON. The other is an OSLC binding, with an OASIS companion spec (OSLC Systems Modeling Language v2.0, published in draft in April 2024) that gives an RDF representation of the same model. Providers can implement either binding, or both. The services cover the operations you'd expect from a real backend: access, persistence, querying, validation, and versioning of model elements.
The practical upshot: instead of "export the whole model and hope," a downstream tool can ask for exactly the elements it needs, get a clean JSON payload back, and trust that the structure matches the standard.
Why JSON over XMI is a bigger deal than it sounds
XMI was always a full-document format. To read one requirement, you parsed the whole tree, and any tool that interpreted the schema a little differently produced an export the next tool couldn't fully ingest. It was technically a standard and practically a negotiation.
The SysML v2 API replaces that with granular, resource-oriented access. A simulation tool can pull the parameters it cares about without dragging along the behavioral diagrams it can't use. A requirements manager can sync a single changed requirement instead of re-importing everything. Because the responses are plain JSON over REST, the integration work looks like ordinary web development, not bespoke modeling-tool plumbing. That alone lowers the barrier for the small integrations that make a toolchain actually flow.
The digital thread, minus the hand-waving
"Digital thread" gets thrown around loosely, but the honest definition is narrow: a connected path of data that lets you trace a decision from requirement to design to test to the deployed system, in both directions. The hard part has never been the diagram of the thread. It's keeping the links live when the data lives in five different tools owned by three different vendors.
A standard API is the missing connective tissue. When every tool in the chain can read and write model elements through the same interface, the links between them can be queried and kept current instead of manually rebuilt after each export. That's the difference between a digital thread you maintain and one that maintains itself.
This is also why the API matters more than the language for organizations with mixed toolchains. You don't have to standardize everyone on a single vendor. You standardize on the interface, and let teams keep the authoring tools they already know.
Where the tools are right now
Adoption is real but uneven, which is normal for a year-old standard. Several vendors have committed to API conformance. Dassault Systèmes' Cameo line, through Teamwork Cloud, conforms to the SysML v2 API and Services specification for repository access. The open-source SysON project, backed by Obeo and the Eclipse community, exposes a REST API and runs an Early Adopter Program aimed at operational use in 2026. Dalus is built natively on the SysML v2 metamodel and API. The reference implementation itself lives in the open, as the Systems-Modeling pilot on GitHub, which is worth knowing about if you want to test conformance claims against something neutral.
The reference pilot is the part teams underuse. Before you trust a vendor's "API compliant" badge, you can point your integration at the pilot server and the vendor's server and compare the responses. If they diverge on the operations you depend on, you've found that out cheaply.
What it won't solve
The API standardizes access, not meaning. Two teams can both serve perfectly conformant SysML v2 over REST and still model the same system in ways that don't line up, because they made different modeling choices, used different libraries, or structured their requirements differently. Interoperability at the byte level doesn't buy you interoperability at the semantic level. You still need modeling conventions and a shared library strategy.
It also doesn't retire your v1 models for you. Migration from SysML v1 is a separate, real effort, and the API doesn't touch it. And maturity varies: a tool can be conformant for read access while its write, query, or versioning support lags, so "supports the API" is a question to ask in detail, not a checkbox. Finally, an API is infrastructure. It enables governance, traceability, and automation, but it doesn't supply them. Those are still process decisions your organization has to make.
Bottom line
The SysML v2 API is the quiet center of gravity in the v2 transition. The language gives you cleaner, more precise models, but the API is what lets those models move, connect, and feed the automation everyone keeps promising. If you're planning a v2 strategy, evaluate tools on their API conformance, not just their editor, and test those claims against the open reference implementation. The teams that treat the interface as the standard, rather than any single vendor, are the ones who'll get a digital thread that holds together.