How Far Does the Revit API Reach
Technical capabilities that change the way projects are delivered
At the time I became involved in add-in development, Autodesk Revit was already an established tool with a clear position in the market. In Slovakia and the Czech Republic, it was used by companies that knew exactly why they were using it and what value they expected from it. Even back then, very advanced add-ins were being developed, demonstrating that Revit’s potential extends far beyond basic model authoring.
The question was therefore not whether an add-in made sense.
The question was how far it was possible to go.
This article is not an introduction to add-ins, nor a justification of their necessity. It is a view of Revit as a platform that allows part of the decision-making process to be shifted from the designer’s head into the system itself. Not abstractly, but very concretely—through control, automation, managed parametrization, and integration with other systems.
I will not be telling stories or presenting general guidelines. What follows are specific principles and capabilities that fundamentally change the way projects are worked on in practice.
And this is exactly where Pandora’s box is opened—not as a problem, but as a consequence of technical possibilities.
DockPanel
An add-in is not an external application. It is an integrated part of the Revit environment and behaves accordingly. It extends Revit’s capabilities—and in the best cases, replaces native solutions altogether. It can include custom icons, functions, parameters, information panels, and virtually anything that imagination (and the API) allows.
Updater
The most fundamental discovery within the entire Revit API. Something like a watchdog.
Whatever you do in a project—insert an element, move it, change a parameter—the Updater is aware of it and can react accordingly. Let me correct myself: it very fundamentally changed the philosophy of the entire add-in and, not least, the way parametric families are created.
Why? Because we suddenly start talking about controlled updates.
Whatever you do in a project—insert an element, move it, change a parameter—the Updater is aware of it and can react accordingly. Let me correct myself: it very fundamentally changed the philosophy of the entire add-in and, not least, the way parametric families are created.
Why? Because we suddenly start talking about controlled updates.
Family Creation
Anyone who has created a complex parametric family knows that with every additional dimension, constraint, or visibility rule, the family grows in size. And with it, the project grows as well—along with slower performance and reduced working comfort.
Not to mention the complexity of defining conditions themselves and maintaining them over time.
If you are creating parametric families today and are not using an Updater, you are doing it… the old way.
Trust me—I know what it means to build families.
Not to mention the complexity of defining conditions themselves and maintaining them over time.
If you are creating parametric families today and are not using an Updater, you are doing it… the old way.
Trust me—I know what it means to build families.
Parametrization
A topic that is not limited to international companies.
You may be a Slovak company working with an English-speaking client. Or you may have a family with English parameters, while the project is delivered to Germany. In which language should the parameters be defined? And their values?
Should they be codes that the designer must remember? Or full textual descriptions? And how will conditions defined directly in the family react to this?
A solution exists. It is elegant—and not far away.
Using a DockPanel, the original parameter interface can be replaced so that the designer sees parameter names and values in a readable form and in the selected language. The Updater then takes care of updating values and graphical changes.
Clean. Fast. Universal.
And one hidden advantage? Read on.
You may be a Slovak company working with an English-speaking client. Or you may have a family with English parameters, while the project is delivered to Germany. In which language should the parameters be defined? And their values?
Should they be codes that the designer must remember? Or full textual descriptions? And how will conditions defined directly in the family react to this?
A solution exists. It is elegant—and not far away.
Using a DockPanel, the original parameter interface can be replaced so that the designer sees parameter names and values in a readable form and in the selected language. The Updater then takes care of updating values and graphical changes.
Clean. Fast. Universal.
And one hidden advantage? Read on.
Reporting
It does not matter in which language a family, its parameters, or their values are defined. The same dictionary used in the DockPanel can be applied to generate reports—for clients speaking any language, or even in multiple languages at once.
In addition, custom templates can be defined for individual family types, allowing values from different parameters to be grouped into coherent descriptions.
Your ERP system will thank you for it.
In addition, custom templates can be defined for individual family types, allowing values from different parameters to be grouped into coherent descriptions.
Your ERP system will thank you for it.
Grouping and Typification
I am not claiming we reinvented the wheel. But merging typologically identical families based on predefined parameters can sometimes be a real challenge.
Identifying atypical dimensions, pairing identical components, rounding to standardized sizes or packaging units, assigning unique identifiers, quantifying quantities…
Would you like to know how many milliseconds this takes for a properly configured add-in?
Identifying atypical dimensions, pairing identical components, rounding to standardized sizes or packaging units, assigning unique identifiers, quantifying quantities…
Would you like to know how many milliseconds this takes for a properly configured add-in?
Something Extra
Are auxiliary installation components familiar to you?
Yes—those elements that are not modeled directly in the project, but still need to appear in schedules and quantities. Various trims, guides, screws, washers, sealants, and other small components that would only unnecessarily burden both graphics and project workload.
I have good news. You tell me which family they are associated with, which dimension they depend on—we can even add a coefficient—and the rest is handled automatically.
And by the way: this can easily be project-specific. The configurator can handle a lot.
Yes—those elements that are not modeled directly in the project, but still need to appear in schedules and quantities. Various trims, guides, screws, washers, sealants, and other small components that would only unnecessarily burden both graphics and project workload.
I have good news. You tell me which family they are associated with, which dimension they depend on—we can even add a coefficient—and the rest is handled automatically.
And by the way: this can easily be project-specific. The configurator can handle a lot.
Control
My favorite part. And with a clear conscience, I would say it is the cherry on top.
Imagine inserting an element into a wall or a panel. What can the Updater do for you? Not only can it automatically adjust the element’s parameters, but it can also check critical dimensions and clearances.
And if something does not fit? It can provide a clear warning—via an information panel in the DockPanel, additional graphics in the selected view, or an entry in the report. The choice is yours.
Imagine inserting an element into a wall or a panel. What can the Updater do for you? Not only can it automatically adjust the element’s parameters, but it can also check critical dimensions and clearances.
And if something does not fit? It can provide a clear warning—via an information panel in the DockPanel, additional graphics in the selected view, or an entry in the report. The choice is yours.
Automation
Just a few examples.
I have worked on projects where a basic wall with inserted elements was automatically transformed into a panelized wall with a complete adjacent structure—while preserving the original elements.
I have also implemented automated generation of suspended ceilings, where the system created the entire supporting structure, including hangers, and even performed trimming against HVAC components.
Currently, I am working on a study involving underfloor, ceiling, and wall heating—and I am genuinely enjoying it.
I have worked on projects where a basic wall with inserted elements was automatically transformed into a panelized wall with a complete adjacent structure—while preserving the original elements.
I have also implemented automated generation of suspended ceilings, where the system created the entire supporting structure, including hangers, and even performed trimming against HVAC components.
Currently, I am working on a study involving underfloor, ceiling, and wall heating—and I am genuinely enjoying it.
Export
A very important part of virtually every project.
And I am not talking only about CSV, Excel, or PDF files. The data processed by the add-in continues further—into exchange databases or directly into ERP systems, where it is handled by manufacturing, procurement, and sales.
Without manual retyping. Without errors caused by the human factor.
Of course, this depends on cooperation and system capabilities—but that is exactly what we are here for.
And I am not talking only about CSV, Excel, or PDF files. The data processed by the add-in continues further—into exchange databases or directly into ERP systems, where it is handled by manufacturing, procurement, and sales.
Without manual retyping. Without errors caused by the human factor.
Of course, this depends on cooperation and system capabilities—but that is exactly what we are here for.
It is not always simple—but it is possible.
Implementing an add-in requires a disciplined approach from both sides. A key phase is the initial analysis, where customer requirements meet the real capabilities of the API and the developer. This is where boundaries and implementation stages are defined.
A proven approach is to start slowly—by modifying the environment and introducing smaller, simpler functions. Over time, the designer begins to understand the connections, and paths open up that were not visible before.
And this is precisely where the role of us, project managers and technical partners who understand the system as a whole, begins. When a simple add-in becomes a comprehensive extension with a significant impact on the entire organization.
Ask questions, discuss, look for solutions.
If you are interested in specific technical capabilities or have your own questions, I will be happy to discuss them with you.
Ing. Lubos RODANIC
I am a technical architect and developer focused on CAD, ERP and system integrations. For more than 15 years, I have been working at the intersection of engineering, data and business processes—from developing CAD add-ins, through DMS/PLM systems, to ERP, web solutions and IT infrastructure.