Conectar Autodesk APS con n8n: OAuth y una consulta pequeña de proyectos
Veinte nodos, colores impecables y una conexión Autodesk que funciona porque alguien pegó un token a mano. Una instalación artística con fecha de caducidad. Si el workflow depende de volver a buscar a esa persona cada vez que vence el acceso, habéis automatizado la espera, no la autenticación. Antes de añadir cables, vamos a resolver quién autoriza la consulta, cómo vuelve a n8n y qué respuesta permite comprobar que está leyendo lo esperado.
El artículo de Autodesk del 5 de junio de 2026 muestra el uso de una credencial OAuth2 de n8n. Vamos a desarrollar un recorrido pequeño de lectura: conectar una cuenta, localizar un hub y consultar sus proyectos. Es una explicación contrastada con la documentación, sin ejecución real del workflow en esta pieza. Los nodos que todavía no se han probado pueden seguir siendo prometedores; lo que no pueden es figurar como resultados.
Tabla de contenidos
Qué necesitas autorizar antes de dibujar el workflow
n8n organiza tareas y puede realizar peticiones HTTP, pero no concede acceso a los proyectos de Autodesk por instalarlo. Hace falta una aplicación APS preparada para el flujo elegido y una persona autorizada sobre los recursos que se van a consultar. En los entornos que lo requieran, también interviene el administrador para permitir la integración. Una credencial correctamente obtenida puede encontrarse después con un recurso denegado: son comprobaciones diferentes, por mucho que apetezca resolverlas todas con el botón de reconectar.
Para este ejemplo, la finalidad es leer hubs y proyectos accesibles para la cuenta que conecta la credencial. El scope elegido es data:read, de acuerdo con las referencias de esas operaciones. No hay razón para solicitar permisos de escritura solo porque algún día podrías querer mover un archivo. Empezar por lectura permite comprobar identidad y datos sin introducir efectos que después haya que revisar o deshacer.
El nombre de la credencial debería ayudar a reconocer su función y el entorno al que pertenece. Una conexión personal de prueba y otra utilizada por un proceso compartido pueden necesitar responsables y reglas distintas. Si el workflow utiliza la cuenta de una persona, también depende de lo que ocurra con esa autorización. Programarlo para las tres de la mañana no convierte el acceso en una identidad de servicio; solo desplaza el momento en que descubrirás que necesita atención.
Conviene acordar además un recurso acotado para la primera comprobación. La cuenta puede ver varios hubs, pero eso no exige lanzar consultas sobre todos ellos. Elegir uno permite relacionar la respuesta con un entorno conocido y entender mejor cualquier falta de datos. Un prototipo que recorre cuanto encuentra parece muy activo, aunque su principal contribución sea ampliar el volumen de cosas que todavía no sabes interpretar.
Usaremos nombres actuales del producto cuando corresponda, manteniendo las rutas técnicas documentadas. Forma, ACC y Data Management pueden aparecer en partes distintas del recorrido. La URL de una API se obtiene de su referencia, no sustituyendo palabras hasta que coincida con el nombre comercial. Este detalle es especialmente útil al trasladar una demostración antigua a una instalación actual.
OAuth2: la URL de retorno tiene que ser la de tu instalación
En la credencial OAuth2 API de n8n, la OAuth Redirect URL identifica dónde debe regresar el navegador tras la autorización. Esa dirección se registra como callback en la aplicación APS. Hay que utilizar la que muestra el entorno real: una instancia local, una instalación pública y otra detrás de un proxy pueden presentar direcciones diferentes. Copiar una URL que se parece a la tuya es una aproximación creativa a un mecanismo que exige coincidencias precisas.
La documentación de credenciales HTTP Request de n8n describe el flujo Authorization Code y sus campos. El navegador lleva al usuario a Autodesk para autorizar; n8n recibe el código en el retorno y realiza el intercambio correspondiente. El client ID identifica la aplicación y el client secret del cliente confidencial se conserva en la credencial. No tienen que aparecer repartidos por nodos, expresiones o capturas del workflow.
Las pantallas pueden cambiar entre versiones, así que interesa reconocer la función de cada campo en lugar de reproducir una captura píxel a píxel. La opción de enviar credenciales en cabecera o en el cuerpo afecta al intercambio OAuth; no es una instrucción para añadir después secretos a todas las peticiones de datos. El nodo HTTP utilizará la credencial guardada para aportar la autorización que corresponda.
Al iniciar la conexión, revisa la cuenta y el consentimiento y comprueba que el retorno llega a n8n. Si se cancela, falta una coincidencia de callback o el intercambio se rechaza, ese recorrido debe resolverse antes de añadir consultas. Desactivar la comprobación TLS no corrige una URL mal configurada ni un secreto incorrecto. Solo consigue que la instalación acepte otro tipo de problema con menos garantías, una ampliación de alcance que nadie había pedido.
Una vez conectada, todavía queda comprobar cómo gestiona esa versión de n8n la renovación y persistencia de la credencial. Si una autorización deja de ser válida, el flujo necesita una salida comprensible y un responsable que pueda intervenir. Una pantalla de conexión satisfactoria acredita ese paso en ese momento; no demuestra que el proceso vaya a mantenerse indefinidamente sin supervisión.
Dos consultas pequeñas que permitan saber qué estás leyendo
El recorrido empieza con Manual Trigger y un nodo HTTP Request que seleccione la credencial OAuth2 guardada. La primera operación es GET https://developer.api.autodesk.com/project/v1/hubs, respaldada por la referencia de hubs. La credencial debe aportar la autorización; pegar un bearer token adicional en una cabecera manual puede ocultar si la conexión configurada funciona realmente y crear una dependencia que caduca por su cuenta.
La respuesta necesita una lectura antes de continuar. En su colección data se identifican los hubs devueltos y se elige el que corresponde a la prueba autorizada. Es útil conservar su identificador junto al nombre visible: los nombres ayudan a reconocer el entorno, mientras la llamada siguiente necesita la referencia técnica. Si la cuenta tiene varios accesos, escoger simplemente el primer resultado introduce una decisión que debería poder explicarse.
Con ese ID se prepara GET https://developer.api.autodesk.com/project/v1/hubs/{hub_id}/projects, siguiendo la referencia de proyectos de un hub. El marcador se sustituye por el ID devuelto para el hub elegido y se utiliza la misma credencial. No hace falta deducir el identificador a partir del nombre de la empresa ni mezclar un ID copiado de otro ejemplo. Las APIs tienen la molesta costumbre de distinguir entidades que visualmente parecen próximas.
Un nodo de edición de campos puede reducir la salida a identificadores y nombres de proyectos, conservando las advertencias necesarias para interpretar el resultado. Así el usuario puede revisar algo concreto sin recibir un volcado de propiedades que no necesita. La reducción debe hacerse después de entender la respuesta, para no eliminar información relevante como enlaces de continuación o señales de que el conjunto está incompleto.
Si hay paginación, terminar la primera petición no significa haber terminado el inventario. El workflow necesita seguir el mecanismo documentado o indicar expresamente que muestra una parte. También debe diferenciar una colección vacía de un fallo al interpretar el cuerpo. «No hay proyectos» y «no he podido leer la respuesta» son mensajes cómodamente breves, pero conviene que no signifiquen lo mismo cuando alguien tome decisiones a partir de ellos.
Este flujo tiene un resultado verificable: una lista de proyectos del hub seleccionado, obtenida con la identidad esperada y con su alcance explicado. Todavía no modifica incidencias, mueve documentos ni conecta un agente MCP. Mantenerlo pequeño facilita localizar un fallo; añadir tres sistemas más antes de comprobar estos datos no mejora el diagnóstico, aunque el lienzo de n8n quede bastante más impresionante.
El trabajo que queda detrás de un nodo rojo o una lista vacía
Una respuesta 401 orienta la revisión hacia la credencial, su vigencia y su recorrido de autorización. Un 403 hace revisar permisos, scopes y configuración de la integración sobre el recurso. No son diagnósticos universales que puedan resolverse únicamente leyendo el número: el cuerpo documentado de la respuesta y el contexto de la llamada siguen importando. La utilidad de distinguirlos está en dirigir la investigación, no en sustituirla por una tabla de supersticiones HTTP.
Si no aparecen hubs o proyectos, comprueba primero la cuenta conectada y el recurso seleccionado. La ausencia de resultados accesibles no demuestra que la organización carezca de proyectos. También puede haber un filtro, una configuración pendiente o una interpretación incorrecta de la respuesta. Reconectar veinte veces a la misma cuenta no cambia sus permisos, aunque sirve para llenar un historial de intentos con una consistencia admirable.
Los errores temporales y los límites de peticiones requieren otro tratamiento. Un reintento limitado puede tener sentido ante una interrupción, respetando las indicaciones del servicio; insistir con una autorización denegada no la vuelve válida. Antes de programar ejecuciones frecuentes conviene observar qué peticiones produce cada recorrido y evitar que varias ramas repitan la misma consulta sin necesidad. La herramienta visual facilita conectar pasos, pero no decide por ti qué carga es razonable.
Cuando una credencial es compartida por varios procesos, también importa cómo se coordinan sus renovaciones. Esa parte depende de la versión y el despliegue y debe verificarse antes de multiplicar ejecuciones. Los registros pueden conservar operación, recurso y tipo de error sin almacenar tokens o secretos. Quien atienda una incidencia necesita saber qué ha fallado y dónde; no necesita que el workflow publique sus credenciales como prueba de buena voluntad.
La primera prueba útil recorre el retorno OAuth, la cuenta autorizada y una lectura del recurso previsto; también debe permitir cancelar o denegar el acceso. Este artículo explica la configuración, sin presentar un workflow ejecutado como prueba. Si no puedes repetir esa lectura sin pegar otro token, detente ahí: añadir más nodos solo conseguirá que la parte que falla tenga mejor compañía.
Respuestas