Passthrough billing en Autodesk APS: quién paga el consumo y qué cambia
El visor gira, la demostración termina y alguien pregunta quién paga cuando entren veinte empresas. Un aguafiestas imprescindible: si esa pregunta estropea el producto, el producto era una subvención con interfaz. El passthrough billing de Autodesk APS permite atribuir consumo elegible al cliente, bajo unas condiciones concretas. Cambia quién asume ese consumo; no convierte las llamadas en gratuitas ni redacta por ti el precio de la aplicación. Vamos a separar esas cuentas antes de que las separe una factura.
Autodesk publicó el anuncio y la guía para ISV el 5 de octubre de 2026. Vamos a utilizar un SaaS BIM hipotético para ver qué cambia en el producto, el acceso y la incorporación de clientes. Aquí no se ha activado passthrough ni modificado la facturación de ninguna aplicación. Podemos leer una guía sin pulsar botones irreversibles; una capacidad infravalorada.
Tabla de contenidos
La factura de Autodesk y el precio de tu aplicación siguen caminos distintos
Imagina una aplicación que recibe modelos de distintas empresas, solicita su procesamiento en APS y permite consultarlos después. En el modelo financiado por el proveedor, ese consumo se carga a la capacidad de quien ofrece la aplicación. El proveedor decide cómo lo incorpora al precio del servicio: una cuota, un límite de uso u otra política comercial. Si un cliente concentra gran parte de la actividad, el coste puede crecer aunque la cuota que paga no lo haga. El edificio sigue girando igual de bien en el visor; la cuenta de resultados tiene menos paciencia.
Con passthrough, el consumo APS elegible puede atribuirse al cliente y utilizar su capacidad en las condiciones que correspondan. Ese cambio afecta a quién financia las llamadas participantes. No cobra automáticamente la licencia de tu producto, calcula tu margen ni convierte tu aplicación en distribuidora de créditos Autodesk. El cliente puede seguir pagando por el software y, por separado, asumir los costes APS mediante su relación con Autodesk. Son conceptos que conviene mostrar por separado cuando se explica la oferta.
La palabra «elegible» limita la promesa. No todas las operaciones tienen necesariamente el mismo tratamiento, y la guía distingue APIs incluidas en el modelo de pago de otras previstas para más adelante. Para analizar tu aplicación hace falta identificar qué servicios utiliza y comprobar su situación vigente. Decir «lo paga el cliente» sin saber qué llamadas hace el producto es una forma bastante ambiciosa de diseñar una tarifa a partir de un adjetivo.
Tampoco basta con que el comprador tenga una cuenta Autodesk. La guía exige una suscripción admisible con capacidad APS y completar la integración requerida. Si el consumo supera la capacidad incluida, hay que entender qué opción de consumo adicional resulta aplicable. No hace falta inventar precios para detectar la consecuencia: una venta puede requerir ahora la intervención de quien administra la cuenta y la capacidad del cliente, además de la persona que quiere utilizar la herramienta.
Para nuestro SaaS hipotético, ese paso puede ser razonable en una empresa que ya controla su consumo y quiere atribuirlo directamente. Puede resultar más difícil para quien espera contratar una herramienta y empezar sin ninguna gestión adicional. El ahorro de complejidad en la factura del proveedor puede convertirse en trabajo de incorporación y soporte. La decisión interesante consiste en valorar ambos lados, incluyendo a quienes tienen que completar el alta y a quienes atenderán las dudas cuando algo falle.
Mantener dos aplicaciones y entrar en transición son decisiones diferentes
La guía permite conservar el modelo actual, adoptar passthrough o ofrecer ambos mediante aplicaciones separadas. Conservar el modelo existente significa que el proveedor sigue financiando el consumo correspondiente. No hay una obligación general de migrar por el mero hecho de que se haya anunciado la función. Si el esquema actual encaja con el producto y con sus clientes, mantenerlo puede ser una decisión perfectamente razonable. La novedad tecnológica no ha adquirido, que sepamos, potestad para dirigir tu negocio.
En un modelo híbrido, mantienes un client ID para la aplicación financiada por el proveedor y otro para la aplicación preparada para passthrough. Puedes ofrecer opciones distintas o incorporar primero a un grupo de clientes. Esa separación permite preparar un recorrido sin cambiar el estado de financiación del client ID existente, aunque añade configuración y pruebas: el acceso, las URLs de retorno y el entorno asociado deben corresponder a la aplicación elegida. Dos identificadores no deberían terminar mezclados en un archivo de configuración con nombres vagamente esperanzadores.
La transición descrita para un mismo client ID funciona de otra manera. En ese estado pueden convivir clientes que ya completaron la integración y otros cuyo consumo sigue financiando el proveedor. El contexto de cada cliente determina el tratamiento de su actividad elegible. No es lo mismo que operar dos aplicaciones independientes: la convivencia forma parte del proceso de migración de ese client ID, con sus condiciones y su posterior cambio de estado.
La progresión indicada es ISV-funded, Transition y Customer-funded only. Avanzar entre esos estados es irreversible respecto al estado anterior. Cuando se alcanza el último, los clientes que no hayan completado la integración pierden acceso por ese client ID. Esta consecuencia debe explicarse literalmente: puede interrumpir el uso del producto. No es un ajuste de aspecto que puedas probar durante la reunión y deshacer al terminar.
Supongamos que tu cliente principal está preparado y un grupo pequeño todavía no. Pasar a Customer-funded only no debería decidirse mirando únicamente cuánto consumo representa el primero. También hay que identificar quién quedaría fuera, qué se le comunicó y qué alternativa tiene. El proveedor necesita una lista verificable de estados de incorporación, una persona autorizada para efectuar el cambio y un plan para atender las incidencias. «Los demás ya se irán enterando» tiene una presencia desproporcionada en migraciones que luego necesitan disculpas.
El contexto de consumo se elige en OAuth, no se adivina en cada llamada
Para atribuir el consumo, Autodesk necesita reconocer el contexto adecuado del cliente. Según la guía publicada en octubre, passthrough exige que la aplicación realice al menos una llamada con OAuth 3-legged y no admite aplicaciones puramente 2LO o SSA. Una integración de servidor que funcionaba solo con una cuenta de servicio no adopta el modelo añadiendo una etiqueta a sus peticiones. Necesita revisar la autenticación y la elegibilidad del tipo de aplicación. Puedes situar esa decisión en la comparación de 3LO y SSA.
El flujo incorpora prompt=select_usage_context cuando se trata de una aplicación elegible. Autodesk ofrece entonces el paso para seleccionar el contexto de uso antes de completar la autorización. Ese contexto permite resolver a qué capacidad se atribuye el consumo correspondiente. Tiene sentido que una persona con acceso a varias organizaciones deba decidir en cuál opera; tener varios proyectos a la vista no significa que todos deban utilizar la misma financiación.
Esta elección no sustituye los permisos sobre los datos. Poder seleccionar un contexto de consumo no debería interpretarse como acceso automático a un proyecto o a todos sus documentos. La autorización sobre el recurso sigue formando parte de la consulta. Son decisiones que pueden aparecer cerca en la experiencia de usuario y conviene explicar por separado: una responde desde dónde se financia el uso elegible, otra a qué información se permite acceder.
Después de autorizar, el código se intercambia por tokens mediante el recorrido OAuth previsto. La guía indica que no hace falta añadir un parámetro especial de passthrough en ese intercambio ni inventar un encabezado de facturación para cada llamada posterior. El contexto queda asociado a la autorización y se conserva durante una renovación normal. Esa continuidad evita volver a preguntar en cada acceso, aunque la aplicación sigue necesitando gestionar correctamente las caducidades y los fallos de renovación.
Si el usuario cancela, no existe un contexto válido o la aplicación no resulta elegible, el retorno puede incluir un error en lugar de un código. El backend debe reconocer ese caso y explicar la acción siguiente. No debería continuar silenciosamente con otra identidad ni suponer quién financia la operación. Es un punto donde la seguridad y el dinero coinciden: conviene que la respuesta sea precisa y que las decisiones las tome quien corresponde, no el bloque de código que tenía más ganas de terminar.
Qué se puede preparar en octubre de 2026 y qué no debe darse por abierto
El anuncio separa la preparación de las aplicaciones de la incorporación de los clientes. Su hoja de ruta sitúa ese segundo recorrido a principios de 2027; es una previsión, no una garantía de que cualquier cuenta pueda completar ya el alta. Antes de comprometer una migración hay que confirmar la disponibilidad para las cuentas implicadas. Un calendario comercial sirve para preparar trabajo, pero no sustituye a una función disponible cuando llega la factura.
Mientras tanto, se puede estudiar el modelo, identificar las APIs utilizadas y preparar los cambios de autenticación. También tiene sentido revisar cómo se explicará la nueva responsabilidad al cliente y qué información necesitará soporte para diagnosticar un bloqueo. Todo eso produce trabajo concreto y revisable sin avanzar el estado de una aplicación de producción. Preparar un flujo y activarlo para clientes son hitos distintos, por mucho que el calendario comercial prefiera comprimirlos en una sola casilla.
En el SaaS del ejemplo, una comprobación documental útil consistiría en dibujar qué ocurre con un cliente preparado y otro pendiente en cada estado. Después, cuando el recorrido esté disponible y se disponga de un entorno adecuado, habrá que comprobar autorizaciones correctas, cancelaciones, falta de contexto y acceso de quienes no completaron la incorporación. Este artículo explica ese diseño; no presenta una prueba real de alta ni resultados de consumo facturado.
Antes de elegir, separa el precio de tu producto, el consumo que puede asumir el cliente y el trabajo necesario para incorporarlo. Si solo has resuelto quién paga la API, aún falta decidir qué estás vendiendo. Lleva esa conversación a quien programe el acceso y a quien firme el presupuesto: conviene que se conozcan antes de explicárselo al primer cliente.
Respuestas