Overview#
Fusion is not a closed application. Almost everything you can do by clicking in the interface can also be done from code, and a good deal of data and logic that the interface hides is reachable too. Autodesk exposes this through the Fusion API, a desktop programming interface that runs inside the Fusion process. With it you can create sketches and features, read and write parameters, drive the CAM and Drawing workspaces, build custom commands and dialogs, react to what the user does, export files, and glue Fusion to other software.
This page is the map for the whole section. It explains the vocabulary, the different ways code can touch Fusion (local API, cloud APIs, automation), and how to choose between them. The following pages go deep on each piece.
The key idea to hold on to is that "scripting Fusion" really means one of three quite different things:
- The desktop API. Python (or C++) code that runs inside the installed Fusion application on your computer, against the document that is open. This is what most people mean and what most of this section covers.
- Autodesk Platform Services (APS). Web APIs that run in the cloud. They handle authentication, file storage (Data Management), file translation and viewing (Model Derivative), and server-side automation (Design Automation). They do not need a running Fusion on your machine.
- Automation services. Running scripts and Fusion-related jobs without a person at a Fusion window. Autodesk's documentation mentions a Fusion Automation API service that runs TypeScript scripts, a Design Automation API for Fusion, and MCP servers that let AI clients drive Fusion. The final page of this section sorts out what the documentation does and does not say about each.
Tip: If you only need to do something repetitive to the models you already have open, such as renaming bodies, exporting every component to STEP, or generating a family of parts from a table, the desktop API in Python is almost always the right tool. Reach for APS when the work must happen without a person sitting at Fusion.
Where to find it#
You reach the desktop API in several places:
| Place | What it gives you |
|---|---|
| Utilities tab > Scripts and Add-Ins | The dialog that lists, runs, stops, creates, and edits scripts and add-ins. Shortcut: Shift+S (Autodesk's System Modeler setup topic quotes this shortcut). |
| The online Fusion API help (help.autodesk.com, "Fusion-360-API") | Three parts: the User's Manual (overviews), the Reference Manual (every object, method, property, event and enum), and Code Samples. The same content is available as a CHM file for offline use. |
| The in-help Sample Programs list and the samples linked from each reference topic | Complete scripts you can copy, paste and run. Most small samples demonstrate one function and are reached from that function's topic. |
| The Fusion API and Scripts discussion group | Autodesk's help names it as the place to ask API questions and browse earlier answers. |
| Visual Studio Code | The editor Fusion uses for Python and TypeScript scripts when you choose Edit. |
The Preferences dialog has a General > API section where the default script and add-in folders can be changed (the Fusion MCP overview also places the local MCP server switch there). If you cannot find the Scripts and Add-Ins command on the Utilities tab, use Shift+S.
Step by step#
This step list is a first pass through the landscape, not yet coding.
- Open Fusion and a design. The API always acts on the active product of the active document, so have something open.
- Open Utilities > Scripts and Add-Ins. The dialog lists scripts and add-ins; you can filter the list (for example to Add-ins only, or Running only) and mark favorites.
- Select a sample script and run it by clicking the run icon beside it. Notice that scripts run once and end, while add-ins stay loaded; the dialog shows the running state of each item with a different icon.
- Select the same sample and use the Edit in code editor command (pencil icon, or the context menu). Fusion opens the item in Visual Studio Code and offers to install VS Code the first time. Read the code before moving on.
- Open the online API reference in a browser tab. Search for
Application,Design,Component, andSketch. These four classes appear in almost every program. - Continue to the next pages, which build a script from nothing.
Languages#
Python#
Python is the most documented language. Fusion bundles its own Python interpreter, so you do not need to install Python separately to run a script. The Python that ships with Fusion includes only the core modules of a standard Python installation. Autodesk recommends that you do not install extra modules or edit sys.path; instead keep a local copy of any third-party module inside your script's folder (or a subfolder) and import it with a relative import such as from .Modules import xlrd. The debugging page covers this.
The Python version is not stated in the topics used for this guide. Print sys.version from a one-line script to see which one your install runs.
Python code imports two modules:
import adsk.core
import adsk.fusion
import adsk.cam # only if you work with the Manufacture workspace
adsk.core holds the application, user interface, geometry primitives, and general utilities. adsk.fusion holds the design, modeling, and sketching classes. adsk.cam holds toolpaths, setups, and operations. The reference also lists classes in the namespaces adsk::drawing (Drawing workspace, about 150 topics), adsk::electron (electronics, about 140 topics) and a volumetric modeling group (about 30 topics). By topic count the reference is roughly 1,060 fusion, 340 core, 250 cam, 150 drawing, 140 electron and 30 volume pages.
C++#
The C++ API exposes the same object model to compiled scripts and add-ins. It is useful when performance matters, when you wrap an existing C++ library, or when you need to ship an add-in without source. Visual Studio (Windows) and Xcode (Mac) projects are generated for you. A dedicated page covers it.
TypeScript and JavaScript#
Autodesk's documentation lists three languages: "Fusion has a single API that can be used from Python, C++, or TypeScript." TypeScript topics carry an experimental flask marker in the help. You choose TypeScript in the Create dialog, import the API with import { adsk } from "@adsk/fusion", and export run and stop functions. TypeScript is transpiled before it runs, and plain .js files are executed directly without the TypeScript compiler. For scripts that run on the Fusion Automation API service, import from @adsk/fusion/automation instead; that is the subset available in the service environment. See the final page of this section.
Separately, JavaScript is also what runs inside palettes: small embedded web pages (HTML plus JavaScript) that talk to your add-in through events. The JavaScript in a palette cannot call the Fusion API itself; it passes data to your add-in, which calls the API.
Scripts versus add-ins#
The single most important distinction in the desktop API:
| Script | Add-in | |
|---|---|---|
| Lifetime | Runs when you press Run, ends when run() returns | Loads, then stays resident until stopped or Fusion closes |
| Entry points | run(context); Fusion unloads the script when run returns | run(context) and stop(context); stop is where cleanup happens |
| Can start with Fusion | No | Yes, with Run on Startup |
| Typical use | One-shot jobs, batch exports, quick generators | Custom buttons, palettes, event listeners, long-lived tools |
Manifest type | script | addin |
A script cannot respond to events after it ends, with one exception: a Python script can deliberately keep running by calling adsk.autoTerminate(False) and then calling adsk.terminate() when it is finished. Autodesk's Commands topic uses this to let a script run a command and handle that command's events. Anything that adds a persistent button to the interface should be an add-in. The context argument is a dictionary in Python; run receives IsApplicationStartup (true when the add-in loads at Fusion startup) and stop receives IsApplicationClosing.
Anatomy of an API program#
Every Fusion program has the same shape. It gets the application object, finds the active document and design, does work through the object model, and reports problems through the UI.
import adsk.core, adsk.fusion, traceback
def run(context):
ui = None
try:
app = adsk.core.Application.get()
ui = app.userInterface
design = adsk.fusion.Design.cast(app.activeProduct)
if not design:
ui.messageBox('Open a Design workspace document first.')
return
root = design.rootComponent
ui.messageBox(f'Root component: {root.name}\nBodies: {root.bRepBodies.count}')
except:
if ui:
ui.messageBox('Failed:\n{}'.format(traceback.format_exc()))
Three habits visible in those few lines recur everywhere:
Application.get()is the doorway. There is a single application object.Design.cast(...)is a safe downcast.app.activeProductreturns a genericProduct; casting toDesignreturnsNoneif the active product is something else (for example Manufacture), which lets you test with a plainif not design.- Wrap
runin try/except and showtraceback.format_exc()in a message box. Otherwise a failure is easy to miss.
Units and coordinates#
For Design data the API's internal ("database") units are fixed: lengths in centimetres, angles in radians, mass in kilograms, regardless of the unit shown in your document. Autodesk's Units topic lists a different set for CAM: length in cm, angle in degrees, linear velocity in mm/min, rotational velocity in rpm, time in seconds, weight in kg, power in W, flow rate in l/min, area in cm2, volume in cm3 and temperature in degrees Celsius. When you pass 1.0 to a sketch circle radius you get a 1 cm radius, which is 10 mm. This surprises everyone once. Two remedies exist: multiply millimetre values by 0.1 yourself, or use the UnitsManager to convert expressions and values (design.unitsManager.convert(25, 'mm', 'cm')). ValueInput.createByReal values are always database units, while strings are interpreted in the current document units unless they carry units, so '25 mm' always means 25 mm and '3' means 3 of whatever the active unit is. The user's choice of default length unit also sets the default mass unit (inches give pounds, centimetres give grams), and angles shown to the user are always degrees.
The up direction is a user preference: Application.preferences.generalPreferences.defaultModelingOrientation "gets and sets the default for which direction is considered up". How that setting maps onto API coordinates is not described in the topics used for this guide, so read points back from the geometry (for example with Sketch.modelToSketchSpace and sketchToModelSpace) rather than assuming an axis.
Transactions and the timeline#
Each change to a parametric design adds an entry to the timeline. When your script creates features, those features appear in the timeline just as if a user had made them, and they are parametric: a user can edit them afterwards.
Undo is different from what many people expect. Autodesk's Commands topic says that without a command, "every API call that causes a change within Fusion will show up as a separate operation in the undo list": a script that draws three lines needs three undos. Everything you do inside a command's execute handler is bundled into a single transaction and undone in one step, which is a main reason to wrap script work in a command (see the UI page).
design.designType returns adsk.fusion.DesignTypes.ParametricDesignType or DirectDesignType. Changing an existing design from parametric to direct removes the timeline and all design history, and some methods (for example the through-all and two-side extrude setters) fail for non-parametric extrusions. Check designType if your program depends on history, and tell the user clearly. designType is not the same as design.designIntent (part, assembly or hybrid).
The cloud and automation layers#
Beyond the desktop, Autodesk offers:
- Data Management API to read and write hubs, projects, folders, items, and versions: effectively the programmatic face of the Fusion data panel.
- Model Derivative API to translate designs into viewable formats (SVF2) and extract metadata, used by custom web viewers.
- Design Automation API to run Autodesk engines in the cloud on your data. Autodesk's 2025 release notes (May 2025 section) list a "Commercial release of the Design Automation API for Fusion".
- Fusion Automation API service that runs TypeScript scripts in a service environment, and the Fusion MCP servers that let AI clients drive a live session or query cloud data.
Note: not confirmed in Autodesk's documentation (the Fusion help mirror): the endpoints, scopes, quotas, pricing and engine lists of the Data Management, Model Derivative and Design Automation services. Those live on the APS portal. The final page of this section labels which statements come from the Fusion documentation and which are general APS knowledge.
Options reference#
The following table summarises the choices when you start a project.
| Need | Recommended route | Notes |
|---|---|---|
| One-time batch job on open files | Python script | Easiest start |
| New toolbar button, dialog, or panel | Python add-in with a command definition | Needs manifest and run/stop |
| Rich web-style user interface | Add-in with a palette (HTML/JS) | Palette talks to Python via messages |
| React to document events | Add-in with event handlers | Keep references to handlers |
| Heavy numeric work | C++ add-in, a WebAssembly module called from TypeScript, or vendored Python code | Autodesk's TypeScript topic and the WasmComputeSample describe the WebAssembly route; NumPy availability is not documented |
| Browse or move cloud files from a web app | APS Data Management | Needs OAuth and an app |
| Show a design in a web page | APS Model Derivative + Viewer | Translate to SVF2 |
| Unattended server-side processing | Design Automation API for Fusion, or the Fusion Automation API service | See the final page of this section |
Tips and pitfalls#
Tip: Keep the API reference open and look up every class you use. Names are consistent: collections end in
s(sketches,features), creation objects areInputobjects (ExtrudeFeatureInput), and creatable collections have.add(...)or.createInput(...)methods. All collections supportcountanditem(index)(zero based); many also offeritemByNameoritemById.
Tip: Use
app.log('message')to write to the Text Commands window (or to the Fusion app log file; the reference says it logs "to either" place). The palette isui.palettes.itemById('TextCommands')and Autodesk's help lists a Show/Hide Text Commands command. It is the lightest-weight debugging channel and requires no editor.
Warning: The API changes over time. The reference marks superseded members as RETIRED: they "continue to work" for backward compatibility but are "no longer officially supported" (for example
ExtrudeFeatureInput.setDistanceExtentandOccurrence.transform). Prefer the replacement the reference names, and test your code after a major Fusion update.
Note: not confirmed in Autodesk's documentation: which licence types may use the API, and whether Personal-use limits affect scripts or cloud services. Check your licence terms before building a commercial tool.
Warning: Do not hold on to API objects after the document changes. Every object has an
isValidproperty that returnsFalsewhen the reference "has been deleted or some other action done to invalidate" it.
Tip: Every API object also has
objectType(a string such asadsk::fusion::BRepFace) and a staticclassType(); compare them withobj.objectType == adsk.core.Point3D.classType()to test an object's type.
Practice exercise#
Run the script in the anatomy section above. Open a design that has at least one body in the root component, run the script, and confirm that the message box shows the root component name and the correct body count. Then change it to print the number of sketches (root.sketches.count) and the count of components (design.allComponents.count). Expected result: the numbers match what you see in the Browser tree, remembering that allComponents includes the root and every nested component.
For a stretch goal, change the message box to a call to app.log(...) and find the message in the Text Commands window.
Related#
- Scripts and Add-Ins dialog and your first script (next page)
- The API object model (Application, Document, Design, Component)
- Autodesk Platform Services overview, later in this section
- Autodesk Platform Services and Fusion automation (the final page of this section)