Forge → Autodesk Platform Services: the migration playbook

Someone just opened a four-year-old repo

Picture it: it is a Tuesday morning in early 2026. A mid-sized engineering consultancy just landed a new client who wants a web viewer built on Autodesk's cloud APIs. Someone on the team remembers that they built something similar back in 2021 — a Revit-to-viewer pipeline that pulled BIM 360 documents, fired a Model Derivative translation job, and embedded the old Forge Viewer in a React shell. They find the repo, dust it off, spin up a fresh Node environment, and the first npm install immediately spits a deprecation warning:

npm warn deprecated [email protected]: This package is no longer maintained.
Please use https://github.com/autodesk-platform-services/aps-sdk-node instead.

Then they open the Autodesk developer portal, find that forge.autodesk.com silently redirects to aps.autodesk.com, and discover that their bookmarked "Forge Authentication" docs now talk about something called "OAuth 2.0 v2" with credentials in the Authorization header rather than the request body. The POST /authentication/v1/authenticate call in their token-exchange helper is gone — or rather, it was gone as of May 22, 2024.

Is this a ground-up rewrite? Did the APIs fundamentally change? Do the Model Derivative endpoints even still exist?

The answers, in order, are: no, mostly no, and yes — under the same URL. But the exceptions matter enormously. The wrong assumption — that a rebrand means nothing changed, or conversely that everything changed — is how teams either ship broken auth silently in production or waste a sprint rewriting perfectly functional code.

This post is the map. We will walk through what Autodesk Platform Services (APS) actually is, trace the exact boundary between what stayed the same and what moved, and hand you a concrete migration playbook covering auth endpoint swaps, SDK package names, webhook event names, and the billing model evolution. By the end you will know precisely which lines of code need to change and which ones you can leave exactly as they are.

The audience is AEC developers who have hands on Autodesk API integrations — whether you are maintaining legacy Forge code, building new on APS, or making the decision about whether to migrate at all. We assume familiarity with REST APIs, OAuth 2.0 basics, and enough Node.js or Python to read code examples critically.

One important caveat upfront: Autodesk's documentation is a living target. Pricing, deprecation timelines, and SDK release states have all shifted during the research for this article. We cite the source and date for every factual claim. When in doubt, verify against aps.autodesk.com/blog and the official GitHub organization autodesk-platform-services before making decisions.

And just to anchor the scope of this piece: we are writing about the Autodesk developer platform — the API layer used to build custom integrations, viewers, and workflows on top of Autodesk's cloud infrastructure. We are not writing about Autodesk's end-user products, desktop applications, or the Revit/Civil 3D/Navisworks feature sets themselves. If you are a developer who builds tools on top of Autodesk products, this guide is for you. If you are an end user of those products, the rebrand has no direct impact on your workflow.

The rebrand in context

Autodesk University 2022

Autodesk has run its annual developer conference (Autodesk University, or AU) for decades. The November 2022 edition was where CEO Andrew Anagnost unveiled what Autodesk called "the Autodesk Platform" — a strategic framing of all their cloud and cloud-adjacent products as a unified infrastructure rather than a collection of siloed desktop tools with cloud add-ons.

The new platform had four named components:

• Fusion — design and manufacturing cloud (formerly Fusion 360 plus Fusion Manage)
• Forma — architecture, engineering, and construction cloud (formerly Spacemaker, absorbing Revit cloud collaboration)
• Flow — media and entertainment cloud (formerly Shotgrid and related)
• Platform Services — the common cloud infrastructure that powers all three of the above and is exposed to third-party developers

That fourth component is the one we care about. On November 28, 2022, Autodesk published the official announcement: Autodesk Forge was becoming Autodesk Platform Services.¹ The website redesign went live December 7, 2022, with the domain migrating from forge.autodesk.com to aps.autodesk.com. Legacy URLs were preserved via redirect so existing bookmarks and documentation links would not immediately break.

What motivated it

The name "Forge" had served Autodesk well as an evocative brand for a developer platform — it suggested building and creation. But it created a positioning problem. From the outside, Forge looked like a separate Autodesk product, with its own pricing, its own developer program, and its own community — somewhat disconnected from the flagship products like Revit, Civil 3D, and BIM 360.

The internal strategy was different. Forge was not a product alongside Revit — it was the infrastructure Revit's cloud capabilities ran on. ACC (Autodesk Construction Cloud) used the same Data Management layer. The Viewer embedded in Autodesk's own products was Forge Viewer. Design Automation (DA) was running Revit in the cloud on the same infrastructure third-party developers accessed.

The rebrand was intended to make that relationship explicit. "Platform Services" signals that this is foundational infrastructure, not a standalone SKU. In Autodesk's own words, the new name "reflects the importance of Forge as a key component of the Autodesk Platform, delivering value to customers across all industries."¹

There was also a market-positioning dimension. By 2022, Autodesk had been steadily building ACC as the consolidated construction data platform, absorbing BIM 360, PlanGrid, BuildingConnected, and others. Third-party integrators building on Forge were, whether they knew it or not, building on the same technical layer as ACC. Making that explicit through shared branding was meant to reduce confusion and signal long-term investment.

Ecosystem branding implications

For third-party developers, the rebrand rippled into several places:

Documentation and URLs. The developer portal moved. forge.autodesk.com/developer became aps.autodesk.com. The API reference docs reorganized under aps.autodesk.com/en/docs. All legacy forge.autodesk.com URLs redirect, but documentation links embedded in code comments, internal wikis, and third-party tutorials scattered across the internet remained pointed at the old domain and now silently forward to potentially reorganized content. Teams running link checks against documentation will see redirects rather than breaks, which can mask the fact that the underlying content has moved or changed.

GitHub organization. The old Autodesk-Forge GitHub organization (github.com/Autodesk-Forge) was not deleted but entered maintenance mode. Active development moved to github.com/autodesk-platform-services. Sample apps, SDK clients, and tutorial repositories that were maintained under the old org received deprecation notices in their READMEs. Some were archived. This is one of the clearest signals that the Forge era has a hard end date — the GitHub footprint tells the story unmistakably.

npm namespace. The old forge-apis npm package, published under the Autodesk-Forge GitHub org, was explicitly deprecated. The new official SDK is published under the @aps_sdk namespace on npm (note the underscore, not a slash — we will come back to why this matters). Developers who run npm audit or upgrade tooling that checks for deprecations will see warnings on any project still pulling in forge-apis.

Community and forum naming. The Autodesk developer forum (forums.autodesk.com/t5/autodesk-platform-services) was renamed. Older posts still use "Forge" throughout, and search results for "Forge API" continue to surface valid APS content — the search engines have not forgotten the old brand. This is generally helpful: searching "Forge Model Derivative" still returns relevant APS documentation. But it can also mislead — old forum answers from 2019 referencing authentication/v1 as the correct endpoint are still findable and still look authoritative.

Third-party tooling and tutorials. The ecosystem of third-party Forge tutorials, YouTube walkthroughs, and blog posts represents years of accumulated developer knowledge. Almost none of it has been updated for APS branding. This creates a dual-namespace situation that will persist for years: the official brand is APS, but the practitioner vocabulary includes "Forge," "Forge Viewer," "forge-apis," and so on. Understanding both names is a survival skill for any AEC developer working with Autodesk APIs.

The Flex token coincidence

One change that landed at exactly the same time as the APS rebrand was a billing model shift: Autodesk stopped selling Cloud Credits on November 7, 2022, and began transitioning to Flex tokens.² The timing was not coincidental — both changes were announced together at AU 2022 — but they are separate changes. The auth API changes came later; the SDK renaming was also phased. The risk of conflating all of these into "the APS migration" is that teams tackle them in the wrong order or mistake progress on one for progress on another.

We will treat each change separately in the sections that follow.

The developer community response

The initial reaction from the AEC developer community to the Forge → APS rebrand was, broadly, "fine, but why?" Many developers had invested years in Forge knowledge — in tutorials with "Forge" in the title, in code with FORGE_CLIENT_ID environment variable names, in team wikis documenting the "Forge Model Derivative API." The rebrand asked them to update none of their code but all of their vocabulary, which generated a mix of relief (nothing to migrate yet) and frustration (ongoing dual-naming confusion).

Forum posts from late 2022 and early 2023 reflect this: developers asking whether they needed to update their code (answer: not immediately), whether forge.autodesk.com links would keep working (answer: yes, via redirect), and whether the APS branding would eventually supersede all Forge references in the documentation (answer: yes, gradually, and not completely for years).

The dual-naming reality persists today. Searching for "Forge Viewer" returns APS Viewer documentation. Official APS tutorials reference Forge-era concepts without explanation. Third-party blog posts from 2020 are still the top search result for many Autodesk API questions, and they use Forge vocabulary throughout. Practitioners navigating this space need to maintain a mental mapping between the two brand names and be prepared to find the right answer regardless of which name it is filed under.

One practical consequence: when you search Stack Overflow or the Autodesk forums for a specific error or behavior, the correct answer may be from 2019, labeled "Forge," and still be 100% correct for your 2026 APS integration. The API surface is stable enough that old answers remain valid. But the auth examples in those old posts almost certainly use v1 endpoints, which are dead. Read old posts for architecture and API structure; verify auth code against the current APS documentation.

What technically did not change

This is the section that will save you the most time. A large fraction of working Forge code — potentially the majority of it — requires no changes at all for APS compatibility. Understanding why helps you trust that confidence rather than second-guessing it.

The base API host

The REST API base URL for virtually every Autodesk API is:

https://developer.api.autodesk.com

This has not changed. It did not change with the rebrand. Model Derivative calls, Data Management calls, OSS bucket operations, Design Automation v3 calls — they all hit the same host they always did. There is no aps-api.autodesk.com or api.aps.autodesk.com to migrate to. Old code that hardcodes https://developer.api.autodesk.com as the base URL is correct for 2026.

Model Derivative API

The Model Derivative API is the workhorse of most Forge/APS integrations. It translates uploaded design files (Revit, DWG, IFC, NWD, and many others) into formats consumable by the Viewer (SVF, SVF2) or extractable as metadata (JSON property databases). Its endpoint paths have not moved:

POST   https://developer.api.autodesk.com/modelderivative/v2/designdata/job
GET    https://developer.api.autodesk.com/modelderivative/v2/designdata/{urn}/manifest
GET    https://developer.api.autodesk.com/modelderivative/v2/designdata/{urn}/metadata
GET    https://developer.api.autodesk.com/modelderivative/v2/designdata/{urn}/properties

The job submission JSON format is also unchanged in its core structure. Here is a representative job submission payload that works identically under both Forge and APS branding:

{
  "input": {
    "urn": "dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6bXktYnVja2V0L3NhbXBsZS5ydnQ",
    "compressedUrn": false,
    "rootFilename": "sample.rvt"
  },
  "output": {
    "formats": [
      {
        "type": "svf2",
        "views": ["2d", "3d"]
      }
    ],
    "destination": {
      "region": "us"
    }
  }
}

Note that svf2 (the newer streaming format) is now Autodesk's recommended output type over svf. That is a best-practice recommendation, not a deprecation — svf still works. But if you are touching Model Derivative job submissions anyway, moving to svf2 gives better viewer performance for large models.

One additive change worth knowing: the Model Derivative API gained a region header requirement for European data center access. If your users' BIM 360 / ACC hubs are in the EU data center, you now need to pass region: EU in the request header and target the EU endpoint variants. This is not a breaking change for US-only deployments, but it catches teams building multi-region products off guard.

Data Management API

The Data Management (DM) API covers OSS (Object Storage Service) buckets plus the BIM 360 / ACC hub/project/folder/file tree. All the endpoint paths have remained stable:

GET  /oss/v2/buckets
POST /oss/v2/buckets
GET  /oss/v2/buckets/{bucketKey}/objects
PUT  /oss/v2/buckets/{bucketKey}/objects/{objectKey}
 
GET  /project/v1/hubs
GET  /project/v1/hubs/{hub_id}/projects
GET  /data/v1/projects/{project_id}/folders/{folder_id}/contents

The JSON:API-style response format (with data, included, links top-level keys) has not changed. The BIM 360 vs. ACC differentiation in hub IDs (b. prefix for BIM 360, a. prefix for ACC unified products) persists and predates the Forge → APS rename.

The Viewer SDK (formerly Forge Viewer)

The Autodesk Viewer — colloquially still called "LMV" (Large Model Viewer) by many practitioners and by Autodesk's own internal tooling — is loaded via a CDN script tag. Its loading pattern has not changed:

{/* Still works the same way under APS branding */}
<link
  rel="stylesheet"
  href="https://developer.api.autodesk.com/modelderivative/v2/viewers/7.*/style.css"
/>
<script src="https://developer.api.autodesk.com/modelderivative/v2/viewers/7.*/viewer3D.min.js"></script>

The JavaScript namespace is Autodesk.Viewing — unchanged. The global initialization call:

Autodesk.Viewing.Initializer(options, function () {
  const viewer = new Autodesk.Viewing.GuiViewer3D(container);
  viewer.start();
  Autodesk.Viewing.Document.load(urn, onDocumentLoadSuccess, onDocumentLoadFailure);
});

is identical between code written in 2020 and code written in 2026. The internal LMV version variable LMV_VIEWER_VERSION is still used in developer tools and telemetry. The Viewer underwent major version updates (v7 is current) independent of the APS rebrand, but those were capability and performance updates, not API-surface breaks — and they predate the rebrand.

Custom extensions written against the Forge Viewer's extension API (Autodesk.Viewing.Extension) continue to work without modification. Extension lifecycle hooks (load(), unload(), onToolbarCreated()) have not changed signatures.

OAuth scopes

OAuth scopes — the colon-delimited permission strings that define what a token can do — have not changed. data:read, data:write, data:create, bucket:read, bucket:create, viewables:read, account:read, account:write are all the same strings in APS as they were in Forge. Code that assembles scope arrays or validates returned scopes does not need modification.

Application client IDs and secrets

Your existing Forge application's client ID and client secret are valid in APS without regeneration. The developer portal at aps.autodesk.com (formerly forge.autodesk.com/myapps) shows the same apps with the same credentials. No credential rotation is required by the rebrand itself. (The auth endpoint changed, which we cover next — but the credentials themselves are unchanged.)

Design Automation v3

The Design Automation (DA) API at v3 (/da/us-east/v3/) has been stable. Activity and appbundle definitions created in the Forge era run on APS without changes. The deprecation to watch here is DA v2 (not v3) — and that was deprecated before the rebrand, tied to the API version rather than the brand.

Design Automation is one of the most powerful but also most operationally complex APIs in the APS catalog. It runs Autodesk desktop engines (Revit, AutoCAD, Civil 3D, Inventor) in the cloud, executing custom .addin / .bundle / .dll code against a model file and producing output artifacts. The complexity of setting up activities, appbundles, and work items means that teams who have a working DA v3 integration are rightly cautious about unnecessary changes. The good news: DA v3 is stable, and the migration from Forge to APS for a DA integration is 100% the auth swap plus the billing enrollment. The activity definitions, engine strings (Autodesk.Revit+2024), bundle deployment, and work item monitoring — none of that moves.

The DA rate limit documentation (aps.autodesk.com/en/docs/design-automation/v3/developers_guide/rate-limits) is worth reading even if you are not migrating, because the rate limits are more complex than the simpler data APIs: they operate per-app, per-activity, and globally, and can be a source of mysterious failures under load.

OSS (Object Storage Service)

The OSS layer — the bucket and object storage that underpins most file upload/download flows — has not changed. Buckets created during the Forge era persist and are accessible under APS without migration. The endpoints:

POST   /oss/v2/buckets                                        — create bucket
GET    /oss/v2/buckets/{bucketKey}/objects/{objectKey}        — get object metadata
PUT    /oss/v2/buckets/{bucketKey}/objects/{objectKey}        — simple upload
POST   /oss/v2/buckets/{bucketKey}/objects/{objectKey}/resumable — resumable upload initiation

The only OSS change worth noting is that Autodesk added a signed URL flow (S3-compatible) for large file transfers, which is now the recommended approach for files over a few MB. This is an addition, not a breaking change — the old direct PUT still works, but the signed URL flow is faster and more reliable for large BIM files.

Scopes and token introspection

Token introspection (checking whether a token is valid and what scopes it carries) used to live at GET /authentication/v1/introspecttoken. In v2, this moves to a different endpoint, but the introspection use case — validating a token received from a third party — is handled differently in the v2 ecosystem. If your code calls introspect, that is a migration target; check the v2 auth documentation for the current endpoint. For most integrations that only use tokens they themselves issued, introspection is not in the code path.

Webhook infrastructure

The core webhook system — the ability to subscribe to events like dm.version.added, dm.folder.added, md.translation.complete — has not changed architecturally. Your webhook payload handler code does not need modification. The subscription management endpoints remain at:

POST   /webhooks/v1/systems/{system}/events/{event}/hooks
GET    /webhooks/v1/systems/{system}/events/{event}/hooks
DELETE /webhooks/v1/systems/{system}/events/{event}/hooks/{hook_id}

We will discuss webhook event naming nuances in the "what changed" section, but the infrastructure itself and your handler code are stable.

What technically did change

This section covers the four areas that require deliberate migration work: authentication endpoints, SDK package naming, pricing/billing mechanics, and a few webhook nuances. We will also embed the migration playbook as subsections here, since the best place to learn what to do is immediately adjacent to understanding why.

4.1 Authentication: the v1 → v2 endpoint migration

This is the sharpest edge in the entire Forge → APS transition. It is a hard breaking change with a hard deadline that has already passed.

The deadline: Authentication v1 was shut off on May 22, 2024.³ If you have any integration still calling authentication/v1/* endpoints after that date, it is returning errors. There is no grace period remaining.

The deprecation timeline was extended twice: originally set for a date in late 2023, then extended to April 30, 2024, then to the final date of May 22, 2024.⁴ Each extension was driven by the volume of integrations still on v1.

The endpoint changes

The most critical structural change is where credentials go. In v1, the client ID and client secret were sent in the POST body as form fields. In v2, they must be combined, Base64-encoded, and placed in the Authorization header as Basic <base64(client_id:client_secret)>. Any code that builds the authentication request body will need this changed.

Code: Forge v1 two-legged auth (deprecated)

// forge-apis era — DO NOT USE, v1 is dead as of May 22 2024
const axios = require("axios");
 
async function getForgeTokenV1(clientId, clientSecret) {
  const response = await axios.post(
    "https://developer.api.autodesk.com/authentication/v1/authenticate",
    new URLSearchParams({
      client_id: clientId,
      client_secret: clientSecret,
      grant_type: "client_credentials",
      scope: "data:read viewables:read",
    }),
    {
      headers: { "Content-Type": "application/x-www-form-urlencoded" },
    }
  );
  return response.data.access_token;
}

Code: APS v2 two-legged auth (current)

// APS v2 — credentials move to the Authorization header
const axios = require("axios");
 
async function getApsTokenV2(clientId, clientSecret) {
  const credentials = Buffer.from(`${clientId}:${clientSecret}`).toString("base64");
 
  const response = await axios.post(
    "https://developer.api.autodesk.com/authentication/v2/token",
    new URLSearchParams({
      grant_type: "client_credentials",
      scope: "data:read viewables:read",
    }),
    {
      headers: {
        "Content-Type": "application/x-www-form-urlencoded",
        Authorization: `Basic ${credentials}`, // "Basic" — capital B required
      },
    }
  );
  return response.data.access_token;
}

PKCE for three-legged flows (new in v2)

One significant capability addition in v2 is PKCE (Proof Key for Code Exchange) support. PKCE is the current best-practice OAuth 2.0 extension for public clients — desktop applications and single-page applications where a client secret cannot be safely stored.

Before PKCE, building a desktop or SPA integration with Forge required awkward workarounds: either exposing the client secret (a security risk) or routing through a backend server solely to hold credentials. V2 natively supports the PKCE flow, which eliminates both problems.

The PKCE flow works as follows:

1. The client generates a random code_verifier (a 43–128 character cryptographically random string).
2. The client computes code_challenge = BASE64URL(SHA256(code_verifier)).
3. The authorization redirect includes code_challenge and code_challenge_method=S256.
4. After the user authorizes, the code exchange POST includes the original code_verifier instead of (or alongside) the client secret.
5. The auth server verifies that SHA256(code_verifier) matches the stored code_challenge before issuing tokens.

// APS v2 — three-legged auth with PKCE (for SPAs and desktop apps)
const crypto = require("crypto");
 
function generatePKCE() {
  const codeVerifier = crypto.randomBytes(64).toString("base64url");
  const codeChallenge = crypto
    .createHash("sha256")
    .update(codeVerifier)
    .digest("base64url");
  return { codeVerifier, codeChallenge };
}
 
function buildAuthorizationUrl(clientId, redirectUri, scope, codeChallenge, state) {
  const params = new URLSearchParams({
    response_type: "code",
    client_id: clientId,
    redirect_uri: redirectUri,
    scope,
    state,
    code_challenge: codeChallenge,
    code_challenge_method: "S256",
  });
  return `https://developer.api.autodesk.com/authentication/v2/authorize?${params}`;
}
 
async function exchangeCodeForToken(clientId, redirectUri, code, codeVerifier) {
  // For PKCE public clients — no client secret in the header
  const response = await axios.post(
    "https://developer.api.autodesk.com/authentication/v2/token",
    new URLSearchParams({
      grant_type: "authorization_code",
      code,
      redirect_uri: redirectUri,
      client_id: clientId,
      code_verifier: codeVerifier, // verifier replaces secret for PKCE
    }),
    {
      headers: { "Content-Type": "application/x-www-form-urlencoded" },
    }
  );
  return response.data;
}

Token expiry and caching

One behavioral difference that catches teams when they move from the forge-apis library to raw HTTP calls: the old library had built-in token caching and automatic refresh via the authenticate() method. You called authenticate() at any point and it would return a valid token, refreshing transparently if needed.

The new @aps_sdk/authentication client is more stateless — it issues a token when you call getTwoLeggedToken() but does not cache or auto-refresh. If you call it on every API request, you will hit the auth endpoint rate limits quickly. The correct pattern is to cache the token and track its expiry:

// Token caching helper — use with any APS auth approach
class TokenCache {
  constructor() {
    this._token = null;
    this._expiresAt = null;
  }
 
  async getToken(fetchFn) {
    const bufferSeconds = 60; // refresh 60 seconds before actual expiry
    if (this._token && Date.now() < this._expiresAt - bufferSeconds * 1000) {
      return this._token;
    }
    const response = await fetchFn();
    this._token = response.access_token;
    this._expiresAt = Date.now() + response.expires_in * 1000;
    return this._token;
  }
}
 
const cache = new TokenCache();
 
// Usage
const token = await cache.getToken(() =>
  getApsTokenV2(process.env.APS_CLIENT_ID, process.env.APS_CLIENT_SECRET)
);

Access tokens expire in 3,600 seconds (1 hour) from issuance. The expires_in field in the token response is the authoritative value. Always use it rather than hardcoding 3600, in case Autodesk changes the expiry duration in the future.

Migration playbook: authentication

Step 1: Audit all auth calls

Search your codebase for any of these strings:

authentication/v1/authenticate
authentication/v1/gettoken
authentication/v1/refreshtoken
authentication/v1/authorize
authentication/v1/introspecttoken

Any hit is a migration target. Do not rely solely on grep — the endpoint URL may be assembled at runtime from a base URL constant. Also search for grant_type and the forge-apis package import.

Step 2: Centralize your token helper

If auth logic is scattered across multiple files, consolidate it into a single module (auth.js, token_manager.py, or similar) before migrating. This ensures you change the endpoint exactly once rather than hunting across callsites.

Step 3: Swap credentials from body to header

For every two-legged token call: remove client_id and client_secret from the form body, construct the Base64 Basic credential string, and add the Authorization: Basic header.

Step 4: Update 3LO callback handlers

For three-legged flows: the token exchange endpoint changes from /gettoken to /token. The credential placement rule is the same — move from body to header. If you are adding PKCE support (recommended for new builds), add the PKCE generation and verifier-passing logic at the same time.

Step 5: Verify the token response shape

The v2 token response is similar to v1 but check that your code handles the token_type, expires_in, and refresh_token fields correctly. V2 response tokens are structurally compatible but validate your token parsing logic.

Step 6: Test with a scope-restricted token first

Do not test the migrated auth by hitting a destructive endpoint. Issue a token with only data:read scope and call a read-only endpoint (e.g., GET /oss/v2/buckets). Confirm you get a 200 before opening up broader scopes.

Step 7: Remove old portal app keys from .env archives

This is not a code change but a security hygiene step: any .env files or CI secret stores that contain FORGE_CLIENT_ID / FORGE_CLIENT_SECRET variable names should be renamed to APS_CLIENT_ID / APS_CLIENT_SECRET (or whatever naming convention your project uses). More importantly, rotate credentials if they have been stored in version control or shared via insecure channels. The rebrand is a good forcing function for a credential audit.

4.2 SDK package naming

Node.js: forge-apis → @aps_sdk/*

The old official Node.js SDK was forge-apis, published by Autodesk on npm. As of late 2023/early 2024, it entered maintenance mode with no new features being added and an explicit deprecation warning shown at install time. The latest published version is 0.9.12.

The new official SDK, announced at the end of 2023, is split into modular packages under the @aps_sdk scope (note: underscore, not a slash — this is an npm scoped package using an underscore because npm scopes use the @org/ syntax and Autodesk chose @aps_sdk as the organization name to avoid a slash-heavy namespace):

# Install the SDK manager (required) plus the APIs you need
npm install @aps_sdk/autodesk-sdkmanager
npm install @aps_sdk/authentication
npm install @aps_sdk/data-management
npm install @aps_sdk/model-derivative
npm install @aps_sdk/oss

Each package is versioned independently. You only pull in the APIs you use, which keeps your bundle lean for browser-deployed code and keeps dependency update noise low for server-side projects.

The SDK manager (@aps_sdk/autodesk-sdkmanager) provides shared configuration — base URL, retry logic, user agent — so individual API clients stay focused on their domain.

Usage comparison:

// Old way — forge-apis (deprecated)
const ForgeSDK = require("forge-apis");
const oAuth2TwoLegged = new ForgeSDK.AuthClientTwoLegged(
  CLIENT_ID,
  CLIENT_SECRET,
  ["data:read"],
  true
);
 
// New way — @aps_sdk/authentication
const { SdkManager, SdkManagerBuilder } = require("@aps_sdk/autodesk-sdkmanager");
const { AuthenticationClient, Scopes } = require("@aps_sdk/authentication");
 
const sdkManager = SdkManagerBuilder.create().build();
const authClient = new AuthenticationClient(sdkManager);
 
const tokenResponse = await authClient.getTwoLeggedToken(
  CLIENT_ID,
  CLIENT_SECRET,
  [Scopes.DataRead]
);
const accessToken = tokenResponse.access_token;

One structural difference: the old forge-apis SDK managed token refresh internally via the authenticate() method on a long-lived client. The new @aps_sdk/authentication client is more explicit — you call getTwoLeggedToken() when you need a token and manage refresh timing yourself (or use a wrapper). This is a more standard pattern and easier to test, but it is a behavioral difference that can cause subtle token-expiry bugs if you migrate the import without reading the new API contract.

Python: the fragmented landscape

The Python SDK situation is more complicated than Node.js. There was a forge-sdk Python package (and older community packages), but Autodesk never had a single authoritative Python SDK during the Forge era to the same degree as Node.js.

As of 2024–2025, the official Python path from Autodesk involves code samples using direct requests calls against the APS REST API, plus an experimental Kiota-generated SDK in the autodesk-platform-services/aps-kiota-python-sample repo. Third-party community packages exist on PyPI — py-aps, aps-toolkit, aps-automation-sdk — each with different scope and maintenance posture.

If your project uses forge-sdk on Python, the migration path is:

1. Identify which APIs you use (most likely Data Management, Model Derivative, or Design Automation).
2. Replace with direct requests or httpx calls against the v2-compatible APS endpoints, using the auth helpers described above.
3. Evaluate whether a community PyPI package (py-aps, aps-toolkit) covers your use case and is actively maintained enough to take a dependency on.

For Python teams building greenfield, we recommend direct REST calls with a thin auth helper rather than a third-party SDK — the API surface is small enough that the maintenance burden of a dependency outweighs the convenience.

.NET: Autodesk.Forge → autodesk-platform-services/aps-sdk-net

The .NET ecosystem has an official replacement SDK at github.com/autodesk-platform-services/aps-sdk-net. The old NuGet package Autodesk.Forge is in the same maintenance mode as forge-apis on npm. The new packages follow an Autodesk.SDKManager + Autodesk.Authentication + Autodesk.ModelDerivative etc. pattern analogous to the Node.js naming.

4.3 Billing and pricing model evolution

The billing model has gone through three distinct phases across the Forge-to-APS lifecycle, and it matters for both operational cost planning and for understanding how API usage is tracked.

Phase 1: Forge Cloud Credits (pre-November 2022)

The original Forge billing unit was the Cloud Credit. Cloud Credits cost $1 USD each (later raised to $3 USD from March 29, 2022) and were consumed by premium API operations:

• Model Derivative: 0.5 credits per complex translation job, 0.1 per simple job
• Design Automation: 2 credits per processing hour
• Reality Capture: 1 credit per 50 photos (later per gigapixel)

Annual subscriptions bundled 100 Cloud Credits. Additional credits were purchasable through Autodesk's eStore and partners. If the credit balance hit zero, the account entered a grace period.

Phase 2: Flex Tokens (November 2022 — December 2025)

As part of the APS rebrand, Autodesk stopped selling Cloud Credits and moved to Flex tokens. The key details:

• A Flex token is operationally identical to a Cloud Credit and costs the same
• The transition from Cloud Credits was framed as a currency rename rather than a price change
• Annual subscriptions were deprecated in favor of a pay-as-you-go model: any account with a positive Flex token balance has "Full Access"
• Tokens are purchased with a one-year expiry
• Enterprise volume discounts start at 5,000+ tokens
• Flex tokens launched in 20+ countries; geographies without Flex availability continued on Cloud Credits under old terms

The important shift here was the subscription model. Under Forge, the annual subscription gave you 100 credits plus platform access regardless of usage. Under APS Flex, the annual subscription was gone — instead you maintained access by keeping a positive token balance. This is a meaningful change for organizations that ran Forge integrations with low-volume usage: they went from predictable $300/year subscription costs to a requirement to actively manage token balances.

Phase 3: Tiered free + pay-as-you-go (December 8, 2025)

In late 2025, Autodesk announced another significant pricing evolution.⁵ The model moved from Flex-tokens-only to a two-tier structure:

• Free Tier: Monthly usage caps on four rated APIs (Model Derivative, Automation/Design Automation, Flow Graph Engine, Reality Capture). Suitable for experimentation and low-volume POCs. Exceeding the cap suspends usage until the following month or upgrade.
• Paid Tier (option A — Flex prepay): Purchase Flex tokens in advance (minimum 100, expiring after one year). Budget-predictable, suitable for production workloads with forecastable volume.
• Paid Tier (option B — Pay as You Go): Monthly billing based on actual consumption. No upfront commitment. Available in US, Canada, Australia, New Zealand, Japan, EU, UK, Switzerland at launch.

All APS APIs not in the four rated categories (most Data Management endpoints, Webhooks, the 3D Viewer CDN, and ACC product APIs) remain non-rated and effectively free.

An important operational requirement from this phase: existing users had to enroll in the new Free or Paid offering by February 18, 2026 and migrate their applications to developer hubs. Accounts that did not enroll by that deadline risked API access suspension. If you are reading this and your organization has not enrolled, that is the first thing to check before any other migration work.

Understanding the Flex token consumption model

One nuance that Forge-era developers often miss: Flex tokens are consumed by the job, not by processing time (for Model Derivative). Design Automation, by contrast, is billed per processing hour. This means:

• A Model Derivative job that translates a 500 MB Revit file and a 50 MB Revit file consume the same 0.5 tokens (both are "complex" if they are Revit files).
• A Design Automation job that runs for 2 hours consumes 4 tokens (2 hours × 2 tokens/hour).
• Submitting a job that fails (translation error) still consumes tokens, because the processing infrastructure was engaged.

For teams running high-volume pipelines, the per-job billing model means you can forecast costs from job count rather than wall-clock time. A pipeline that translates 1,000 Revit files per month costs 500 tokens in Model Derivative charges. At the current Flex token rate, this is a predictable, budgetable cost. The Design Automation cost is less predictable because it depends on model complexity and the efficiency of your DA activity code — an inefficient activity that takes 3 hours to complete what an optimized version could do in 45 minutes represents 4× the token cost for identical functional output.

Migration playbook: billing

Step 1: Identify which APIs you use that are rated

Rated APIs: Model Derivative, Design Automation (Automation API), Flow Graph Engine, Reality Capture. If you only use Data Management, the Viewer CDN, or Webhooks, you are on non-rated APIs and incur no token charges.

Step 2: Enroll in the new pricing tier

Log into the developer portal (aps.autodesk.com) and complete the new pricing enrollment. Choose Free Tier if your volume is low and you can tolerate monthly cap suspension, or Paid Tier if you have production SLA requirements.

Step 3: Migrate apps to developer hubs

The new billing model requires applications to be registered under developer hubs. This is an administrative step, not a code change, but it is required for continued API access.

Step 4: Update cost monitoring

If you have cost alerts or dashboards tied to Cloud Credit consumption, update them for the new Flex token or pay-as-you-go reporting format. The API for querying token consumption has not fundamentally changed but the units and thresholds will differ.

Step 5: Audit the IFC pricing change

IFC file translation was reclassified as a "Complex job" (0.5 tokens) from "Simple job" (0.1 tokens) in March 2022, before the APS rebrand. If you are running heavy IFC pipelines, this is a 5x per-job cost increase that may have already materialized in your token burn rate without a code change trigger.

4.4 Webhook event names and nuances

The webhook system's architecture is stable (as noted in section 3), but there are naming details worth auditing.

Event name format

APS webhook event names use a {system}.{event} dot-notation format. The system values are things like dm (Data Management), md (Model Derivative), adsk.c4r (Collaboration for Revit). These have not changed with the rebrand.

A representative set of events you may have subscriptions for:

dm.version.added          — a new version of a file was added
dm.version.modified       — a file version was modified
dm.folder.added           — a folder was created
dm.folder.modified        — a folder was modified
md.translation.complete   — a Model Derivative translation job finished
md.extraction.complete    — a metadata extraction completed
adsk.c4r.collaboration.pushed — Revit cloud model was synced

These event strings have not changed in name as a result of the APS rebrand. However:

• Check your subscription endpoint. Webhook subscriptions include a callbackUrl that must be HTTPS and publicly reachable. If your dev/staging server URL has changed during the intervening years, subscriptions pointing to old callback URLs are silently failing to deliver.
• Verify hook createdBy references. If your webhook subscription management code filters or audits hooks by the createdBy field, those references may use old client app IDs. The client ID itself has not changed, but if you rotated credentials, new subscriptions would show a different createdBy.
• The BIM 360 Issues v1 API deprecation. BIM 360-specific webhook events tied to the Issues v1 API (not the ACC unified Issues API) had a deprecation deadline in 2023. This is a product-level deprecation, not an APS-level one, but it affects teams that subscribed to issue lifecycle events.

Webhook subscription code (current)

// Subscribe to a webhook — endpoint and structure unchanged from Forge era
const axios = require("axios");
 
async function subscribeToWebhook(accessToken, callbackUrl) {
  const response = await axios.post(
    "https://developer.api.autodesk.com/webhooks/v1/systems/dm/events/dm.version.added/hooks",
    {
      callbackUrl,
      scope: {
        folder: "urn:adsk.wiprod:fs.folder:co.some-folder-urn",
      },
      hookAttribute: {
        projectId: "your-project-id",
      },
    },
    {
      headers: {
        Authorization: `Bearer ${accessToken}`,
        "Content-Type": "application/json",
      },
    }
  );
  return response.data;
}

The only thing to change here relative to pre-APS code is that accessToken must be obtained from the v2 auth endpoint. The webhook call itself is unchanged.

Migration playbook: webhooks

Step 1: List all active webhook subscriptions

curl -X GET \
  "https://developer.api.autodesk.com/webhooks/v1/hooks" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

This returns all hooks across all systems. Export the list and review the callbackUrl and createdAt for each.

Step 2: Test each callback URL

For each callbackUrl in your subscription list, verify the endpoint is reachable, returns an appropriate response, and is still connected to the correct handler logic. Stale subscriptions pointing to decommissioned callback servers consume delivery attempts and can generate noise in Autodesk's backend.

Step 3: Delete and recreate stale hooks

There is no in-place edit for a webhook's callbackUrl. Delete stale subscriptions with DELETE /webhooks/v1/systems/{system}/events/{event}/hooks/{hook_id} and recreate them with the correct endpoint.

Step 4: Validate payload handling

Send a test payload to your webhook handler (or trigger a test event). Confirm your handler correctly parses the resourceUrn, hook, and payload fields and routes to the right business logic.

4.5 Rate limits: what changed and what you need to know

Autodesk does not publish a single rate limit table, but the operational picture is:

• 429 responses are handled the same way in APS as in Forge: the response includes a Retry-After header indicating seconds to wait before retrying.
• Rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) are returned on most API responses. If your Forge-era code did not read these headers, APS is a good time to add exponential backoff logic.
• Design Automation has explicit rate limit documentation per app and per activity. If you run high-volume DA workloads, consult aps.autodesk.com/en/docs/design-automation/v3/developers_guide/rate-limits for current limits.
• The v2 auth endpoint itself is subject to rate limiting; token exchange calls should be cached (do not re-request tokens on every API call — cache them until near expiry).

Anti-patterns

These are the failure modes we see most often when teams migrate Forge integrations to APS, or assume they do not need to migrate.

Anti-pattern 1: "We haven't had any complaints, so it must still work"

The most dangerous assumption: that because your integration was not broken by an alert or user report, it is operating correctly on APS. The auth v1 shutdown on May 22, 2024 would have produced immediate 401 Unauthorized errors — visible in server logs, invisible if no one is monitoring those logs. Teams running scheduled batch processes (overnight Model Derivative jobs, nightly BIM data extracts) may have had days or weeks of silent failures before anyone noticed.

Before declaring any Forge-era integration "APS compatible," actively verify it by inspecting HTTP traffic with a tool like Charles Proxy, Wireshark, or your cloud provider's API gateway logs. Look at the actual endpoint URLs being called. Do not infer from lack of complaints.

Anti-pattern 2: Hardcoding the /authentication/v1/ path string anywhere besides the auth module

Some codebases encode the full endpoint URL as a constant in every file that needs a token. When you find the auth bug and fix it in one place, the other instances remain broken. The pattern to avoid:

// BAD — endpoint URL scattered across files
// utils/modelDerivative.js
const token = await fetch("https://developer.api.autodesk.com/authentication/v1/authenticate", ...);
 
// services/bucketService.js
const token = await fetch("https://developer.api.autodesk.com/authentication/v1/authenticate", ...);

The fix is consolidation before migration. If you have not already centralized auth, do it as the first step of migration — not as a follow-up refactor.

Anti-pattern 3: Ignoring the Retry-After header

Forge-era code that handled rate limits by catching 429 errors and sleeping for a fixed interval (say, 5 seconds) may work fine under low load but will behave unpredictably under high load where the actual required wait is longer or shorter. The APS APIs communicate the required wait via the Retry-After header — use it:

async function apiCallWithRetry(fn, maxRetries = 3) {
  let attempt = 0;
  while (attempt < maxRetries) {
    try {
      return await fn();
    } catch (err) {
      if (err.response?.status === 429) {
        const retryAfter = parseInt(err.response.headers["retry-after"] ?? "5", 10);
        await new Promise((resolve) => setTimeout(resolve, retryAfter * 1000));
        attempt++;
      } else {
        throw err;
      }
    }
  }
  throw new Error(`Max retries (${maxRetries}) exceeded`);
}

Anti-pattern 4: Leaving client secrets in the old Forge developer portal

When developers created Forge apps in the pre-rebrand portal, some teams stored credentials in .env files committed to private repos, in plaintext CI/CD secret stores, or in internal wikis. The rebrand and portal migration is an opportunity for a credential hygiene audit. Regenerate any client secrets that have been accessible beyond the immediate dev team, and verify that old app registrations in the pre-APS portal are either migrated or explicitly deactivated.

The developer hub migration (required by February 2026) is also a forcing function here: apps that were not migrated to developer hubs may retain credentials in an ambiguous state. Clarify which app registrations are active, which are deprecated, and ensure only production secrets are available in production environments.

Anti-pattern 5: Assuming forge-apis minor version updates brought you to APS compatibility

Some teams updated forge-apis from an older minor version to 0.9.x and assumed they were now "APS compatible." They are not. The forge-apis package continued calling v1 auth endpoints internally regardless of version. The version updates fixed bugs and added API surface, but did not migrate the package to v2 auth. This is the reason the package required a full replacement rather than a version bump.

Run a dependency audit:

# Find forge-apis in your dependency tree (including transitive deps)
npm ls forge-apis
# or in a pnpm project
pnpm why forge-apis

If forge-apis appears — whether as a direct dependency or a transitive one — it is a migration target.

Anti-pattern 6: Rebuilding entirely from scratch

The opposite failure mode: a team reads "Forge is dead, APS is the new thing" and decides to rewrite their integration from scratch rather than migrating. This is usually unnecessary and expensive. As documented in section 3, the overwhelming majority of working Forge code — Viewer integration, Model Derivative calls, Data Management calls, webhook handlers — runs unchanged on APS. The targeted changes (auth endpoint, SDK package) are surgical. Treat this as a targeted migration, not a rewrite.

Anti-pattern 7: Not reading the auth migration guide because "OAuth is OAuth"

OAuth 2.0 is indeed a standard, and the v2 APS auth endpoint is more standards-compliant than v1 (which put credentials in the body rather than the header, contrary to RFC 6749 Section 2.3.1). But "OAuth is OAuth" can lead developers to miss the specific behavioral differences: the credential placement change, the PKCE availability, the new /revoke and /logout endpoints. Read the official migration guide at aps.autodesk.com/blog/migration-guide-oauth2-v1-v2 in full before writing migration code.

Anti-pattern 8: Not testing in a staging environment with production-like data

Model Derivative jobs — particularly Revit translations — behave differently depending on the specific Revit version, file complexity, linked model structure, and family library usage. A migration that works perfectly on a simple test model may fail on a production Revit file with 47 linked models and custom families. Always test your migrated integration against a sample of real production files before go-live.

Similarly, the v2 token response can have subtle differences in claim presence depending on the grant type and scopes requested. Test 2-legged and 3-legged flows separately, and test all the scopes your application actually uses — not just the primary ones you remember.

Anti-pattern 9: Using environment variable names that mix Forge and APS

Teams mid-migration often end up with a mix of FORGE_CLIENT_ID (old) and APS_CLIENT_ID (new) environment variables in the same codebase. If the code references both names because the migration was done incrementally, you can end up with auth that works locally (where both variables happen to be set) but fails in CI (where only one or the other is set). Standardize on one naming convention and purge the other before deploying.

Anti-pattern 10: Forgetting that token lifetime is 1 hour

Access tokens from the APS auth endpoint have a 1-hour (3600 second) expiry. This has not changed. But teams migrating from a library (forge-apis) that handled token refresh automatically may, when switching to raw HTTP calls or the new SDK, inadvertently stop refreshing tokens. A long-running process that fetches a token at startup and reuses it for hours will see failures. Implement token expiry tracking based on the expires_in field in the token response and refresh proactively before the expiry — not reactively after a 401.

Case studies

The following are composite scenarios constructed from common migration patterns observed in the AEC developer community. Names and specifics are illustrative rather than references to specific organizations.

Case study 1: The structural engineering firm with a 2021 clash pipeline

A mid-sized structural engineering firm built a Node.js pipeline in 2021. It ingested Revit models from a BIM 360 project, submitted Model Derivative jobs to produce SVF output, then extracted the property database to run automated clash detection logic. The pipeline ran nightly as a cron job on an EC2 instance.

What they found in 2024: The pipeline started failing silently in May 2024 when auth v1 was shut off. The EC2 instance had no alerting configured for HTTP 401 responses — it treated all API errors as transient and retried indefinitely. The cron job continued running and consuming CPU, but produced no output. The team discovered the failure six weeks later when a structural review meeting referenced data that had not updated since May.

The migration: The fix was surgical. They had a single getToken.js module (fortunately already centralized). The changes were:

1. Updated the endpoint from /authentication/v1/authenticate to /authentication/v2/token
2. Moved credentials from the POST body to the Authorization: Basic header
3. Added a Retry-After-aware retry loop
4. Added a Slack webhook notification for any auth failure (not an APS feature — just basic operational hygiene they should have had before)

The entire code change was under 30 lines. The biggest time cost was the six-week investigation into why the pipeline had silently died.

The lesson: Silent auth failures are the most dangerous migration risk. Instrument your integrations with active health checks that test the full auth → API call chain, not just process-is-running checks.

Case study 2: The BIM consultancy migrating an SDK-heavy codebase

A BIM consultancy had built a document management portal for multiple ACC clients. The backend was Node.js using forge-apis extensively — token management via AuthClientTwoLegged, bucket operations via ObjectsApi, and file hierarchy traversal via FoldersApi and ItemsApi. The codebase had about 2,500 lines of SDK-dependent code across 18 files.

The assessment: Not every file needed to change. The team ran a dependency audit and found that 14 of the 18 files imported from forge-apis, but 8 of those only imported the auth client (AuthClientTwoLegged) and the token refresh logic. The actual API call code in the other 6 files used the SDK's wrapper methods rather than raw HTTP.

The migration strategy: They adopted a phased approach:

1. Phase 1 (Week 1): Replace forge-apis auth with a custom apsAuth.js module using the v2 endpoint and direct axios calls. Update all 14 files to import from apsAuth.js. No change to API call logic yet.
2. Phase 2 (Weeks 2–3): Migrate API calls from forge-apis wrapper methods to @aps_sdk/data-management and @aps_sdk/oss. This involved reading the new SDK's method signatures carefully — some parameter orders changed, and the error format shifted from forge-apis's custom error class to axios error objects.
3. Phase 3 (Week 4): Integration testing against a staging BIM 360 environment. Several edge cases surfaced: the ItemsApi.getItemVersions() pagination behavior in the new SDK required an extra loop, and the user info response shape changed (name instead of firstName + lastName).

Total effort: About 3.5 developer-weeks, with the majority in Phase 2's API call migration and Phase 3's edge case discovery. If they had been on an older version of forge-apis (pre-0.9.x), the discovery phase would have been longer.

The lesson: Auth is a one-day fix. SDK migration is a multi-week project if your codebase is deeply SDK-coupled. Consider whether full SDK migration is necessary — for many teams, replacing auth only and making raw HTTP calls for the rest is faster than adopting the new SDK across the whole codebase.

Case study 3: The SaaS product team that needed PKCE

A startup had built a desktop companion application for structural designers. The app let users browse their ACC files, launch clash analysis, and download reports — all from a native macOS application written in Swift with a local embedded Node.js backend for APS API calls.

Their original Forge integration used a 3-legged auth flow with the client secret embedded in the macOS application bundle — a known security anti-pattern, but the only option under Forge v1. Any motivated user could extract the client secret from the app bundle.

The APS v2 opportunity: The migration to auth v2 was not just a maintenance obligation but a genuine security improvement. They implemented PKCE for the 3-legged flow: the macOS native layer generates the code verifier, passes it to the embedded Node.js layer for the token exchange, and the client secret is never embedded in the distributable binary.

Implementation highlights:

• Used the macOS SecRandomCopyBytes API in the Swift layer to generate a cryptographically random 64-byte verifier
• Base64URL-encoded and SHA-256 hashed in the Swift layer to produce the code challenge
• Passed both to the Node.js backend via IPC for the authorization redirect and token exchange
• The exchange call passes only client_id, code, redirect_uri, and code_verifier — no client secret

The outcome: Cleaner security posture, no client secret in the bundle, and the migration took less than a week for a developer already familiar with OAuth 2.0 and PKCE. The main friction was understanding the APS v2 PKCE documentation, which at time of migration was spread across a blog post and the API reference rather than a consolidated guide.

The lesson: If you have a desktop or SPA Forge integration that embeds a client secret, the auth v2 migration is an opportunity to fix a security debt while you are in the code anyway. Do not migrate auth v2 and keep the secret-in-bundle anti-pattern.

Case study 4: The large contractor moving from BIM 360 APIs to ACC APIs during migration

A large general contractor maintained a Node.js integration that read BIM 360 Issues, RFIs, and document versions via the BIM 360 product APIs. When they heard "Forge is being replaced by APS" they assumed this meant their BIM 360 product APIs were going away and launched a full rewrite toward ACC APIs.

What they discovered: The APS rebrand did not deprecate BIM 360 product APIs. The platform-level rename left the BIM 360 API surface intact. What did have active deprecations was the Issues v1 API and specific RFI endpoint paths being consolidated from /construction/ to /bim360/ paths — changes that predated and were independent of the APS rebrand. They had conflated two separate change streams.

The cost: About four developer-weeks spent on API migration work that was driven by a misread of the deprecation notices. The Data Management, Viewer, and OAuth changes were real and necessary. The BIM 360 → ACC product API migration was premature — the BIM 360 APIs were still active and their timeline was per-product, not tied to the platform rebrand.

The lesson: Read each deprecation notice in full and identify its scope. Platform-level changes (auth endpoints, SDK packages) are one category. Product-level changes (BIM 360 Issues v1, RFI endpoint consolidation) are a separate category with separate timelines. Subscribe to the APS blog's deprecation tag so you receive advance notice for each category independently.

Case study 5: The ISV handling multi-tenant Flex token billing

An independent software vendor (ISV) built a multi-tenant SaaS application where each tenant connected their own Autodesk account via 3-legged OAuth and the application submitted Model Derivative jobs on their behalf. Under Forge, each tenant's token was used directly, and Autodesk's billing tracked consumption against the user's account. Under the Flex token model, the billing relationship became more nuanced: the ISV's application (registered under one client ID) was making API calls on behalf of many different users.

The question they faced: Who gets billed for the Flex tokens — the ISV's account, or each tenant's account? The answer depends on which token is used in the API call. If the ISV uses its own 2-legged token to submit jobs, the ISV's token balance is consumed. If the ISV uses the tenant's 3-legged token (with data:write and appropriate scopes), the tenant's balance may be consumed — though the exact billing attribution depends on the specific API call and Autodesk's billing backend.

The resolution: The ISV audited their token usage and found that Model Derivative translation jobs were being submitted with the tenant's 3-legged token (correct behavior — the models were in the tenant's BIM 360 account) but job status polling was using the ISV's 2-legged token (also acceptable). They clarified the billing attribution with Autodesk's enterprise team and documented the expected behavior. No code changes were needed, but the billing clarity was essential for their enterprise contracts.

The lesson: In multi-tenant applications, understand and document which identity (ISV vs. tenant) is making which API calls, and verify with Autodesk which account's Flex token balance each type of call consumes. This is especially important as the December 2025 pricing model has moved some previously-free API calls into the rated category.

Limits and caveats

This post has a knowledge cutoff

The research for this article reflects the state of APS APIs and documentation through mid-2026. Autodesk moves quickly on pricing, deprecations, and SDK releases. Always verify the current state against the official APS blog (aps.autodesk.com/blog) and the GitHub release notes for the SDK you use. Treat this post as a map, not as ground truth.

Pricing details are subject to change

The billing model has already changed three times since 2022. The December 2025 pricing tier described in this article is the current structure as researched, but Autodesk reserves the right to adjust rates, free tier limits, and geographic availability. Before building a business case or pricing model for an APS-based product, verify against aps.autodesk.com/pricing-flex-tokens and consult Autodesk's enterprise sales if your volume is significant.

The "what didn't change" list is not a forever guarantee

We state that Model Derivative, Data Management, and the Viewer CDN endpoints have not changed. This is true as of mid-2026. It does not mean Autodesk will never version or deprecate those APIs. Model Derivative has been at v2 for many years; Data Management at v1/v2. Both are stable, but both have changelog entries and release notes you should monitor. Subscribe to the APS blog's RSS feed or the Autodesk developer newsletter to receive deprecation notices before they become emergencies.

SDK beta caveats

The @aps_sdk/* Node.js packages were in beta as of their mid-2024 introduction. By mid-2026 they have stabilized considerably, but any package marked beta in an earlier version you may have pinned could have undergone non-backward-compatible interface changes in the interim. If you pinned an early beta version, read the changelog before upgrading.

Regional data sovereignty

For projects serving EU customers, the regional data residency requirements in APS are more nuanced than the US-default setup documented in most tutorials. The Data Management API, the Model Derivative API, and ACC hubs all have EU-specific endpoint behaviors. If your users' ACC accounts are on the EU data center (identifiable by hub IDs and by account setup), ensure your code passes the region header and targets EU-appropriate URNs. This is not a Forge → APS migration concern per se, but it is a common source of confusion for teams building multi-region integrations and often surfaces during migration testing.

ACC vs BIM 360 product evolution

BIM 360 is being sunset in favor of ACC (Autodesk Construction Cloud). The API surface of BIM 360 product APIs (Issues, RFIs, Submittals) is being deprecated on a rolling basis per-product. This is a product-level migration distinct from the APS platform-level migration described in this post. If you have BIM 360 product API integrations, consult aps.autodesk.com/blog for the specific deprecation timeline of each API you use.

The "two migrations" confusion

Many AEC developers face not one but two overlapping migration concerns: the APS platform migration (covered in this post) and the BIM 360 → ACC product API migration. These are separate work streams with separate timelines, separate code changes, and separate business justifications. Conflating them — as happened in Case Study 4 above — is expensive. Keep two tracking documents: one for APS platform changes (auth endpoint, SDK packages, billing enrollment, developer hub migration) and one for BIM 360/ACC product changes (Issues API version, RFI endpoint consolidation, Cost Management API changes). They have overlap in the authentication layer (both require v2 auth) but are otherwise independent.

Future-proofing beyond the current migration

The APS rebrand and the auth v1 deprecation are the most pressing migration concerns as of mid-2026, but they will not be the last changes Autodesk makes to its developer platform. The pattern Autodesk has established — blog post announcements of deprecations with 12–18 month runways, multiple extension opportunities, and active developer engagement — suggests a reasonably developer-friendly deprecation process. But "reasonably friendly" still requires you to be paying attention.

Recommended monitoring practices:

• Subscribe to the APS developer newsletter (linked from aps.autodesk.com)
• Follow the @AutodeskAPS account on relevant social platforms
• Monitor the autodesk-platform-services GitHub organization for new SDK releases and security advisories
• Include the APS changelog pages in your team's regular technical reading rotation

Teams that were caught by the auth v1 shutdown were, in most cases, teams that were not monitoring deprecation announcements. The tooling around APS is mature enough that there should be no surprise shutoffs — only missed announcements.

Sources and further reading

Primary sources cited in this article

1. Autodesk Platform Services Blog — "Autodesk Forge is becoming Autodesk Platform Services" (November 28, 2022) The official rebrand announcement, including the AU 2022 context and the four-component platform framing. https://aps.autodesk.com/blog/autodesk-forge-becoming-autodesk-platform-services

2. Autodesk Platform Services Blog — "Authentication v2 and deprecation of v1" The original announcement of the v1 deprecation, new v2 features (PKCE, /revoke, /logout), and initial timeline. https://aps.autodesk.com/blog/authentication-v2-and-deprecation-v1

3. Autodesk Platform Services Blog — "Migration guide - OAuth2 v1 to v2" The definitive endpoint-by-endpoint migration reference, including exact URL changes and credential placement rules. https://aps.autodesk.com/blog/migration-guide-oauth2-v1-v2

4. Autodesk Platform Services Blog — "Important Update: Authentication V1 migration extended - May 22nd, 2024 - Final!" The final deprecation deadline announcement. The v1 auth endpoints were shut off on this date. https://aps.autodesk.com/blog/important-update-authentication-v1-migration-extended-may-22nd-2024-final

5. Autodesk Platform Services Blog — "Important Update: Authentication v1 Deprecation Extended to April 30th, 2024" The penultimate deadline extension, useful for understanding the migration timeline. https://aps.autodesk.com/blog/important-update-authentication-v1-deprecation-extended-april-30th-2024-act-now

6. Autodesk Platform Services Blog — "Migrating to the new APS Node.js SDK" The official guide for moving from forge-apis to @aps_sdk/*. https://aps.autodesk.com/blog/migrating-new-aps-nodejs-sdk-0

7. Autodesk Platform Services Blog — "Goodbye Cloud Credits. Hello Flex tokens." The Flex token transition announcement, including timeline, pricing parity, and geographic availability. https://aps.autodesk.com/blog/goodbye-cloud-credits-hello-flex-tokens

8. Autodesk Platform Services Blog — "APS Business Model Evolution" The December 2025 pricing restructure: free tier, pay-as-you-go, rated vs. non-rated APIs, enrollment deadline. https://aps.autodesk.com/blog/aps-business-model-evolution

9. Autodesk Platform Services Blog — "Forge pricing changes are here" (effective March 29, 2022) The Cloud Credit price increase from $1 to $3, IFC job reclassification to Complex, subscription model changes. https://aps.autodesk.com/blog/forge-pricing-changes-are-here

10. npm — forge-apis package page Shows current deprecation warning, maintenance status, and pointer to replacement SDK. https://www.npmjs.com/package/forge-apis

11. GitHub — autodesk-platform-services/aps-sdk-node Official APS Node.js SDK repository. https://github.com/autodesk-platform-services/aps-sdk-node

12. npm — @aps_sdk organization Lists all published APS SDK packages. https://www.npmjs.com/~aps.sdk

Further reading

• APS Webhooks API Reference — event names, subscription management, payload schema https://aps.autodesk.com/en/docs/webhooks/v1
• APS OAuth v2 API Basics — authoritative reference for v2 endpoint parameters and grant types https://aps.autodesk.com/en/docs/oauth/v2/developers_guide/basics
• APS Rate Limits Best Practices — 429 handling, backoff strategy, rate limit headers https://aps.autodesk.com/blog/autodesk-platform-services-aps-api-rate-limits-best-practices-developers
• APS Data Management Rate Limits — per-endpoint limits for Data Management API https://aps.autodesk.com/en/docs/data/v2/developers_guide/rate-limiting
• APS Design Automation Rate Limits — per-app and per-activity limits for DA v3 https://aps.autodesk.com/en/docs/design-automation/v3/developers_guide/rate-limits
• APS Pricing and Flex Tokens — current pricing page, token rates, regional availability https://aps.autodesk.com/pricing-flex-tokens
• BIM 360 API Developer's Guide — product-level API reference for BIM 360, including deprecation notices https://aps.autodesk.com/en/docs/bim360/v1/overview/
• APS Tutorials — up-to-date Node.js, .NET, and Python quickstarts using current APS SDK https://tutorials.autodesk.io/