Up and Running with Fusion Data API

PRESENTER: Would you like to be able to access Fusion model and lifecycle information without having to install Fusion 360? Then the Fusion Data API for you. I'm Adam Nagy, a Forge developer advocate, and this is the topic I'm going to cover. I will be making some forward-looking statements. So here is our usual safe harbor statement slide that you can read later on in your own time.

The Fusion Data API provides manufacturing design data in the cloud with granular and easy access. Currently it only enables read access to data, but we are working on letting you modify existing data and also extend it with your own custom data.

We want to provide a cloud-based source of truth for all valuable product design and manufacturing data. It will not matter whether the data is altered by an Autodesk application or a third party application. No need for desktop altering applications, like Fusion 360 or Autodesk Inventor, to access it.

In another presentation, you might have seen how our partner, Bommer, is using this API to synchronize data between multiple systems and can even use it to provide notifications to users when a new milestone version of a model is available.

Fusion Data is one part of the global cloud information model we are working on. This API focuses on the manufacturing side of things and provides the following. Access to model properties, like part number and description. I'm not talking about the new model properties API. That is available in Autodesk Construction Cloud. This is about properties coming from the Fusion 360 model.

The API lets you traverse the hierarchy of the model, including both internal and external subcomponents and access life cycle properties that are in sync with what's available inside Fusion 360 Manage or lifecycle product.

Thumbnails, even for internal components, unlike with the Model Derivative service, where you could only get thumbnails for a file, not for an internal component. Then eventing, in other words, getting notified about certain events, like creation of a milestone version. We call it eventing to differentiate it from the well-known Forge web hooks API that you might be already familiar with.

And beyond all the above, it also exposes all the data management API functionality related to getting the list of hubs, projects, folders, files, and versions a given user has access to. So you could create an app only using Fusion Data API that lets the user navigate all the files they have access to on Forge and then provide model and lifecycle information about the selected model.

All the properties and hierarchy information are stored in parallel with the geometric information. So far, shown as option B, if you wanted to get information out of the model, then you had to get it translated first, and then you had access to model properties and hierarchy information. But now with Fusion Data, which is shown as option B, you can access such data as soon as the file is saved and the new version is created without having to wait for any translation to take place.

And here you can see how we can request, for example, the description property of a model, which is just simply description at the moment. Then we can go into Fusion 360 to modify that property. Let's change it to, for example, just simply new description. So we are inside the Properties panel, and just quickly change it to new description. Then of course, close the dialog, and then save to create new version.

And as soon as the new version is available, when we go back to the GraphQL API, and then execute the query again, straight away we have access to the latest version of those properties.

Internally we have a F API that interacts directly with the graph database where all the data is stored. However, the structure is a bit complex and you would need to understand all the relationships between the nodes in order to use that API.

So we decided to create a wrapper on top of that API using GraphQL and this can drastically reduce the number of requests you need to send to us. Instead of you having to call our REST endpoints multiple times, all those calls can be done internally by the GraphQL layer.

So what is this GraphQL technology that we are using? It is becoming a popular way to expose and let users query data in a nice structured way. Don't let the name mislead you. This technology is not specific to graph databases. Its name simply means that the data is made accessible through a graph-like query language.

The data could be coming from anywhere, from a REST API, some external structure, database, or anything else. It was created by Facebook back in 2012, and then they also publicly released it in 2015, so it's quite mature by now.

And so, many companies have been using it already, including the creator Facebook Meta of course, Twitter, PayPal Pinterest, and many others. And now, Autodesk is using it as well for the Fusion Data API, our first ever public GraphQL API.

Just like REST APIs, GraphQL as well provides broad access. In other words, the ability to create, read, update, and delete elements. In GraphQL, all read operations or queries, and everything else that modifies the data, the create, update, and delete operations, are all mutations.

Its website has a great documentation. Nice graphics to help explain the concepts, tutorials, support for lots of programming languages. And the banner just says it all. This technology enables you to describe the data you want to expose, let users make queries on that data, and provide them with exactly what they ask for.

They even provide very easy to follow tutorials to show you how you could expose your own data through GraphQL. For example, using JavaScript. Our JavaScript samples tend to use Node.js and Express, and they have a sample for that too. One great thing about the GraphQL component is that it also enables you to provide a very nice graphical user interface for users to play with and explore the data you expose through GraphQL. You will see that in a second.

We just need to open a folder, in our case, an empty one, where you want to create the sample project. Then, we can create a basic Node.js project using NPM init. Accepting all the options, apart from the name of the entry file of our project, where we use server.js to stay consistent with the GraphQL tutorial.

Yeah, once that's done, then we can follow the steps from the web page to add the necessary components. So we just run NPM install to install all the components. That will be added in the node modules folder. And then we can create the server.js file and fill it with the sample code from the website.

And save the changes, of course.

Once we are done with that, you can use node server.js in order to start the application.

And when you open up the application in the browser, then you will see the graphic UI. UI that I was talking to you about, where in the documentation Explorer panel, we can find a query we implemented, which is called Hello, that simply returns hello, world.

So let's go to the editor, and then quickly just type in the query that we created. As you can see, while we are typing intelligence helps us find what's available, and once we executed the query, we can see the result, which says hello, world.

We can make the sample a bit more interesting by providing data types, additional queries, and mutations that let us create and modify data. Let's say you wanted to use a database. The data could be coming from anywhere and SQL database or any other place. To keep things really simple, we just stored the data in a variable named users.

At the start we'll have two users, both with the name and ID, and people will be able to add to that. In order to expose the data from the users variable, we need to declare things in the schema. So we can define the user. They will have a name and ID. Provide a query that returns the list of users that we have in the database, and also a mutation that lets people add a new user.

And then in the root object, we will contain the implementation of all the queries and mutations that we declared in the schema. So you can see the user's query and also the create users, create user mutation. To keep things simple, the user ID will be generated based on how many users we currently have in the database.

After adding the changes mentioned on the previous two slides, we end up with this code. With the schema, with the list of users in the users variable, and then of course, the implementation inside the root object.

When we run the sample again, just like before, no server.js, and then we navigate in the browser to our application.

And then, you go to the documentation section, now post the newly added query for users will show up and also the mutation that we added there. So you can see we have under mutation, we have create user.

So let's quickly test what we have done so far. So we can simply run the query. As you can see, when we say users, then it's underlined in red, meaning we still have to provide the properties of the given query that we're interested in. So we can just simply go with name and ID of each user.

Once we edit that, then we can run the query and get back the two users that we have by default, John Doe and Jane Doe, with their IDs as well. Now let's test the mutation. So instead of that part, we are going to be creating the mutation. We only have a single mutation currently. That's the Create User.

Again, it's still underlined, then you get an error, because you need to add more information there. We need to provide an input parameter for the name, and so let's just go with, for example, Sarah Doe.

And we also have to specify what we want to get back. I could say, name but there's not much point to it because we are just providing the name right now. So instead, I'm asking for the ID, so we'll also get back the ID that was generated automatically for this newly added user. And there's also a nice button in the user interface called history, so we can go back to a previous query that we already ran and then use it again.

So as you can see, my query is back again, and of course, when I'm running it this time, then it will return three users, which will include the newly added user as well, called Sarah Doe and with the generated ID.

GraphQL enabled us to present the data in a way that's using the same terminology that Fusion 360 users are already familiar with. Exposing components, occurrences, versions, path number, description, and so on. You can see in this image how nicely the hierarchy information, provided by our GraphQL API, lines up with the structure shown in the model palette inside Fusion 360.

If you were to compare GraphQL to a REST API, then you find that GraphQL has the following benefits. A single query can retrieve results from multiple REST endpoints, which means less calls. You can also add multiple queries to a single API call, which also means less calls. And you will get that just the data that you are interested in, no unnecessary data that you would have to traverse to find what you need.

Now, let's see these points in detail. I'm going to use the Forge Data Management API for comparison. So as an example, if you wanted to get the names of all the projects you have access to using our REST APIs, you would have to first request the list of hubs you have access to, then for each hub, request the list of projects it contains.

As you can see in GraphQL, I can simply request all this in a single query. Asking for all the hubs, then names and IDs, and then for each hub, getting the name of each project they contain.

With REST, you have to send the request multiple times in order to get back results for multiple different items. In GraphQL, I can combine two completely separate queries, one looking for the hub named Fusion Data and requesting all the project names inside it, and the separate one looking for a hub named My Hub and requesting all the project names inside that as well.

We trust you will get back all the data that is exposed through a given REST endpoint, whether you want it or not. With GraphQL, you can specify what you are interested in, and only that will be returned.

In this example, you can see that we just want the names of the hubs we have access to, but instead in case of REST, we get loads of unnecessary data for each hub. Type of the hub, its schema, links, et cetera. With GraphQL, we get just what we ask for. The name of each hub, nothing else.

Currently only the eventing part, where we can create web hooks to get notified about milestone creation, supports all the CRUD operations, and we only have read only access to the rest of the objects. But we are planning to expose the ability to modify other data as well.

You'll find the documentation of the Fusion Data API at the link below, which provides you with a nice overview of the capabilities, tutorials, samples, and also a list of all the objects that are exposed.

The source code of the samples can be found inside this GitHub report. Since there is a single endpoint where you can send your GraphQL requests, therefore the samples are fairly similar, mainly the GraphQL queries are different.

One of the samples also has a live version that lets you log in using your Autodesk credentials and play with the Fusion Data API. It's using a library called GraphiQL, that makes it really easy to provide a very nice intuitive graphical user interface for your GraphQL APIs that lets your users interact with your API and quickly get familiar with all the data it exposes.

Many web services, including GitHub itself, are using this component to provide a kind of playground for their customers.

GraphQL lets you type in your queries, then run them and get back to the results. While typing your queries it also offers intellisense, listing the options available for you. And it also has a documentation explorer on the right, which will list all the possible queries and mutations you can use. As you may remember, in order to get back information, you need to run a query. If you want to modify something, then you need to use the mutation.

When you see the list of available queries, you'll also find, of course, the one we just used at the beginning, simply called hubs. That returns all the hubs that log in users has access to. But we could also start with other queries like projects, that returns a given project based on the hub and project ID, or item, which can return a specific file or folder, based on its ID.

As you keep clicking on the various types, you will quickly discover the whole object model exposed through the Fusion Data API, with all the various types available and the properties or fields they have.

Just to show you how you can play with the API in this online tool, first, you have to log in using your Autodesk ID, then can start doing various operations. The simplest is probably to ask for the list of hubs you have access to, then we can also use fear to reduce the amount of data in the response to just what we need, based on the name of the hub.

So first we are just running the simple hubs query, and then we are going to be filtering it down to something that we are actually interested in. So hubs has an option, you can put it in brackets, you can provide a filter. And it needs to be an object with one property. Go with name, and then we can just pass in the name of the project or hub that we interested in.

Now we can simply list all the projects inside the hub that we selected.

So here are all the projects. Now we are going to be filtering down to the specific project we're interested in. So we're just passing the name to the filter. Then we run it again. This time only the specific hub and projects are listed. And we can also ask for other properties, like for example, the root folder of the project and see what's inside those.

So the name of the root folder the will be the same actually as the name of the project, as you see right here. And now we can check the items, the contents of the root folder, and it's always going to be part of a results list. And just for fun, also we are requesting the type name for each of the objects, and this is how you can see that one of the items is actually a subfolder, or a folder, and all the others are Fusion objects, or components.

You can also specify the event type that you're interested in. So let's say you only want to get certain properties on a component. Then we can say dot, dot, dot on, and then specify the type in this case component. And then, we can write there what we're interested in. Let's say the tip version of the given component, and then also get back some properties for that tip version, like the item number.

We could also find out if any other components are being referenced by this component. So we can go to model occurrences, check the results for those, get the ID for each of them. So we can see that the steering wheel assembly for the FOFD test that has multiple occurrences being referenced by it. So those are all listed there. But the ID doesn't tell us much, right?

So instead we can also ask for the component version of what's being referenced and then list the name. So some of these components might be internal components. Some of them might be external components, which are also available in the root folder of the project.

So this is one way to find the hierarchy of a given model. And again, we can just ask for more properties for each of these component versions as well, if you want it to. The part description, part number.

Yeah, that's it. So you saw how we can get to data from files solely using the Fusion Data API. However, many people interested in this API already have applications using for example, the data management API and already know the UR and what the identifier of the files they are interested in. In that case, they can use different queries as a starting point.

So as an example, let's get the project ID and item ID of the Fusion 360 model using the tool like the Model Derivative API sample. You might be familiar with this already.

So this is using the data management API to list all the files I have access to. You can see the hubs projects, folders, and the rest. And then when I select the file and then in the developer console, I can check the URL of that item and that will contain both the project ID and the item ID of the given file.

So here you can see the URL, so projects/projectid. I'm just quickly starting up the Fusion Data explorer sample that you've seen already. But this time around, I'm going to be starting with a specific file.

So we just need to authorize the application to access our data. And now instead of doing the usual query, like going through the hubs and projects, we can start off straightaway with a specific item. And as you can see in this case, we have to provide the project ID and also the item ID. So we can take the project ID from this URL right there. And then the item ID, which is also part of that URL. I can just copy paste it from there.

And let's just check what we found, so we can ask for the name and also ID of the item. So this should be the box, exactly the box model that we have in our root folder. You can also ask for the type name. It should be design file.

Again, I can use the on operator in order to drill down to the specific type of object that I'm interested in. In this case, the design file, and then check the tip version, for example of the design file, and then check the root component version of that.

And once I get there, I have access to the usual information for the component version, like part description and part number. So I can just run the query again to get back that information. And again, you may remember we just changed the part description for new description. So of course, that's what's going to show up there as well in the query. And beyond that you could also ask for, for example, the thumbnail of the given component.

When I'm running this query, the image is not yet available. If you're familiar with Model Derivative API, it's a similar process. You have to ask for thumbnail. If it has not been generated already, then it might take a bit of time for it to be so. So best thing is to check the status of the thumbnail, but by the time I'm running this query again, the status is already success, and the URL of the thumbnail is already available. So I can just click on it and get the thumbnail.

Apart from the Fusion Data Explorer sample, you can also check out the other three samples showing specific workflows. Let's have a look at one that gets the thumbnail of a given model. As pointed out on the website, you have to make sure that the Forge app with credentials you are using has the correct callback URL.

You can just go to your app on the Forge website, forge.autodesk.com, and check it there. Log in with your Autodesk account, go to my apps, then select the app that you want to use, and then of course, make sure that the callback URL is as shown in the picture, which is HTTP, not HTTPS. And then local host, colon 3,000 so we will be running on the 3,000 port, and then forward slash callback and forward slash oauth.

All three samples have a similar structure. So the index js is the starting point where you have to provide your Forge apps client ID and client secret, plus the location of the model you want to work with. In other words, the name of the hub and project where the model resides, plus the name of the model itself.

Currently, the sample assumes that the model is inside the root folder of the project. However, it would be quite straightforward to modify the code in order to work with the model that is inside the subfolder of a project. And I'm going to show you that in a second. But this specific sample you see on the screen, that shows how you can get the thumbnail for a given Fusion model.

So you can just open up Fusion 360 or the Fusion Team website in order to find the name of the hub project and the model that you want to work with. In our case is L2 Forge data team, Adam, and then the box model that was already playing with before.

And then, update the values of the variables in the index.js file accordingly. So hub name, project name, and component name. And then the auth.js file is using the usual Forge authentication APIs that all Forge developers are already familiar with. In this case, we need to use a Three Legged authentication, because that's what the data management API requires when accessing models on Fusion Team.

And finally, app.js is the file that contains all the functionality related to the Fusion data API. You can see the single endpoint that you need to use to access all the GraphQL functionality. So the developer, the API, the total [INAUDIBLE] Fusion data, the specific version, and then forward slash GraphQL.

In order to get the thumbnail for our model, we just have to run this single query. So first we query for all the hubs and filter the result the hub with the given name we previously provided. Then the query for all the project, again filtering it for the specific one we're interested in. Then the query for all the files and components that are available in the root folder of that project and filter that for the one with the name we provided.

Since the thumbnail might not have been generated for the given component already, therefore we have to check its status. And then we have to keep sending this query to get an update of the thumbnail status. This process is similar to how you translate files using the modal Derivative API, or get properties out of an already translated model with it.

Once the status is a success, then we can use the provided URL to download the thumbnail. As pointed out in the pre-requisites of the samples, make sure that the node.js version on your system is at least 16 before trying to run the samples. You can simply run node-v in the terminal to check the node.js version currently being used on your system.

Before you can run the sample, you need to use NPM I in order to install all the required components in the node modules folder. Then use NPM start to run the sample.

So to recap the whole process, once you downloaded the sample, all you need to do is set the values of the highlighted variables in the index.js file, as you can see there. Then the run NPM I to get all the necessary libraries installed in the node modules folder.

You can see all the packages that were added, then can start the app using the NPM start command. And then, you'd have to open the given URL in the browser so that you can log in using your Autodesk account. So we just have to type in our account details, our email address, usual things.

Sometimes, it asks for the emails twice. Then of course, the password. And then we also have to approve the sign in requests.

So we got the access token. Once that's done, the program will continue execution, and send the GraphQL query to the Fusion Data API. And as soon as the thumbnail is available, its location will be printed to the console so that you can open it and here's the thumbnail of our model.

You can run the other two samples exactly the same way. One sample shows how you can get the full hierarchy of a given model, and the other shows how you can subscribe to the milestone created event in order to get notified when someone creates a new milestone version of your model.

If you wanted to modify the code, the easiest way to make sure that you are sending the query correctly is testing it in a utility like the Fusion Data Explorer that I've shown you before. So let's modify the sample code so that it will work with the model that is in a subfolder in this case called my subfolder.

We can simply copy paste the query into the Fusion Data Explorer's editor and also provide the query parameters. When typing those in as usual intellisense will help you here too, if needed. And the parameters that the query is using will be listed in a popup window that you can select from. And then you can just run the query to test the result.

In our case, all we need to do is filter for the name of the subfolder first, then look for the model or component inside that folder, instead of doing that directly in the root folder. So only these couple of lines need to be added to achieve what we want.

Since the name of the model is different as well, we need to modify that in the query variables window. Then we can run the query and see that it's working just fine. So we manage to change the code as we wanted it. So now it's time to copy paste to go back into our application. You can see that now it includes those extra lines of code we added.

And we also need to update the component name in the index.js file, of course. And since now the data will be one level deeper in the response, we have to modify the Get component version thumbnail functions code to get the data from the subfolder. I just had to add these three lines and also modify this line, so that we check the results in the subfolder instead of doing that directly on the root folder.

Now we can run the sample, just like before, by using NPM start. Then go into the browser to log in using our Autodesk account. We got the access token straight away. And by the time we're back, the sample already downloaded the thumbnail, and we can view it by clicking on the link. And there go. We have the sphere model's thumbnail.

And this sample that prints out the full hierarchy of the selected design can be run exactly the same way as the previous sample. The way we can get the component or design we want to work with is exactly the same in the query.

So we are just going through the hubs, projects, root folder, and check the items in there. But instead of checking the thumbnail, we are asking for the list of model occurrences that this model has. In other words, what other components are used in the design.

We also have another query that will check the model occurrences of the components that we got back from the previous query using the component version query.

We request the same info here, as in the previous query, the list of model occurrences with their ID and name, and we keep doing this until we discover the full hierarchy of the top model.

Here as well, we just have to make sure that we file the values of the relevant variables in the index.js file, run NPM I to add all the necessary components and packages, then we can run NPM start to start the application.

Then navigate to it in the browser, and then log in using our Autodesk account. But since we've already logged in before, it remembers that and we go back the access token straight away. And by the time we got back to the application's console window, we can see that the full hierarchy has been printed there.

You can also double check to make sure that this is exactly what you would expect. So we can simply go into Fusion 360, check the Components tab, and you will see that it's exactly the same hierarchy that we got back using the API.

As mentioned at the beginning, we always get up to date information without any delay. So let's for example, modify the components in our model. We are going to be adding another instance of the bolt that we have in the model.

So as you can see, currently we only have two bolt instances. Bolt one, bolt two. We can simply just copy it, and then paste it in the model. We don't really care where it's placed. We only care about the hierarchy or the structure of the model. Just to test it, that it's all correct in the API. So we're going to be saving this. In order to generate the new version for the model.

And you can go back to the sample that you just ran before and run it again to get the up to date information about the hierarchy of the model that we're working with. So again just navigate to the application and the browser, login using our Autodesk account, and by the time we get back here, well almost, we have to wait just a bit.

But you can see there's a hierarchy and now, we have three instances of the bolt. So all seems to be good. It all seems to be good.

The last sample is a bit more complicated to run because it requires that you handle callbacks coming from the fourth server, and in case of testing on a local computer that's not exposed to the internet, we need a tool that will pass on the message to our computer. So the two extra things needed in the sample are handling the callback coming from the fourth server and using a tool like and ngrok that we pass messages to our computer.

The Fusion that the API provides and the venting system, which is basically like web hooks, but the system is separate from the Forge web hooks that you may be familiar with already. Currently, it only supports the milestone created event. As the name suggests, this allows you to get notified when a new version of a model is saved as a milestone in Fusion 360.

In this sample as well, the queries are in the app.js file. The main one in case of the sample is how we create the webhook using a mutation. You just have to specify the ID of the component that we want to monitor and then of course, the callback URL that our app is expecting to get the notifications on.

As usual, first we have to make sure that the values of the relevant variables in the index.js file are correct, then we also have to start ngrok so that we can receive the webhook callback. On this system, it's already installed in the applications folder, so I can run it from there.

And we can simply copy paste the URL it generated for us and use that for the ngrok URL variable. So we just replace that there. We have to install all the necessary components. So we're going to be running and NPM I.

And once that's done, we can start the application. So we're going to the browser, navigating to our application.

And once that's done, the application registered the webhook for us and printed a message about that in the terminal. To test things we can just go in Fusion 360, open the model we are monitoring it, make some changes in it, and see if the new version as a milestone.

So we can just simply open up the model and probably one of the easiest modifications to do is just select one of the faces, and then do a push pull or press pull modification on it. So we are just going to be changing the height of this object. Click OK, save the changes. Make sure we select milestone, because that's what we are monitoring.

So that's been done now. We just have to wait for this modification to show up in our program. And here it is. We received a notification successfully. And you can see that information, including the name of the milestone, event type, and some other information like component ID, which might be relevant.

You also have a great sample utility web app available online that you can log into and start testing the API with. It's using the same GraphiQL component as the first sample I showed, but has many other features as well. On the left side, it provides a tree control that lets you access any of the models that you have access to, and this app as well is using the Fusion Data API under the hood to populate the tree control.

Apart from being able to run any GraphQL queries you want, it also suggests queries for you, depending on what object you select in the tree control. So for example, if you select the hub, then it shows you how you could query for all the projects in it and the contents of the root folder of those projects.

If you select the project, then it shows you how you could query for the contents of the root folder of that project. If you select a model, then it shows you how you could query the component version of the model, get properties, like path number and description. And also get a list of the other components this model is referencing and the properties of those components as well.

You can of course run all these queries by clicking on the play button in the user interface, and get the results back in the panel on the right side.

It also has a tap code demo app that shows the hierarchy inside the selected model using a graph visualization library. You can simply double click on a node, and if it has a subcomponent, those will appear and you can drag them around. It's a bit like herding cats. The nodes keep trying to escape.

So we can just discover the full hierarchy or object model of the design that we are working with.

If you wanted to start from scratch, then you could either select the file again in the tree control on the left side or in fact as I found out, if you just double click the root component, the same thing will happen.

Yeah. So we are back to square one, have to touch those components again.

And if you're paying attention, you can see that in the tree control, where all the files in the root folder of the project are listed, some of these names will be familiar because some of these are actually external references inside the design. So those will also show up in the root folder of the project.

So I'm checking which ones are there. The bolts are not. Those are internal components. Those are not external files. Steering wheel form, that's not either. As you can see, it's not part of the root folder. But for example, if you check the center bracket modified, that does show up in the root folder, or the base modifier. That's also an external component, which also has some internal components as well.

So this is a really fun way to investigate the hierarchy of the models that you're working with inside Fusion.

There is another tab, which will use the well-known Forge Viewer to display the selected model. You're probably familiar with the Forge Viewer already, with the various functionalities which are available to you, including sectioning, measuring, and all those things.

Then there is the component table tab, which shows the same hierarchy that was presented on the demo app tab as a graph. But this time organized into table, and also including component properties and thumbnails, basically providing [INAUDIBLE] information for the model.

And last but not least, there is the query history tab that not only lists the queries that you ran in the Query Editor, but those as well that the app used to populate. For example, the tree control, the username and icon, and the Forge Viewer. It might be quite useful to have a look at those as well, to see what API requests the app is making in the background.

All the samples you've seen were using node.js. If you prefer .net, actually created one following the steps in the tutorial, where you can find in the online documentation. So it's following the exact same steps outlined in the tutorial, going through picking a hub first, picking a project to work with, picking a component, generating the thumbnail, and then of course, downloading the thumbnail as well.

So here as well, first of all, you have to fill in the credentials and make sure that you use the correct callback URL, which is the same like in all the other samples. And then when you run the app, then the browser should pop up where you can log in with your Autodesk account. You just have to wait for it a bit until it gets started.

So we need to provide the email, password of course, and also approve access to our data on Fusion Team. So signing in.

And as soon as we go the access token, of course the application continues running. And it goes through each step, just like as I said in the online tutorial. So first of all, we are going to back order. Get back all the hubs that we have access to.

So those are listed in the console, and what we have to do now is select the ID of the specific hub that we are interested in. So I'm just going to be going with the usual hub like I used before. The L2 Forge data team, so I just need the ID from there. And then I have to go into the get all project's function and then paste it in there. And make sure you save the changes. And then we can restart the application.

So this is the way the sample works. Each time, you're going to get an error until you fill in all the necessary information in order to get back the thumbnail that you were interested in.

So now that you selected the hub, it's going to be listing all the projects available inside that hub. Unfortunately, each time we have to go through the login process. So that takes a bit of time. It's just asking for the usual credentials.

So this time around, it should successfully execute two of the steps out of the five of the tutorial. So now it's going to be listing the hubs and also the projects inside the specific hub. So you can see all those should be available inside the console, and this time around we need to select the project ID that we want to use, and go to the get components and also select the ID of the root folder of the given project.

So we are copy pasting that as well. Again, save everything. And then we can restart the application.

So now, three steps should successfully execute. Getting list of hubs, getting the projects inside the hub, and now getting also the contents of the root folder of the given project.

So once we go through the usual login process, then the application should continue.

Yep, so now we should have the list of components available in the root folder as well. We're going to be going with the box model that we already use before. So we just need the ID of that model. Place it right there in the generate thumbnails function, or the generate thumbnail function.

As you can see, we'll also need the project ID, but that's something we already used in the previous function. So we can just simply copy paste it from there. We go to the get components function, and copy paste the project ID from there into the generate thumbnail function. Again save all the changes, and then we can restart the application.