An Overview of Autodesk Fusion 360 Manage API's

TONY MANDATORI: Welcome, everyone, to this AU 2023 presentation. This will be an overview of Autodesk's Fusion 360 Manage API. And it will be presented by three people-- Firoz, Orrin, and myself.

Before we start, we would like to give the safe harbor statement because some of the information provided here will be forward-looking.

Then we'll start with a brief introduction. The three people here are the three people I mentioned before. And we'll do a quick introduction. Firoz?

FIROZ ABDUL KAREEM: Hi. I'm Firoz. I'm a technical product manager at Autodesk working on Fusion 360 Manage. I work closely with the software development teams working on this product.

ORRIN BOURNE: Hi, everyone. I'm Orrin Bourne, a solution engineer. My background is mechanical engineering and software development. My specialization is connected product development with Autodesk. Thank you.

TONY MANDATORI: And my name is Tony Mandatori. I'm a technical solution executive for named accounts here at Autodesk. And I've been with Autodesk for about eight years.

There's going to be three major topic headings here in our presentation. I will start with getting started, where we show how to set up with importing a Web Application Development Language file and authenticating in both 3-legged and 2-legged. Then Firoz will take over with a deep dive into the APIs with the topics shown here. And Orrin will then complete the session with beyond the basics and show an application of using the API.

So getting started-- Fusion 360 Manage API is self-describing. That means that it comes with a WADL file, or a Web Application Development Language file, which defines all the API that can be called.

This use of a WADL file is completely optional. It might make your job easier because all the API is defined and documented through the WADL file. The parameters and such are provided as well.

This is beneficial when using tools like Postman and SoapUI. We will show a couple of examples in Postman.

Here is an example view of how it looks when you import the WADL file into either Postman, on the left, or SoapUI, on the right. And here's an example, a demonstration, of using this WADL file. The WADL is available at the URL /apiapplication.wadl. And it's presented here in this format, in this XML format.

Postman is able to interpret this file if you simply copy the URL and switch over to Postman. While in Postman, we'll create a workspace. We'll give it a name, Fusion 360 Manage AU Demo. And when we're in this new workspace, we'll simply choose File, Import, and paste the URL that we have from before.

And when this happens, you'll see that there is a /v3 subdirectory. And in this subdirectory, there is all the calls that we can make. There is a link to view the complete documentation. And it will be more of a pictorial of what the inputs are. However, we can simply click on one of the URLs that we can-- the URIs that we can call. And we can see that the call in Postman is configured for us with the various parameters that are available.

Moving on to authentication, with authentication, Fusion 360 Manage reuses the Autodesk Platform Services authentication, which is available at this URL for documentation. It suffices to simply register the APS app at aps.autodesk.com and then add the client ID to the allowed list in the security settings for your Fusion 360 Manage tenant.

So here is an example of the login for Fusion 360 Manage. It uses the Autodesk Platform Services. And there are two types. There's 2-legged, which requires a client ID and client secret, along with a grant type of client credentials. And it returns a token immediately.

The 3-legged, however, requires the users to log in through a typical interface which requests a username and login. And the first step of this is to call that user interface. At this point, it returns an authorization code. And then the authorization code is then presented to the second URL, /token, with the grant type of authorization code.

And you may be asking, when do I use either one of these? Well, if your application is a headless application, which runs in the background, you'll probably want to use 2-legged authentication because it doesn't require the user to log in. However, if your application is another layer that you're presenting in the UI where you actually want users to log in to identify which user is logging into this custom application, you'll want to use the 3-legged application to identify the user.

So let's get into these in a bit more detail. Here's the 3-legged authentication steps. We define our variables, v2 token URL and v2 authorize URL. We're going to use Postman to submit these calls. And we're going to define the authorization as an OAuth 2.0 type.

When we click Get New Access Token, it will ask us to log in, providing our email address and our password. Then it will provide us with a token. We'll have to click on Use Token. And then once we click on Use Token, the authorization is already provided-- is already added.

Here it is in a demonstration. We have the base URL defined as a variable, an environment variable. We have Auth 2.0 defined for the authorization, no parameters. And we'll see the other variables that we need in just a minute. The callback URL has to be the same callback URL that was registered with our APS app, v2 authorize, where those URLs I provided earlier, v2 token, provided earlier, as well, and we won't show the client ID and secret.

If we click Send without actually getting the token, we're going to get an error. So what we'll have to do is we'll have to actually authorize. And there will be a button on the lower end of the screen as we scroll down. This will get our new access token, call the interface for logging in, and here it will return the token.

We'll have to say Use Token to actually submit the token with the request. And now we can click Send. And here we can verify that the data that we got back, because we got a status of 200, which is a success-- the data that we got back did, indeed, come from the tenant we were looking at, AU 2023 Demo.

So now let's take a look at 2-legged authentication through Postman. And the way I chose to do this is to use a pre-request script. In this pre-request script, I encrypt the client ID and secret as identified in the documentation. So we have an encoded keys. And then I add the encoded keys to environment variable called Encoded Auth. And I use the Encoded Auth as the header for authorization. I then submit the request before the actual request in the-- that's shown in the header. And let's see how this looks in Postman.

So here's an example in Postman where we have a request for Workspaces. And everything looks similar. However, we don't have any authentication defined, authorization defined, on the request. We don't have any authorization variable, either. But we do have our tenant, our ex tenant, AU 2023 Demo, and our user ID, myself.

And the pre-request script is going to handle everything else. And all we have to do here is simply send the request. And we will notice that we can log in and get the data without actually having an interaction with the user.

And again, we will verify that we've got the data from the AU 2023 Demo. And now I'll pass it over to Firoz to take it away with the deep dive.

FIROZ ABDUL KAREEM: Now that Tony has shown us the authentication part and how to make the very first call to Workspaces, let's deep dive into the APIs for Fusion 360 Manage. And we'll start with the Item Detail API.

For the Item Details endpoint, we'll go over the get method first. And then-- which the get method, which is used to read the item-- and then we'll follow it up with the methods that are used to update the item. These are the put and the patch methods.

The get method requires two IDs to work with. It requires the workspace ID and the item ID. This method returns the payload with the sections, fields, and values of the fields that are present in the item. The difference between the put and patch methods, both of which are used for updating the item, is that put requires a full payload of the item, meaning it requires all the fields that are present in the item, whereas patch requires only the fields that are getting updated in this call.

Here, I'm on a workspace, workspace number 70. I'm trying to create an item from the UI. I enter the mandatory fields, which are Title and Team in this case. And I select the priority of my document change order. And I'm able to save this item. When it is saved, I see that the-- I see the workspace ID and the item ID as part of the URL. In this case, the item ID is 15236.

Now, here is a get call made to the Item Detail API. So there's the URL, which includes workspace ID and the item ID. And the get returns a payload, which I'm now copying into a JSON formatter so I can have a better view of it. And the response of the get includes all the sections that are part of the item. So in this case, there are two sections-- section one, summary, and section two, approval.

Section one contains five fields. So these fields are present in the payload. And the value of every field is also missing. So there is the field number. There is the field title with its value. The field team is slightly different because it's a picklist. So its value has a different format. So this is a picklist pointing to another workspace. You have its value. It points to workspace 64 and item ID 9843 in that workspace.

So that was the get. How do we update the item using put? As I mentioned earlier, put requires the complete payload. So what I'm doing here is I'm duplicating the tab on my Postman and changing the method to put. Now I'll copy the payload, which I got back as a response of the get, and use that as my request for the put method.

I'm going over the payload. And I'm trying to change the field title here from User Guide Update to User Guide Revamp. So I make the update. I change the field that I want to update in the payload. And I also have to add a request header, the content type header. So this is how I'm telling the method that I am passing JSON as input for the put call. So the content type is application/json.

Now I issue the put call. But it comes back with a 204, a successful response. And when I go and look at the item and refresh it, the value got updated to User Guide Revamp.

How is put different from a patch? So here's a look at patch. Patch, as I mentioned earlier, does not require the full payload. It requires only the fields that are changing.

So again, in this case, I'm copying my-- I'm copying the response payload of the get-- copied it over to a JSON formatter. And now I'm deleting all the unwanted fields. I'm keeping only those fields that I want to update. So in this case, I'm deleting every field other than Title from this payload. And even for the field Title, I need to pass the value, the Self field, and the title of the field.

So I have deleted all of the properties of that field. I'm keeping only the bare minimum that is required. And I'm changing the value here to User Manual Update. I will copy this payload over to Postman, change the method to patch, and issue the call. It comes back with 204, success. And now if I go and refresh the item, I can see that the title got updated to User Manual Update. So that is the patch.

Moving on to create-- so post is the method that is used to create the item. The post method requires all the mandatory fields to be passed in the payload. And-- since it respects validation. So if mandatory fields are not passed, validations will fail and item creation will fail. Here is a look at post.

So here, I'm duplicating my Postman tab. I'm changing the method to post. Now, we are creating the item. This means that the ID of the item is no longer relevant because we don't-- the item is yet to be created. So I delete ID from the URL. And here, I'm trying to pass only field-- only the field title in the payload. And the value that I'm passing is User Documentation Update.

When I send the payload, I get a validation error. The error code is 400. And it says that I must select an option for the field Team. Let me look at the UI. It seems that Team is a mandatory field. So I need to pass it.

In order to get the value of Team, the payload of Team, which I have to pass to the post, I am copying my-- copying the response from the get payload. And I'm trying to get this field from the response of the previous get call that I made.

So there it is. I'm copying the field that I need and deleting the properties of the field that I don't need, or I'm keeping only the mandatory properties that needs to be passed to the payload, which are Self, Title, and Value. I then copy this over to Postman, add the second field, the mandatory field, to the payload, and send the request.

So the request comes back with a success. And now if I look at the response header, there is a property called Location in the response header, which gives me the URL of the item that just got created. It has ID 15239.

If I refresh the workspace, I can already see the item there. When I navigate to the workspace, I can see that this is the item that I created. It has the ID 15239 and the title User Documentation Update.

So that was post. Now, as part of post, I had to pass the value of a picklist because that was a mandatory field. Now, when I performed the post, I actually copied the value of the post from a previous get payload, from a previous get item payload, that I got.

This is not how I should have done it. There is a different method here, which is to actually-- which should be used to get the picklist values. This requires lookup ID or the picklist ID as an input. And the API is /api/v3/lookups. Lookup ID can be found in the picklist manager under System Configuration. Let's take a look at that.

So here I have my picklist, which is called Team. It is a picklist linking to another workspace. And it has four values. If I go to the workspace manager and open my document change order workspace and go to the field Team, I can see that it's a single selection picklist, which is sourcing from Approval Lists workspace. And the picklist ID that you see there-- that is the lookup ID that I need in order to make this API call. When I make a call to the API, a get call to the API, it comes back with a response. There are four items in the picklist. And there are the values. So this is how we should get the value of a picklist and then use that value on put, post, or patch calls.

So now that we've seen the Item Details tab and Picklist, how do we navigate to other tabs in the application, other tabs, such as Affected Items, Bill of Materials, Change Log, Grid? So there is a very generic method to navigate to these tabs, to get the details of these tabs. All these tabs are represented as views in the API. So the API call to be used is v3/workspaces/workspaceid/items/itemid/views.

Now, the /views API will give us a list of all the tabs and the corresponding view ID of each tab. In order to get to a tab, we should make another get call to /views/viewid of that tab. We'll also take a look at another API call, which is /tabs, which gives you the count of all items-- the count of items that are present in each tab.

So here, I'm navigating to the affected documents or the Affected Items tab on my change order. It has two entries and change log. Let's see how to go-- how to navigate to those tabs through using the API.

So I make a call to /views, itemid/views. And it returns me the name of the tab. So in this case, views/11 is managed items or affected items. Views/15 is change log.

Now, when I make a call to views/11, I get the response corresponding to managed items-- corresponding to view/11. So in this case, the Managed Items tab contains two items. So what I get back in the response payload is descriptor of those items, the lifecycle state, the effectivity set on those items, exactly the details that you would see on the UI.

Now, if I go to the change log, which is views/15, I'll get to see the information displayed in the change log, which is the actions performed on the item, the user who performed those actions, and the timestamp of those actions.

Moving on, to find the count of items present in each tab-- so this URL is item/id/tabs. So here, in the response, I can see that the Linked Items tab contains two entries-- attachments. There is one direct attachment and six related attachments. Grid has two entries. And I can see the same information on the UI. So attachments-- there's one direct attachment. There are six related attachments. Grid has two entries. And affected items had two entries.

So now that we have seen the item-related API calls, let's go to some admin APIs. I'll start with the user administration APIs. So here, I'll go over the Users API, the Groups API. And I'll show how to assign users to a group or how to assign a user to multiple groups.

So here, the first API call that I'm making is to api/v3/users/atme. /atme gives information about the logged in user. It returns information, such as user ID, the date format that the user has set up, the groups that this user is part of, and all that. And I can make the same call using user ID. So the API call can be users/atme to get all users' information, allusers/userid.

Now, as an admin, I'm also able to make a call to /v3/users to get information of all the users in the system. In this case, there were seven users. Here, I'm using a filter on first name. I want to get details of the user Jane, which is why I use a filter on first name called Jane. And I get info of that user. I get the user's user ID, login name, et cetera.

And I copy the user's ID and make a call to that user. So that's another way now to get to that user. What you see here is the groups API-- so api/v3/groups. What the response payload says is that there are 26 groups in this tenant. So that's the total count. And then I get to see details of each of those groups.

Here, I'm using a filter to get details of a group by the name Engineering. So there is one group with the name Engineering. And I can get details of that group. So in this case, the group ID is 133.

Now, how do I add one user to multiple groups? So in this case, I want to add this user, Jane, the user with ID S-T-V-I-X. This user currently is part of two groups, Administration and Admin group. I want to add this user to the group Engineering. So I have to find the URL of the group Engineering. And I also want to add this user to another group, which is called Executive. So I find the URL of the group Executive.

And the API call that I have to make is post because it's a post call to users/userid/groups. And the request payload that I need to send is in the comma-separated format with the URL of the two groups where I want to add this user. So I issued the call. I got a success response. And now when I get the user, I can see that this user is part of four groups now, including Engineering and Executive. They were part of that many group. And they still remain in the Admin group.

Now, in this case, I'm doing the mirror image of what was done in the previous case. So here, I want to add multiple users to one group. So in this case, the group is called Importer. I want to add two users to the group Importer. So I get the group ID. The group ID in this case is 135. And I get the URL of the users that I want to add. So one of the users is John.

So I get the URL of that user by making a call to the Users API. And I follow the same steps to get the URL of the user Jane, who I want to add to the group Importers.

And now I made a post call. The URL in this case is groups/id/users. And the payload is comma-separated-- is in comma-separated format with the URLs of the user you want to add. And that came with a successful response. Now if I get the groups Importer again, I see that it includes the two users that I added-- so user Jane, STVIX, and user John. Tenant admin was already part of that group. This is the second user that I add, user John.

So those are the user administration APIs. Now here, I'll take a look at the System Logs API. Now, System Logs-- it tracks all the user and system activity on the Fusion 360 Manage site.

So there is a way to access system logs from the UI. So you navigate to Administration, System Configuration, and System Log. And you'll be able to see the date and time of actions performed by the user, the name of the user who performed it, the type of action, and some details about the action.

The limitation of checking System Log from the UI is that you will see entries for the last 60 days. That is all that is displayed on the UI. However, there is an API for system logs, which can be used to see more details. Rather, the API does not have the 60-day limitation that the UI has.

So here is a look at how the System Log will be on the UI. So in this case, I'll go over the System Log API. And I'll also show how certain parameters can be passed to the API parameters, such as limit, offset, some filters on the System Log API. I'll go over the sort method, how to sort the response of System Log. And I will also show the filter by date on this API.

So the API call is the URL api/v3/tenants/tenantid/system-logs. So tenant ID in this case is [INAUDIBLE]. So that's the tenant where I'm getting the system logs from. And I see that user John Doe has logged out of the system at a certain timestamp. So that's the first activity-- that's the latest activity. And by default, activities are ordered in descending order of the timestamp. So user John Doe logged in first. And then I can also see activities from another user, Mary [INAUDIBLE] in this case.

So that's the generic call to system logs. Here, I'm inputting a parameter on-- called limit. So I'm restricting the count of items returned in my payload to two. So I just want to see the latest two records. And I get to see the first two entries from user John Doe.

Now, the response payload also includes the URL, which can be used to navigate to the next page. That URL includes using offset and limit. So when I use offset 2, I start fetching-- I start-- I get a response starting with the third record. So I offset the first two records. And I start with the third in this case.

Here, in this case, I want to see only the activities from user Mary. So I'm using a filter on user title. So right now, I have not issued a call. I can see activities from user John Doe. But when I issue a call with a filter on user title, I get to see only those activities from the user Mary [INAUDIBLE] in this case.

And in this case, there are four activities from the user. And again, it's in the descending order of timestamps. So what you see is log out, log in, profile sync with oxygen, and modify user in that order. However, this is not the order in which I want to see the response. I want to see it in the ascending order. So I add a sort parameter to the request. So here, I'm sorting by timestamp ascending. And I get to see the items in the ascending order of the timestamp in which those actions were performed.

Now, here, I'm adding filter on Date. So I want to see activities from user Mary on the day 20th September, 2023. So I have two filters added, one on from date and one on to date. And the payload shows me only activities from that date.

Now I'm changing from date to 10th of September. And I keep to date same as 20th of September. And I see the same activities. But this user has activity only on the 20th. So now when I change to date to 19th, I don't see-- I don't get a response. I get an empty response because this user has no activity between the 10th and the 19th. Now, I'm removing the filter on user Mary. And when I do that, I see that my user, Firoz, has logged in to the system between the 10th and the 19th.

And in this example, I'm just combining multiple filters. I'm combining all the filters that we just saw-- so limit, offset, filter on title, filter on dates, and the sort. And I don't get a response here because I was filtering on username. And some dates were-- that user had not logged in. But when I put the proper dates, which is the 20th of September, I get a response. So all these parameters can be combined and used, depending on what the intent is.

So now I'll move on to some nuances of the Fusion 360 Manage APIs. One of them is content negotiation. So what does this mean? The same payload, the same request, the same URL returns different responses depending on the accept header that is passed to the request.

So there are multiple-- there are different accept headers that are accepted by our APIs. And some of those are-- well, obviously, for data, application/json is used. To get metadata, there is a different accept header, which is application/vnd.autodesk.plm.meta.json.

And for the bulk, to get the bulk responses, the relevant accept headers should be used. So to get the bulk response on Workspaces API, the accept header to be used is what's shown there, which includes .workspaces.bulk.json. In order to get the bulk response on the Bom API, the accept header to be used is .bom.bulk plus json. And for sections, it is .sections.bulk plus json.

So let's take a look at those APIs in action. So here, I'll start with workspace views. When you land on a workspace view, what-- when you land on a workspace, what you see the-- is the workspace view. Now, workspace view has data and metadata. Data is the two items that you see on the workspace, on the workspace view. And metadata is the columns and the filters applied on those columns.

Here, I'm making a call to the tableaus/1177, which is the workspace view. And I'm passing the accept header as application/json. And I get the data back. Again, data is information related to the items, to the content of the workspace view. So I get the item descriptor that is displayed on the workspace view. I get the current state that is displayed on the workspace view. And I get the priority. And I get this information for both the items that are displayed on the workspace view.

Now, what happens when I change the accept header to get the metadata? So here, I changed the accept header. And now I get the response. And the response includes the columns that are part of the workspace view. So the first column is Item Descriptor. I get Current State, which is the second column. And I get details about the third column, which is Priority.

And in this case, Priority has two filters applied on it, priority filters-- and looks for values high and low. So there is the part where it shows the applicable filters and the applied filters. Applied filters in this case includes two items. That is for priority high and priority low. So those are the applied filters, the two filters that are applied in this workspace view. So by changing the accept header, I am able to see data and metadata from using the same URL.

Now let's take a look at the Bulk API call. So here, this item has two sections. Section one is summary. Section two is approval. And when I make a call to workspaces/id/sections with the accept header for data, this is what I get. I get details about these two sections, just the name of the section, the title of the section, and the link to the section.

Now, if I make-- if I change the accept header and use the accept header for bulk, I get more details about these sections. I get the name. I get the details of the fields that are present in that section. I get information such as whether the section is subject to workflow lock or not. And in this case, the section-- the second section has a matrix. So I get details about matrices that are part of the sections. And it includes the row names, column names, et cetera, that are part of the matrix.

So basically, the same URL by changing-- the accept header, I was able to get data. And I was able to get bulk data, more data. That's how we make use of content negotiation in our API course.

Now, when I showed the put and the post API calls on item details, I was copying the payload from a previous get call. Now, there is a better way, too. There is a fast and efficient way to make API calls in order to get started quick, which is copy as cURL. And let's see how to do that.

So here, I'm editing an item and changing the title [INAUDIBLE] from Design to Design Spec. I need to now go to the Developer Tools. So I right-click and go to Inspect. And then I switch to the Network tab. And when I hit Save, I see the patch API call that was issued. All I do now is right-click on the patch, copy, and copy as cURL.

Now I switch to Postman. And I import the cURL that I just copied-- so import as cURL and paste. And here, I have the URL. I have the method. I have the body of the URL as well.

Now, here I'm changing the URL. So now I want to update once more to design specification. So I made the change in the payload. It copies over-- the cURL copies over the headers. It even copies over your authorization bearer token from the browser. And now I can easily perform a patch call. And I see that the item is updated. So this is a quick way to get started with the APIs. And this eliminates the need to build the payload from scratch.

Next one-- so here, here I show a quick way to generate code from Postman. Postman allows you to select the language in which you require the code. And you can select the code, copy it, and use it in the app that you are developing.

So I'm making a call to workspaces/id/sections. If I click on the Code button on Postman, it opens a code snippet. And I can select the language in which I need the code. And this is code that I can copy over and use in my application, of course, after making any needed tweaks.

Now, API version-- so when we develop APIs, we make sure that there is backward compatibility within the same version of the API. So currently, all the calls that we saw were to the V3 version of the API.

Now, this V3 version is undergoing changes, as we do weekly releases of Fusion 360 Manage. So that API gets updated. But we don't delete any existing property or update the name or the format of the response in the payload-- in the API that is published.

However, we will be introducing new properties within the same version of the API. So a recent property that we introduced was on the Workspaces API. It did not contain the system name of the workspace in the past. But this was recently introduced.

So one thing to keep in mind while writing integrations is to make sure that the integrations are resilient to any new properties that are being added to the API call-- rather, ignore the unknown properties in the integration work with the known properties. And the known properties will not be deleted or updated. Currently, we support three versions of Fusion 360 Manage APIs-- V1, V2, and V3. And the version number is present in the URL.

Now, we will create a new version when some incompatible changes are needed. There are no plans for a new version at the moment. But this is a strategy. And when new versions are created, we could deprecate older versions, of course, by providing proper notice for customers to make changes to the integrations. And we always recommend using the latest version of the API integrations.

Now I'll pass on to Orrin to show these APIs in action.

ORRIN BOURNE: What you just saw were some excellent examples of how you access and use the Fusion 360 Manage API. While this class is very technical in nature, for this final section, the intent is to inspire you to create applications of your own.

The Fusion 360 Manage APIs are very useful for building business systems integrations. However, they can be used to create custom applications of surprising sophistication.

The architecture of Fusion 360 Manage allows us to leverage PLM functionality directly through the APIs. The back end is separated from the front end user experience. You could potentially drive PLM completely through the APIs alone. What follows next are three examples of how you could leverage the APIs for enhanced PLM experiences.

First, we'll look at how the APIs can provide an easier way to access and modify the manufacturing bill of materials. Then you'll see firsthand how data from Fusion 360 Manage can bolster your product support activities. And finally, we'll close out with an example of how a configurator based on Autodesk Platform Services can connect PLM to a customer-facing website.

Here we have Fusion 360 Manage. You see the Ember printer product. This came over from Vault. We have the engineering building materials accessible to us. Additionally, we are currently working on the manufacturing bill of materials. Without the API, we would simply go into the manufacturing bill of materials and manually modify the BOM as needed, or perhaps we download it into a spreadsheet, manipulate it, and then re-import that back into Fusion 360 Manage. Using the APIs, we have a better way of managing the data.

What you see is an aggregation of the viewables from the Attachments tab, the engineering bill of materials and the manufacturing bill of materials presented side by side. This application allows me to have a better experience in managing the transition from the engineering BOM to the manufacturing BOM, all being pushed through by using the APIs.

Here I see an example of an item that is not yet added to the manufacturing bill of materials. I simply add the item, position it where I want to be. And if I save it, I'll commit that to the manufacturing bill of materials. Additionally, I can use the API to pull in more items from Fusion 360 Manage and simply drag and drop them where I want them to be.

For this next example, let's take a look at how we could use Fusion 360 Manage APIs to bolster our services portal. By simply clicking on the Services Portal link, again, I launch a companion website. Once again, I'm using the APIs to pull together a viewable through the API, also accessing the bill of materials, and connecting to information about availability of spare parts.

In this particular example, I can use this application to zoom, view the spare parts, confirm that this is, indeed, what I want, and submit a request back to PLM to fulfill this need. Back in PLM, do a little refresh. I see the request that just came in from the field. I see the item requested, the quantity requested, and now I have the workflow that I can enact to determine how to fulfill supplying this component to the need.

And lastly, we have an example of a configurator. Here in Fusion 360 Manage, I have a product that is being managed. I have customer-facing information stored directly inside the metadata of the item, and also have attachments. On a customer-facing website, when I navigate to the product, I see a configurator that displays that information pulled over through the API.

If, perhaps, I have a document that needs to be uploaded that I want customers to have access to, I simply upload it. And automatically through the API, the document is now presented. That happened live. And conversely, if want to remove a document, again, on the customer-facing website, that document is automatically pulled down.

I can continue this experience further by leveraging design automation. So here, a customer might go to your website, update the desired configuration, and then submit a request for quote. That quote is submitted. And then using the API, a request is provided back in PLM. Here is the newly requested quote coming in from the field, and also information about the product configuration.

That was a lot. Let's catch our breath and review what you just saw. You saw that Fusion 360 Manage API provides great capabilities for extending the value of PLM. First, Tony explained how to get started by accessing the WADL to get a list of API endpoints. Then he demonstrated how to use Postman to access and test the endpoints. And you saw the methods for obtaining an authorization token used to access all Fusion 360 Manage APIs.

Then Firoz gave you a deep dive into the APIs by showing you a variety of API calls and how to use the developer tools to assist. And finally, you saw three examples of the APIs in action and how they can add value to your business processes.

Additionally, here is more information I strongly encourage you to investigate further. And also, remember to download the documentation from the AU website for this class. There will be plenty of additional information to help you.

I'll leave you with a final thought. "The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn"-- Alvin Toffler. Thank you.