Autodesk published a case for building Vault integrations on the Vault Data API instead of the legacy path, and the shape of the argument is a familiar one told with unusual restraint. The old road is the Vault SDK with DLL references and SOAP web services, which means Windows, which means version compatibility management as a permanent tax. The new one is REST over HTTPS with JSON payloads, callable from C#, Java, Python, JavaScript, Node.js, Go, PHP or PowerShell, which is what makes the interesting integration targets reachable at all — ERP, MES, PLM and CRM systems, Power BI, and glue running in Azure Functions, AWS Lambda or Power Automate. A PDM vault that only Windows can talk to is a vault that only Windows can integrate.
What lifts this above a migration announcement is the pair of concessions. “Existing custom applications do not need to be rewritten. Legacy SDK-based solutions remain supported” is the sentence every enterprise customer reads first, and it is stated before the pitch rather than buried after it. The second is rarer: “Feature parity is still evolving. Not every capability available in the Vault SDK or SOAP APIs is currently exposed through the Vault Data API.” Publishing an incomplete surface and saying it is incomplete is a governance choice, and it is the one that lets an integrator scope a project honestly. The guidance that follows is correspondingly unglamorous — REST for web, cloud and cross-platform work; the SDK where you are writing Vault Explorer add-ins or Job Processor extensions, which the REST surface does not reach.
The catalog’s Autodesk record runs to 69 API pages and is weighted almost entirely toward Autodesk Construction Cloud — the ACC Data Connector API, the ACC Model Properties API, the AEC Data Model API, the Data Exchange API — with the Autodesk Tokens API underneath as the Platform Services front door. The Vault Data API is not among those 69. The catalog knows Autodesk’s construction estate in depth and has not yet met its manufacturing PDM surface, which is roughly what you would expect of an API whose feature parity its own vendor describes as evolving.
Autodesk scores 55.5, strong on the Kin Score, on contract quality at 75.0 and developer ergonomics at 72.6, held back by governance at 18.2 and operational transparency at 26.3. Agent Readiness is 44.9, agent-ready, with a notably deep lit row that includes error_semantics, event_surface_described, agent_skills, reversibility_documented and — rarest of these — delegated_identity, which is the dimension that matters most when the integration in question is a PLM system acting for an engineer rather than as itself. idempotency is unlit, which is the one that would sting in this specific migration: SOAP clients that retried a check-in against a vault got their semantics from the SDK, and a REST surface has to say so in the contract instead.