Revit API en español: primeros pasos para automatizar Revit con C# (2026)

Revit guarda tu proyecto como una base de datos. Cada muro, cada puerta, cada vista y cada parámetro es un registro con propiedades.

Cuando haces clic en un muro y cambias su altura, Revit está actualizando ese registro. La interfaz gráfica es sólo una forma cómoda de editar la base de datos.

La API es la otra forma de editarla: por instrucciones en vez de por clics.

Eso cambia dos cosas:

• Escala. Lo que a mano son 400 clics, por instrucción es una orden que se ejecuta 400 veces.
• Repetibilidad. La instrucción hace exactamente lo mismo cada vez. No se cansa ni se salta un elemento.

Lo que la API sí puede hacer

• Leer cualquier propiedad de cualquier elemento del modelo.
• Crear, modificar y borrar elementos.
• Recorrer todos los elementos que cumplan un criterio y actuar sobre ellos.
• Generar vistas, planos y tablas.
• Exportar información a Excel, CSV o cualquier otro formato.
• Añadir botones propios a la barra superior de Revit.

Lo que no

• Hacer algo que Revit no permite hacer de ninguna manera. La API no expande lo que Revit sabe hacer; expone lo que ya sabe.
• Arreglar un modelo mal construido. Automatizar sobre un modelo desordenado escala el desorden.

La lista es más corta de lo que la gente supone, y no cuesta dinero.

Revit instalado. El que ya usas. Anota la versión exacta: un add-in compilado para Revit 2024 no carga en 2026 sin recompilar.

Visual Studio Community. El editor donde escribes el código. Es gratuito para uso individual y pequeñas empresas. Al instalarlo, marca la carga de trabajo de desarrollo de escritorio con .NET.

Las librerías de Revit. Son dos archivos que ya están en tu computadora, dentro de la carpeta de instalación de Revit: RevitAPI.dll y RevitAPIUI.dll. No se descargan, se referencian desde tu proyecto.

La documentación. El Revit API Docs de la comunidad y el Revit Developers Guide de Autodesk. Están en inglés — es la principal barrera de entrada, y la razón por la que casi todo el contenido bueno de este tema está en ese idioma.

Un add-in de Revit tiene tres piezas. Entender qué hace cada una te ahorra mucha confusión.

1. El comando. El código que se ejecuta cuando el usuario aprieta tu botón. Es el punto de entrada: Revit te entrega el documento abierto y tú haces lo tuyo.

2. El archivo .addin. Un archivo de texto que le dice a Revit dónde está tu programa. Va en una carpeta específica del sistema y Revit lo lee al arrancar. Sin él, tu add-in no existe para Revit.

3. La DLL compilada. El resultado de compilar tu código. Es lo que el archivo .addin apunta.

La estructura que evita el dolor a los 6 meses

Casi todos los tutoriales meten todo el código dentro del comando. Funciona para un ejemplo y se vuelve inmanejable en cuanto crece. La estructura que sí aguanta separa tres responsabilidades:

• Comando — recibe el clic, muestra mensajes al usuario, maneja errores. Nada de lógica de negocio.
• Servicio — la lógica real: qué hay que calcular, con qué reglas. No sabe nada de ventanas ni de botones.
• Acceso al modelo — leer y escribir en Revit. Aislado, para que cambiar de versión de Revit toque un solo sitio.

Si vas a recordar una sola cosa técnica de esta guía, que sea esta.

Todo cambio al modelo tiene que ir dentro de una transacción. Sin excepción. Revit lanza un error si intentas modificar algo fuera de una.

No es burocracia. Es lo que hace posible el Ctrl+Z: la transacción agrupa un conjunto de cambios en una unidad. O se aplican todos, o no se aplica ninguno.

El patrón es siempre el mismo:

1. Abres la transacción, con un nombre descriptivo.
2. Haces todos los cambios.
3. La confirmas.

Si algo falla en medio, la cancelas y el modelo queda exactamente como estaba. Nada a medias.

El nombre de la transacción sí importa

Ese nombre es lo que el usuario ve en el menú de deshacer. "Transacción1" no le dice nada a nadie. "Renombrar vistas por estándar" sí. Es un detalle de dos segundos que cambia la percepción de calidad de tu herramienta.

Casi todos los tutoriales empiezan creando un muro. Es un mal primer proyecto: nadie necesita crear muros por código, y no resuelve ningún dolor real.

Los criterios de un buen primer proyecto:

• Que sea una tarea que hoy haces a mano y te molesta.
• Que sólo lea el modelo, sin modificarlo. Cero riesgo mientras aprendes.
• Que el resultado se pueda verificar a simple vista.
• Que se pueda terminar en pocas horas.

Candidatos que cumplen los cuatro:

Exportar un listado de elementos a Excel. Recorres todos los elementos de una categoría, lees los parámetros que te interesan, y escribes un archivo. Útil desde el primer día y sin riesgo.

Auditar nomenclatura. Recorres las vistas (o las familias, o los niveles) y listas las que no cumplen el estándar de la oficina. No cambia nada: sólo reporta. Es la herramienta que más rápido se gana la confianza del equipo.

Contar y clasificar. Cuántos elementos hay de cada tipo, agrupados como los necesita tu presupuesto.

Detectar parámetros vacíos. Lista los elementos a los que les falta información obligatoria antes de una entrega.

Se repiten con una regularidad casi cómica. Saberlos de antemano ahorra días.

1. "Mi add-in no aparece en Revit." Casi siempre es el archivo .addin: está en la carpeta equivocada, o la ruta a la DLL no coincide, o Revit no se reinició. Revisa esas tres antes que el código.

2. "Funcionaba y ahora no carga." Actualizaste Revit. Un add-in compilado contra las librerías de una versión no carga en otra. Hay que recompilar apuntando a las nuevas.

3. "Me da error al modificar el modelo." Falta la transacción, o está mal cerrada.

4. "Tarda muchísimo." Casi siempre son transacciones dentro de un bucle, o recorrer todo el modelo varias veces en vez de una. Recorre una vez, guarda lo que necesitas, y trabaja sobre eso.

5. "Funciona en mi máquina pero no en la de mi compañero." Rutas absolutas escritas a mano, o falta desplegar la DLL. Es el momento de armar un instalador de verdad en vez de copiar archivos a mano.

Es una decisión de negocio, no técnica, y conviene tomarla con los ojos abiertos.

Tiene sentido aprenderlo si:

• Hay muchas tareas distintas que automatizar, no una.
• Alguien del equipo tiene interés genuino y tiempo asignado — no "en los ratos libres".
• Las reglas cambian seguido y quieres poder ajustarlas sin depender de nadie.

Tiene sentido encargarlo si:

• Es una herramienta concreta y bien definida.
• La necesitas funcionando este trimestre, no el próximo año.
• Nadie del equipo tiene tiempo real disponible.
• Va a usarla toda la oficina y tiene que ser robusta desde el día uno.

Lo que mejor funciona en la práctica es mixto: encargar la primera herramienta seria y pedir que el equipo participe del proceso. Se resuelve el problema urgente y queda capacidad instalada para lo siguiente.