SolidWorks Macro vs API vs Add-in: Which One Do You Need?

A macro is a small program that runs inside SolidWorks and collapses a specific task into a single command. It is produced in two ways:

By recording. The operations you perform while the Macro Recorder is running are written out as code. This is the fastest way to learn the API: doing an operation by hand and looking at the generated code shows you directly which method on which interface is called.

By writing. Recorded code is rarely production ready — it usually comes out dependent on selection, on the active document, and on the state of the screen. A real macro emerges by rewriting that code by hand.

Macros are written in VBA and stored as a .swp file. That file is both executable and the source code itself; being a single piece makes sharing easy. SolidWorks also supports .NET-based macros (.swb).

A macro's defining property is not that it is a single file but its lifecycle: it starts when the user calls it, does its job, and ends.

The API (Application Programming Interface) is the layer that gives external access to the SolidWorks object model. The names you meet while writing code are parts of that model:

• SldWorks — the application itself
• ModelDoc2 — an open document (part, assembly or drawing)
• PartDoc, AssemblyDoc, DrawingDoc — interfaces specific to the document type
• CustomPropertyManager — custom properties
• ISwAddin — the interface through which add-ins register with SolidWorks

The API is COM-based. In practice that means the same object model can be reached from VBA, from C#, from C++, and from Python's COM bridge. What you reach does not change; the program doing the reaching does.

That is why the question "should I use the API or a macro" does not quite land technically. The right question is about architecture.

The mental model is built like this — five layers from the top down:

1. SOLIDWORKS — the application itself.
2. The SOLIDWORKS API — the layer that lets you reach the application from code (it works over COM).
3. Language — which language you call that layer with: VBA, C#, VB.NET, C++ or Python.
4. Form — which container what you write sits in: a macro, an add-in, or a standalone application.
5. CAD automation — all of the above applied to an engineering process.

The source of the confusion is that the third and fourth layers are constantly mixed up. "Should I write a macro or use the API" is a badly formed question for that reason: when you write a macro you are already using the API. The right question concerns the fourth layer — which container?

The third row from the bottom is where the decision is made. The two rows above it are fixed; the row below it is what the work actually amounts to.

Collapsing repeated operations into one command

If an engineer performs the same 12–15 steps on every drawing — placing views, setting the scale, filling title block fields, saving, exporting PDF — that flow can be reduced to a single button. The gain is small once; multiplied by the repetition count, it grows.

Standardisation

This is the side of macros that gets discussed least but makes the biggest difference in the field. A macro does not only speed the work up, it makes everyone do the same job by the same rule. File naming, revision fields, output folders, layer mapping — done by hand these vary from person to person. In code there is a single definition.

The measurable gain of an automation project usually comes not from time but from that consistency. A single misnamed DXF takes back every minute it saved, in production.

Reducing the risk of human error

The places where risk concentrates are known: file names, revision numbers, custom properties, output folders, layer and colour mapping, unit selection. All of them are repetitive and attention-demanding — which is to say, exactly where people slip most easily.

Batch processing

Processing a folder from start to finish instead of opening and saving 100 drawings one by one is a macro's most visible gain.

There is a distinction here that often gets skipped. For bulk PDF/DXF, the Task Scheduler or PDM tasks are usually recommended. Both work — but both depend on licence level and their rules are fixed. A macro or API-based solution runs on SolidWorks Standard and writes the rule according to your process: which configuration, which layer mapping, which naming template, under which condition to skip. A ready-made tool "converts the file"; code "converts it by your rule."

Automating production output

PDF, DXF, DWG, STEP, STL, BOM and Excel output — this is the point where design passes into manufacturing, and it is also where mistakes are most expensive.

Combined with a parametric model

An important distinction: parametric design is not a macro. A parametric model is geometry bound to rules; a macro is code that can drive those rules from outside. Each is useful on its own; combined, the automation changes class: the user enters a few dimensions, the model builds itself, and the drawing and production output follow.

The items I meet most often in the field:

• Bulk reading, writing and validating of custom properties
• Bulk PDF / DXF / DWG generation from drawings
• STEP / STL export from parts
• Binding file naming and revision fields to a rule
• Exporting the BOM and matching it against Excel
• View placement, scale and title block filling
• Configuration generation and table-driven variant creation
• Standards compliance checking on models and drawings

What these have in common: they are all jobs that can be bound to a rule. Jobs that require judgement — which design is correct, which tolerance is appropriate — are not on this list, and should not be.

A macro is usually the right and sufficient choice in these situations:

• The number of people using the tool is small; often just the person who wrote it
• The job is a flow that starts and ends with a single command
• The task has limited scope, such as bulk export or property editing
• You need to validate quickly whether the idea works at all (proof of concept)
• The process has not settled; the rule changes from week to week

That last point matters. Building an add-in architecture on top of a process whose rules are undefined is one of the most expensive mistakes there is. In such cases a macro is not just the fast solution but the right one — because it is cheap to throw away.

I am deliberately careful with the language here: this is not a list of jobs macros "cannot do." A surprising amount can be done with VBA. The problem is not capability but sustainability.

The line has been crossed when these symptoms start appearing:

• Continuous operation is needed. A macro starts when called and ends. Behaviour that listens in the background as long as SolidWorks is open (check when a document opens, validate before saving) runs against a macro's lifecycle.
• Event handling is needed. Hooking into save, open and rebuild events is the job of an add-in architecture.
• The interface is growing. Beyond a simple input box — a CommandManager tab, a TaskPane, a PropertyManagerPage — VBA forms quickly fall short.
• There is team-wide distribution. Ten people updating a macro file by hand works right up until the first revision.
• Central updates are needed. If you cannot tell who is using which version, you cannot trust the output the automation produces.
• Error handling and logging have to be taken seriously. Finding a problem from "it didn't work" feedback is a guessing game without logs.
• Version control and tests are needed. A single-file binary format is not suited to code review or diffing.
• Integration enters the picture. A PDM, ERP, database or external service connection requires dependency and authentication management.

It is more productive to ask the question this way: not "Is it technically possible?" but "Will this architecture still be standing a year from now for this job?"

How you read the table matters: the right-hand column does not mean "better." The left-hand column is more correct for small, undefined jobs — because it carries no architectural cost.

The decision comes down to three questions:

How many people will use it? One person, VBA. A team, and you have a distribution and update problem; that is what the .NET side is for.

How long will it live? For a need lasting a few weeks, VBA. If it will live for years alongside the process, maintenance cost overtakes setup cost quickly.

How intertwined with SolidWorks will it be? A single command the user calls, VBA is enough. If it changes SolidWorks' behaviour — adds a tab to the interface, controls saving, runs checks at startup — you need an add-in architecture.

Python sits in a separate place outside this table: it suits rapid prototyping, data processing and certain automation scenarios over COM, but it does not offer an interface embedded inside SolidWorks. I covered its limits separately in where Python fits in SolidWorks automation.

1. The same custom properties are filled on every drawing. Approach: a VBA macro. One command, one file, a quick win.

2. PDF and DXF output is needed from hundreds of parts. Approach: macro or API-based batch processing. If the rule is complex (different layer mapping per configuration, conditional skipping), code beats a ready-made tool.

3. The user enters a few dimensions and a complete assembly is built. Approach: parametric model plus API. The real work here is not in the code but in building the model's rules soundly. A badly built parametric model will not carry even the best code.

4. A custom SolidWorks interface is needed across the company. Approach: a C#/.NET add-in. CommandManager tab, central updates, user settings.

5. There is data exchange between SolidWorks and ERP/PDM. Approach: API plus an integration layer, and an add-in where needed. The critical point is whether the data flow is one-way or two-way; if two-way, conflict resolution must be designed from the start.

6. 3D models are generated from 2D drawings according to rules. Approach: parametric rules plus the API, with an AI-assisted interpretation layer where needed. I went into this scenario in automating 2D drawings into 3D models.

The order is simple and should not be reversed:

1. Measure first. Which job, how often, taking how long? Without that measurement it does not matter which tool you pick. I described the method step by step in how to start an automation project.
2. Validate with the smallest working solution. Usually that is a macro.
3. Watch how it gets used. Who uses it, where do they get stuck, which rule changes?
4. Grow the architecture as the need grows. The add-in decision is made when a macro's limit has actually been hit — not when it is predicted that it will be.

When calculating whether the gain is real, development and maintenance cost belong in the equation too; for that I use the approach in measuring automation gains.

In my own projects I have almost never started with an add-in.

The order I have followed in SolidWorks automation work has always been the same: measure the repeated job first, confirm the rule is right with a small macro, and grow the architecture once the rule has settled in the field. That is how I made the moves from VBA to a C#/.NET add-in architecture too — the decision to move was not a preference but the result of accumulated symptoms: the team grew, distribution became a problem, event-based behaviour was needed.

You can see the concrete result of this approach in two places: the SolidWorks CAD automation case study covers the move from macro level to an add-in architecture, and ParametriX covers where parametric design meets API automation.

I use AI in this process but knowing its limits: it genuinely accelerates scaffolding and API discovery, and it is confidently wrong about the COM lifecycle and silent failures. I went into the distinction in writing a SolidWorks add-in with AI.

Are a SolidWorks macro and the API the same thing? No. The API is the access layer; a macro is one of the application forms that uses it. When you write a macro you are already using the API.

Which language are SolidWorks macros written in? Primarily VBA. SolidWorks also supports .NET-based macros. Add-ins are written in C#, VB.NET or C++.

Does the SolidWorks API cost extra? The API is part of the SolidWorks licence; it is not sold as a separate product. The capabilities you can reach vary with the SolidWorks version you use.

Should I choose a macro or an add-in? Look at how many people will use it, how long it will live, and how intertwined with SolidWorks it will be. Single user and a single command, a macro; a team, an interface and event handling, an add-in.

Is the SolidWorks API hard to learn? The object model is broad but the entry threshold is low. Recording an operation with the Macro Recorder and looking at the generated code moves you forward faster than starting from the documentation.

When does a macro fall short? When continuous operation, event handling, team-wide distribution, central updates, advanced error handling or enterprise integration are needed. This is a sustainability limit, not a capability limit.

What is the difference between parametric design and a macro? Parametric design is geometry bound to rules; a macro is code that drives those rules from outside. Combined, they produce far more powerful automation.

"Macro or API" is a question that needs correcting rather than answering. The API is underneath every route already; the choice is which architecture you reach it with.

A practical summary:

• Small, single-user, short-lived job → a macro
• Team-wide, continuously running work needing an interface and integration → a C#/.NET add-in
• The decision between the two → a question of architectural sustainability, not capability
• In every case → measure first, validate with the smallest solution, then grow

If you repeat the same SolidWorks steps on every order or every project at your company, we can assess together whether the process suits automation at macro, API or add-in level — write to me from the contact section.