Solid Edge vs SolidWorks API: a neutral comparison for automation and AI in 2026

If your company designs in Solid Edge or SolidWorks, every automation and every AI application runs through that system’s API. On paper the two APIs look alike; in practice they differ in how you start (recorder or Visual Studio), how variants are stored and what your PDM allows. This comparison refers to SOLIDWORKS 2026 and Solid Edge 2026. The public preview of SOLIDWORKS 2027 started on 15 July 2026, and on 15 October 2026 Siemens announced Solid Edge 2027 for 11 November, with commands launched through Copilot and agentic workflows. Neither announcement describes API changes so far. Inventor, CATIA and Siemens NX side by side are covered in our CAD API comparison; this article goes deeper into the two systems only.

Solid Edge vs SolidWorks API at a glance

Solid Edge and SolidWorks both expose a COM API for VB.NET, C# and C++ programs and for add-ins. The differences sit around the API. SolidWorks has a macro recorder, a VBA editor and configurations inside one file. Solid Edge splits its API into type libraries per environment and creates family of parts members as separate files.

Where the table shows no winner, there is none. Both APIs read and change features, assemblies, drawings and properties, and both load add-ins into the CAD process. The rows that decide projects are macros, variants and PDM.

Both APIs use COM, with different object models

Both APIs are COM interfaces that .NET programs reach through interop assemblies, and both connect through a ProgID: SldWorks.Application and SolidEdge.Application. Below that level the object models differ. SolidWorks routes common document work through IModelDoc2 and its document types, Solid Edge works with collections and a separate type library for each environment.

In SolidWorks, one reference to the sldworks interop plus the constants covers parts, assemblies and drawings. In Solid Edge, the Framework type library is mandatory, and you add the Part, Assembly or Draft library for every environment your code touches. In its migration guide for SolidWorks programmers, Siemens names collections as the main difference; documents, for example, are added to a Documents collection that also reports how many files are open. The short program below connects to both systems and shows the parallel.

// .NET Framework 4.8 console app. References: SolidWorks.Interop.sldworks (from the SOLIDWORKS
// API redist folder) and the COM type library "Solid Edge Framework Type Library".
// Both systems must be running with a document open.
using System;
using System.Runtime.InteropServices;

class Program
{
    [STAThread]
    static void Main()
    {
        // SOLIDWORKS: one main type library, common document functions on IModelDoc2
        var sw = (SolidWorks.Interop.sldworks.SldWorks)Marshal.GetActiveObject("SldWorks.Application");
        var swDoc = (SolidWorks.Interop.sldworks.ModelDoc2)sw.ActiveDoc;
        Console.WriteLine("SOLIDWORKS: " + swDoc.GetPathName());

        // Solid Edge: Framework type library plus one library per environment, collections throughout
        var se = (SolidEdgeFramework.Application)Marshal.GetActiveObject("SolidEdge.Application");
        var seDoc = (SolidEdgeFramework.SolidEdgeDocument)se.ActiveDocument;
        Console.WriteLine("Solid Edge: " + seDoc.FullName + " (" + se.Documents.Count + " documents open)");
    }
}

External programs have to handle busy COM servers in both systems. The Solid Edge programmer’s guide has its own chapter on the errors “Application is Busy” and “Call was Rejected By Callee”.

The practical consequence is that code does not move between the two systems by search and replace. The CAD-facing layer is rewritten, and the business logic (rules, naming, tables) survives only if it was kept apart. We recommend that separation from the first macro on, even if you use only one system today. More on the Solid Edge side, from type libraries to deployment, is in our article on the Solid Edge API.

Macros and the recorder make the clearest difference

SolidWorks lets a designer record a macro, edit it in the built-in VBA editor and run it the same day. Solid Edge has neither a macro recorder nor a VBA editor, which Siemens states in its own migration guide. A Solid Edge macro is a program built in Visual Studio and started with the Run Macro command.

SolidWorks: VBA and VSTA

The recorder saves VBA as an .swp file or creates VSTA projects in VB.NET or C# that build to a .dll. Recording, editing or debugging VB.NET and C# macros in SOLIDWORKS 2023 and later requires Visual Studio 2019; without VSTA, the macro dialogs offer only VBA.

Solid Edge: programs from Visual Studio

The Solid Edge programmer’s guide starts with a Visual Studio project, for automation without user interaction a console application that references the Solid Edge Framework type library. The Run Macro command and the RunMacro method of the API start such a program. Control returns as soon as the macro has been launched, so it may still be running.

A recorded macro is a good way to find the right API call and rarely a good tool for 20 designers. Recorded code depends on selections, the active document and the order of clicks. For production use we rewrite recorded logic as an add-in or program with error handling, whichever system it comes from. The recorder speeds up the first day in SolidWorks, and after that the gap shrinks. Autodesk Inventor has a third model with rules stored in the files, compared in iLogic vs Inventor API.

Add-ins work alike, with different entry points

In both systems an add-in is a COM component that the CAD program loads and that adds commands, panes and event handlers. SolidWorks calls ConnectToSW and DisconnectFromSW on the ISwAddin interface. Solid Edge calls OnConnection and OnDisconnection on ISolidEdgeAddIn, plus OnConnectToEnvironment whenever an environment such as Part or Draft connects.

A SolidWorks add-in registers its class ID in the AddIns key of the Windows registry, .NET add-ins with RegAsm. The SOLIDWORKS API SDK installs Visual Studio templates for C# and VB.NET. For batch jobs it matters that add-ins do not load when a program starts a new SolidWorks session, even if they are set to start up; the program has to load them with LoadAddIn.

In Solid Edge the environment event is the main design difference, because an add-in can offer its commands only where they make sense, for example in Draft. Open-source templates for C# and VB.NET come from the Solid Edge Developer Community and were presented on the Siemens Solid Edge blog.

For AI applications both forms work, and the choice follows the same rule as for any automation: an add-in for functions a team uses every day, an external program for batch jobs. Every write is a preview that an engineer confirms, with one undo step per change, as described for the AI assistant for SolidWorks.

Drawings and variants follow different ideas

Drawings are comparable, because both APIs create sheets, views, dimensions and title block entries. Variants are where the systems think differently. SolidWorks keeps variants as configurations inside one file, often driven by an Excel design table. Solid Edge creates a separate file for each family of parts member and drives dimensions through the variable table.

Drawings

SolidWorks exposes drawing operations on IDrawingDoc. Solid Edge has its own Draft type library with DraftDocument, sheets and the DrawingViews collection. In both systems the template decides more than the API, because a clean drawing template with fixed property links saves more code than clever view placement.

Configurations against family of parts

In SolidWorks, IConfigurationManager gives access to the configurations of a model and IDesignTable to its design table. In Solid Edge, the FamilyMembers collection of a part document holds the family members. The Variables collection creates variables and treats every dimension as a variable, with formulas, external functions and spreadsheets.

Neither model is better. One file with many configurations keeps the file count low, but it puts a lot of logic into a single file, and a change touches every variant. Separate member files are easier to release one by one, while your PDM has to manage many more files. For assembly variants with drawings and BOMs, both systems end up with a program that sets values, replaces components and updates the drawing.

PDM and files outside the CAD session

Check the PDM edition before you plan workflow automation. The SOLIDWORKS PDM Professional API reaches vaults, data cards, workflows, states and transitions, while SOLIDWORKS PDM Standard has no API. Solid Edge brings its own file-based data management with Design Manager, and Siemens provides separate type libraries for file properties and for Design Manager.

SolidWorks: PDM Professional and Document Manager

With PDM Professional you write stand-alone programs, or add-ins that PDM calls when users check files in or out, add them to the vault or change their state. On PDM Standard the API returns the error E_EDM_STANDARD_APINOTSUPPORTED. Both editions are compared on our SolidWorks PDM page.

For batch work on closed files, the SOLIDWORKS Document Manager API reads and writes properties and references without starting SolidWorks. It needs a license key that only subscription customers receive through the customer portal. Each user needs a key, and it is renewed with every major release.

Solid Edge: built-in data management

Solid Edge Data Management is built in and works on the file system. Search and where-used depend on Windows indexing, and Design Manager handles revising and copying. Programs work with properties through the file properties type library and with links through the Design Manager and Revision Manager libraries.

If a data management decision is due anyway, make it before the automation. An add-in that writes properties works in every setup, a workflow add-in only in the PDM it was written for.

Documentation and community

SolidWorks has the larger public footprint, with API Help online for every release, examples in VBA, VB.NET and C# and a large user forum full of published macros. Solid Edge documents its API in the SDK with a programmer’s guide and a type library reference. Its developer community is smaller, but active and partly open source.

Both APIs are large. The SOLIDWORKS API Help speaks of hundreds of functions, and the Solid Edge programmer’s guide by Siemens says it takes most people several years to feel comfortable with the API.

For Solid Edge, Siemens provides sample programs for the SDK through its Support Center, and the Solid Edge Developer Community publishes tools such as Spy for Solid Edge on GitHub. In practice, an existing answer for SolidWorks is usually one search away. For Solid Edge you read the type library reference more often yourself, which costs time at the start.

What this means for a project

In most companies the CAD system is already set, so the real decision is the form of the solution and the PDM edition it has to work with. The differences between Solid Edge and SolidWorks show up in the first weeks of a project. What can be automated in the end is similar in both systems.

• Prototype: in SolidWorks a designer records and adapts a VBA macro without Visual Studio. In Solid Edge the first prototype is a small Visual Studio project.
• Rollout: in both systems, a function used by a whole team becomes an add-in with versioning and a test run on each major release.
• Variants: SolidWorks configurations and Solid Edge family members need different PDM rules, so settle those before writing code.
• PDM workflows: SOLIDWORKS PDM Standard has no API, so workflow automation needs PDM Professional.

Is one system clearly better for automation and AI? No. SolidWorks is easier to start with and has more public examples. Solid Edge separates its API cleanly by environment, and its family member files are easier to release one by one. CAD service providers that support both systems should keep rules, tables and naming apart from the CAD calls, so that only the CAD-facing part is written twice.

Already know which system you want to automate? Our pages on Solid Edge automation and SolidWorks automation show typical tasks and how a first project is scoped.

Frequently asked questions