Revit API development: what you can build, and what a dependable add-in takes

The Revit API is a .NET library installed with Revit. Autodesk describes it as an API that lets you automate repetitive tasks and extend the software's core functionality. An add-in loads into Revit's own process and works on the open model through the same objects Revit uses.

Almost everything in that model is an Element: walls, doors, views, sheets, even the types that define them. Code finds elements with a FilteredElementCollector, reads and writes their parameters, and creates new ones. Every change to the model happens inside a Transaction, and each transaction appears as one step in Revit's undo list.

Revit stores every length internally in decimal feet. An office that has never measured anything in feet still gets every wall length back from the API in feet, and the add-in converts it before anyone sees a number.

Not every Revit task needs a compiled add-in. The API is reachable from five places, and the right one depends on who runs the tool and how often:

• Macros: C# written inside Revit's own Macro Manager and saved with a model or the application. Good for a small personal task, awkward to share.
• Dynamo: visual graphs with Python nodes, run by the person who needs the result. Custom Dynamo script development covers when a graph is enough.
• pyRevit: an open-source framework that turns Python scripts into ribbon buttons, common for office toolbars.
• Compiled add-ins: C# projects built in Visual Studio and installed with a manifest, with their own ribbon, windows and settings. This is what most people mean by a Revit plugin.
• Design Automation for Revit: part of Autodesk Platform Services, the platform formerly called Forge. It runs Revit without an interface in Autodesk's cloud, so an add-in can process models from a web page or a batch job, reading its inputs from files instead of dialogs.

Most of what used to be called Autodesk Forge API development now happens under the APS name. For Revit it usually means Design Automation, and the add-in running inside it follows the same API rules as the desktop.

A command is a class that implements IExternalCommand. Revit calls its Execute method when someone clicks the button and discards the object when the method returns. A .addin manifest file in Revit's Addins folder tells Revit the command exists. Without it, Revit never sees the code.

An add-in with its own ribbon tab also has an IExternalApplication, which builds the panels and buttons when Revit starts. The TransactionMode attribute on each command decides who opens transactions. In Manual mode the command opens its own, and can group several into one undo step.

One rule stops most first add-ins: the API can only be called from Revit's own thread, while Revit is ready for it. A window that stays open beside the model has to hand its work to Revit through an ExternalEvent. Calling the API straight from that window fails with an exception.

The requests that reach a Revit developer tend to fall into these groups:

• Checks that read the model and report: naming, empty parameters, warnings, rooms without boundaries. A Revit model checker covers the rule-based end of this.
• Batch edits: renumbering sheets and views, renaming families, filling title-block fields across a set.
• Model generation from other data: walls from CAD linework, a structural frame from an analysis model, finishes from room boundaries.
• Data exchange: schedules out to Excel and back, parameters to a database, reports to a dashboard.
• Custom MEP add-ins: system naming, connector checks, sizing rules and hanger placement, wherever Revit's MEP tools stop short of the office standard.

CAD-to-Revit automation works through the model-generation case in detail.

Autodesk ships a Revit release every year, and an add-in is compiled against a specific version of the API. Most code carries over, but deprecated methods are removed, and each release needs its own build, test and installer.

Revit 2025 was the largest break in years. Autodesk's API notes say Revit 2025 is built on .NET 8 and that "Revit add-ins need to be recompiled for .NET 8." Revit 2024 ran on .NET Framework 4.8, so an office on both versions needs two builds. One project with multiple target frameworks produces both from the same code.

When you commission an add-in, ask who does that work each release, and what it costs.

The test model is clean. Real models aren't. This is where the development time goes:

• Worksharing: an element borrowed by another user can't be edited, and the add-in has to say which ones it skipped.
• Linked models: elements inside a link are read-only from the host, and sit in a different coordinate system.
• Warnings and failures: a change that creates duplicate instances or overlapping walls raises failures the add-in has to handle itself, instead of leaving a dialog for the user.
• Scale: a collector that runs a slow filter over every element is quick on a test file and slow on a hospital. Quick filters by class and category go first.
• Reporting: every element the add-in couldn't process, and why.

None of these show up in a demo. All of them show up in the first week on real projects.

If you already write C#, the path is well marked: the Revit SDK samples, the API reference on revitapidocs.com, and RevitLookup for inspecting what an element actually holds. Start with a macro or a single command, and leave the ribbon for later.

If the task runs once, or a Dynamo graph already does it, don't commission an add-in. You don't need us, or anyone like us, for that. Revit API development services earn their cost when the tool is used across projects, by people who didn't write it, through several Revit releases. How much Revit plugin development costs sets out what drives the price, and custom Revit plugin development is where we do that work.