Passthrough billing: A guide for ISVs

Beginning October 14, 2026, independent software vendors (ISV) can start preparing their applications to implement Passthrough billing allowing API calls initiated by the application to attribute the API consumption directly to the customer.

Passthrough affects both your business model and your application architecture. This guide helps you evaluate whether passthrough is the right model for your application and, if you choose to use it, understand the technical options for enabling it.

This guide has two parts:

Business considerations — understand the available options and what passthrough means for your business and customers.
Technical enablement — choose an enablement path and understand the application and authentication changes required to implement passthrough.

Part 1: Business considerations

Understand the business implications

API consumption costs moves to the customer

For customers using passthrough, eligible API consumption is attributed to the customer's Autodesk Platform Services (APS) account rather than your own.
This changes who is responsible for API payment without changing your product ownership or customer relationship.
For applications with significant API consumption, API costs can scale with the customer generating that consumption, rather than becoming an increasing cost for you.

Customers need an APS subscription

Customers using a passthrough application must have an eligible Autodesk subscription with APS capacity and complete the required integration setup.
This introduces a customer prerequisite that does not currently exist when the ISV absorbs API consumption.
Consider how this affects your customer onboarding, packaging, pricing, sales, and support processes.

Customers have a separate Autodesk cost

Customers using passthrough continue to pay the ISV for the ISV's product or service if any, while their eligible APS API consumption is handled through their Autodesk subscription.
ISVs should be prepared to explain the following:
- The ISV's product or service and the Autodesk API capacity that the product consumes are separate costs and will be billed by the respective provider. Customers that consume more than the API capacity that is included in their subscription must have Flex/T Flex/Pay as you go available on their account to cover their API consumption. Flex is available on the Autodesk store or through partners authorized to sell Flex.

Moving a client ID to passthrough billing is a one-way decision

Whether you create a new passthrough application or convert an existing application, plan the change carefully.
For an existing client ID, movement from existing billing to passthrough state where the customer pays is forward-only. Once the application advances to the next funding state, it cannot return to the previous state.

Is passthrough billing a good fit?

Consider upcoming API pricing updates

The passthrough billing decision is particularly relevant as additional APS APIs move to a paid model.
If your application relies on APIs that are currently or will move to a paid model, consider whether you want those API costs to become part of your own cost structure or assumed by your customers.
Making this decision before APIs transition to a paid model gives you the time to make the required application and customer onboarding changes.
- The following APIs are currently part of our paid model:
  - Model Derivative API
  - Automation API
  - Reality capture API
  - Flow Graph Engine API
  - Manufacturing Data Model API
  - AEC Data Model API
- The following APIs will be added to our paid model later:
  - Data Management APIs
  - Forma APIs
  - We will continue to add more APIs to our paid model, always with ample notice to help you and your customers’ plan.

Consider your billing options

Passthrough billing is optional. You can continue with your existing usage model, move customers to passthrough, or operate both models in parallel.

Model	What it means	Best used when
Stay on your current model	Continue using your existing application. API usage continues to consume your API capacity, and you remain responsible for the associated API costs, just as you are today. For ISVs that are also contracted Autodesk Partners or Agents, self-quoting is prohibited.	You do not want to change customer onboarding, billing expectations, or application architecture.
Full passthrough	Create a new passthrough-enabled application or implement passthrough on your existing application and transition all users to that app. All API usage charges go directly to the customer. The customer must buy Flex separately (Pre-pay with Flex or Pay as you Go) if their consumption is higher than what is included in their subscription.	You want eligible API costs to shift to customers and your application can support the required passthrough setup.
Hybrid	Keep your existing application and create a separate passthrough-enabled application. Customers can remain on the existing application or onboard to the passthrough application.	You want to support both ISV-funded and customer-funded options in parallel using separate client IDs.

How the hybrid model works

The hybrid model uses two separate applications/client IDs with different funding models:

1. Existing application

Customer → Existing client ID → APS → ISV API capacity

2. Passthrough application

Customer → Passthrough client ID → APS → Customer APS capacity

This allows you to offer both models in parallel, giving you the option to transition select customers to the passthrough model without changing the funding model of your existing application.

Note: Hybrid billing using two applications is different from the Transition state described later in this guide. The Transition state allows both ISV-funded and customer-funded usage to coexist under a single existing client ID while customers are being onboarded to passthrough. The Transition state will be a temporary state and the exact timelines will be shared later.

Part 2: Technical enablement

Once you've decided to adopt passthrough, there are two ways to enable your application:

Create a new passthrough-enabled client ID.
Convert an eligible existing client ID to passthrough.

Both ultimately support the same customer-funded passthrough model, but the migration path is different.

1. Choose your enablement path

Option A: Create a new passthrough-enabled client ID

Create a new application in the APS Developer Portal, head to app setting and click “Start Transition.”.
This gives you a separate passthrough application that can be configured and tested before customers are onboarded.
This path is also useful when you want to keep your existing ISV-funded application running alongside a separate passthrough application.
Your applications would operate as:
- Existing client ID → ISV-funded
- New passthrough client ID → Customer-funded
Customers can then be onboarded to the appropriate application.

Option B: Convert an existing client ID

If your existing application is eligible(single page, web, mobile, desktop) with at least one 3LO call, you can enable passthrough on the existing client ID rather than creating a second application.
This avoids requiring customers to move to a different client ID and provides a transition period in which existing and passthrough customers can continue using the same application.
When you enable passthrough on the existing client ID, it enters the Transition state.

2. Understand the Transition state

The transition state is designed to let you migrate customers to passthrough without requiring every customer to make the change at the same time.

Important: Advancing between funding states is irreversible. Once an existing client ID enters transition, it cannot return to the ISV-funded state. Once it advances to customer-funded only, it cannot return to Transition.

During Transition, a single client ID can support both funding models:

Customer status	Who funds eligible API usage?	Access
Customer has completed the passthrough integration	Customer	Continues
Customer has not completed the integration	ISV	Continues

This means existing customers do not lose access when you first enable passthrough on the client ID.

As customers complete the required integration workflow once it’s available early next year, their eligible usage moves from ISV-funded to customer-funded. Customers who have not yet completed the integration continue to use the application with their API usage funded by the ISV.

This allows you to onboard customers at the pace appropriate for your application and customer base.

When you are ready, you explicitly advance the application to customer-funded only.

At that point:

The ISV no longer funds API usage on that client ID.
Customers who completed the integration continue to have access.
Customers who did not complete the integration lose access.

The progression is:

ISV-funded → Transition → Customer-funded only

Each advancement is an explicit ISV action.

3. Use a supported authentication model

Passthrough requires the application to make at least one API call using 3-legged OAuth (3LO). Pure 2LO and server-to-server applications are not supported for passthrough. This applies whether you create a new passthrough application or convert an existing client ID.

Why is 3LO required?

Passthrough needs to determine which customer's APS subscription should be responsible for API consumption.
A 3LO authorization provides Autodesk with a user identity. Autodesk uses that identity to determine the usage contexts available to the user and allows the user to select the appropriate context during authorization.
A pure 2LO flow provides application context but no user context. Without that user context, Autodesk cannot determine which customer's capacity should fund the usage.
Existing 2LO or server-to-server applications
A server-to-server client ID cannot be converted to passthrough.
If your application currently operates entirely through 2LO or SSA, adopting passthrough requires an authentication architecture change and an application type that supports 3LO . Autodesk Platform Services will be slowly transitioning all API endpoints to 3LO moving forward so we recommend you to start adopting 3LO in your application too.

4. Configure the passthrough application

Configure the application in the APS Developer Portal with the required:

Callback URLs
OAuth scopes
APS API access
Application collaborators
APS APIs used by your application

For passthrough, supported client types include:

Web
Single-page application
Mobile

Server-to-server applications are not supported.

If you're converting an existing application, its existing configuration remains associated with the same client ID. The significant change is its passthrough/funding state rather than a migration to a different application identity.

5. Update your 3LO authorization flow

The passthrough-specific change to your 3LO authorization flow is the addition of:

prompt=select_usage_context

For example:

import secrets

from urllib.parse import urlencode

CLIENT_ID = "your_client_id"

REDIRECT_URI = "https://yourapp.example.com/callback"

AUTH_BASE = "https://developer.api.autodesk.com/authentication/v2/authorize"

def build_authorize_url() -> str:

params = {

"response_type": "code",

"client_id": CLIENT_ID,

"redirect_uri": REDIRECT_URI,

"scope": "data:read data:write",

"state": secrets.token_urlsafe(16),

# Request usage-context selection for passthrough.

"prompt": "select_usage_context",

}

return f"{AUTH_BASE}?{urlencode(params)}"

When the parameter is present and the application is eligible for passthrough, Autodesk inserts a usage-context selection step into the authorization flow.

The user experience becomes:

Authenticate → Select usage context → Consent → Return to application

The selected usage context determines the customer context associated with the authorization.

6. Exchange the authorization code normally

After successful authorization, exchange the authorization code using the standard APS OAuth token exchange.

No additional passthrough parameter is required during token exchange.
import requests

TOKEN_URL = "https://developer.api.autodesk.com/authentication/v2/token"

def exchange_code(code: str) -> dict:

resp = requests.post(

TOKEN_URL,

data={

"grant_type": "authorization_code",

"code": code,

"redirect_uri": REDIRECT_URI,

"client_id": CLIENT_ID,

"client_secret": "your_client_secret",

# Use PKCE instead for applicable public clients.

)

resp.raise_for_status()

return resp.json()

The selected usage context is associated with the resulting authorization grant and access token. Your application does not need to inspect the usage context or explicitly send it with subsequent APS API requests. Post the, token refresh the selected usage context is bound to the authorization grant. When your application refreshes the access token, the same context is retained. You do not need to ask the user to select a usage context again during a normal token refresh.

7. Call APS APIs normally

After obtaining the access token, call APS APIs as you normally would with a 3LO access token.

tokens = exchange_code(code)

response = requests.get(

"https://developer.api.autodesk.com/some/aps/endpoint",

headers={

"Authorization": f"Bearer {tokens['access_token']}"

)

There is no additional passthrough billing header or API parameter to provide. For eligible usage, Autodesk uses the usage context associated with the access token to determine the appropriate customer context and funding source.

8. Handle unsuccessful usage-context selection

Usage-context selection is fail-closed. If Autodesk cannot establish a valid usage context, the authorization flow redirects back to your application's callback URL with an error instead of issuing an authorization code. Your callback should handle both successful authorization and errors.

from urllib.parse import parse_qs, urlparse

def handle_callback(callback_url: str):

q = parse_qs(urlparse(callback_url).query)

if "error" in q:

raise RuntimeError(

f"Authorization failed: {q['error'][0]}"

)

return q["code"][0]

Usage-context selection can fail when:

No valid usage context is available for the user.
The user cancels the selection or authorization process.
The application is not eligible for passthrough.
A usage context cannot otherwise be resolved.

Your application should treat these cases as authorization failures and provide the user with an appropriate next step.

9. Complete your migration

Your migration depends on the enablement path you selected.

If you created a new passthrough client ID

Onboard customers from your existing application to the new passthrough application.

If you're using a hybrid adoption model, you can continue operating both applications:

Existing application → ISV-funded customers
Passthrough application → Customer-funded customers

If you converted your existing client ID

Keep the application in Transition while customers complete the passthrough integration workflow.
During this period:
- Integrated customer → Customer-funded
- Not-yet-integrated customer → ISV-funded
Both populations continue using the same client ID.
When you are ready to stop funding customers who have not migrated, explicitly advance the client ID to customer-funded only.
This action is not triggered by a deadline or predetermined transition period. You decide when your customer migration has progressed far enough to make the cutover.
Remember that customers who have not completed the integration workflow will lose access after the application moves to customer-funded only.

Before going live

Before enabling passthrough billing, confirm that:

1. You’ve selected your billing model and client ID approach (new or eligible existing ID).

2. Your application meets passthrough requirements, including a supported application type and 3LO.

3. Your customers can meet APS subscription requirements.

4. Your client and APIs are configured, including callback URLs, scopes, API access, collaborators, and API declarations.

5. Your authorization flow is ready, including prompt=select_usage_context, unsuccessful selection handling, code exchange, token refresh, and API calls.

6. You understand that passthrough state changes are irreversible.

7. If converting an existing client ID, you have a plan to move from transition to customer-funded only, and customers understand the actions required.

Once these requirements are met, you’re ready to begin onboarding customers to passthrough!

Tags:

Announcements

Back to Community Blog