Accelerate Digital Transformation Using Upchain APIs

SANJIN VUCKOVIC: Welcome, everyone. Welcome to my presentation, "Accelerated Digital Transformation using Upchain APIs." My name is Sanjin Vuckovic, and I'm a software developer engineer in Autodesk. I've been working on Upchain for the pass five years, and two years ago, Autodesk acquired us. So now, I'm part of Autodesk.

So today, I will talk a bit generally about Upchain and Upchain APIs, and then I will jump straight into using our APIs. I will show you some examples of how to create, fetch, and update BOM or Bill of Material data, and then I will give a brief overview of some other endpoints that we provide projects, like BMS projects, change requests, and some others.

So as I hope most of you already know, Upchain is a cloud-based PLM and PDM solution. Some of its main features are multi-cloud integration and centralized data. Since all data is stored in the cloud, it provides easy and efficient way to collaborate between different users and stakeholders. But I'm not going to talk too much about Upchain in general. If you're more interested in that, you can check presentations from the previous video. I've mentioned two of them here-- Kick-start your Upchain Experience and Cloud Data Management with Upchain. But there were some other presentations, and there are also Upchain content on this year's AU.

But what I would like to talk about more is Upchain APIs. So different companies have different needs and requirements, and Upchain offers out-of-the-box solution with a web application and plugins to meet those problems. However, sometimes these solutions are not enough, and some custom functionality is needed. And this is where APIs come into play.

Upchain offers a wide array of API endpoints that enable different use cases and provide customers with the flexibility to create custom solutions for their own needs. Some of the most common use cases are importing data from other systems into Upchain, and also exporting data for various reports, dashboards, and similar purposes. APIs can also be used to create different automations to reduce manual work, improve efficiency, and accelerate the digital transformation.

For example, many companies use different tools and systems to store similar data, so using APIs to automatically synchronize data between the systems can be a very efficient way to solve those problems. However, APIs can be used for a lot of other use cases, and once you start digging into Upchain APIs and see what's available, I'm sure you will find a lot of other use cases where you can use them.

So if you want to start with Upchain APIs, first stop would be the Swagger documentation page. Swagger is an open-source tool that displays API documentation. Our API conforms to the Open API specification. I will show you a bit later why that's important.

And on the Swagger tool, we can see all the endpoints with the descriptions, and examples, and data schemas, and stuff like that. But instead of me just talking about it, I would like to quickly show you about the Swagger tool.

So here is the Swagger. At the start, we see some general instructions about logging in and sending some required headers. And then, below, we have a lot of different sections that contain a lot of APIs. So when you scroll down, you will see many different endpoints and sections that you might want to use.

So if I open any of them, I will see now exact endpoints in here. And can open one to show you how it looks like. So here we have the name of the endpoint and the URL. Here is some description of the endpoint. Below are the parameters that we need to send to call this endpoint. So there are some required parameters, some optional parameters, and also descriptions for all the values that can be sent.

And if I scroll a bit down, we can also see examples of the responses that API returns. So here we see an example value of this endpoint, but we also have this schema button. If I click on it, it will show you all possible fields that this endpoint will return, and also its data type. So if you are implementing your own integration, it will be very important for you to see which data types you will get.

And this applies to all other endpoints that we have. So I've previously mentioned that we use OpenAPI specifications. So here is this link called API Docs. I can open it quickly, and it is one giant JSON file.

I'm not going through that right now, but I wanted to show you this because you can Google Open API Code Generators, and it will give you a bunch of different generators for all the programming languages that you might use. So if you are starting for the first time with our APIs, probably the easiest way would be to just copy this link into Code Generator, and it will generate all the code. And there will be examples how you can start using our APIs, so you will not need to manually import everything and it will be generated for you.

So that's our Swagger page. And before I start using our endpoints, I would quickly like to talk a bit about our terminology that we use because there are some inconsistencies in our system. So I would just like to tell you about some of the terminology so it's easier for you to understand what's happening.

So first thing, you might on some places see "company." On some other places, you might see "tenant," and "company IDs," and "tenant IDs," and that's the same thing. That also applies to parts and items. So you can see part versions, item versions-- parts, items, that's completely the same thing. And you will see a lot of those inconsistencies.

And then, a little bit about our data model. So the building block option is an item, and for items, we have item masters and item versions-- or part masters and part versions. So if we create one item, we might give it a unique item number. In this example, I'll use 1000123. That's item number that uniquely identifies our item and it is stored on Item Master.

And then, for this Item Master, we can have multiple different versions. So one can be in development. Other can be in released. Then, we can have another development, and so on. They can all have different revisions, but they all share the same item number, so they have one item master. And then, there are multiple item versions. So items belong to the eBoM or Engineering Bill Of Materials.

Very similar thing is with files. With files, we have file masters and file versions. So when we import some file into Upchain, that file will have some name which we use to uniquely identify it. And then, we can check out, check in, and create different versions of that item. And then we will get version 1, 2, 3, 4, and everything else. So File Master is the one object that stores file name, and then it can have multiple versions. And files and file versions are all part of the cBoM, or CAD Bill Of Material.

And at the end, I would also like to mention about CAD data and DMS. So everything I've talked until now-- items, and item versions, and files, and file versions-- that is all part of the CAD data. So that's all the data that you create in your CAD tools-- in your Inventor, SolidWorks, AutoCAD, CATIA, and everything else. Those are the models, drawings, translations, and any other files.

And then, we also have a DMS, or Document Management System. This is a general document management system where we can store any other type of documents. So here, you would put your different office documents, your PowerPoint presentations, your Excel sheets, or ZIP files, or some images, or any other file that you might use and you might want to attach to different items, or projects, or other places in Upchain.

So that would be it for the introduction into Upchain. And now, I would like to start with the demo. I could use the Swagger page, which is often the easiest and fastest way, but I will use a tool called Postman. But for now, if you want to use Swagger, I will show you how to quickly get started.

So on the right side, we have Authorize button. We can click on it, and then we need to Insert client ID and secret. These are the values that you can get from the Upchain Customer Support.

I have my Academy. It's called Academy ID, I have some secret. I click on Authorize, and now it will check if I'm logged in into Option. I am logged in since I'm in the second tab, so it immediately authorizes me. And now, I can use my APIs.

So I can open any of them. We have this Try It Out button, and now I execute it. And that's it-- I executed my endpoint and got the result back. And Swagger tool took care of everything.

So we can see that it sent the header, accept application JSON. It also sent authorization header. So whenever we call some endpoint, we need to send this authorization header, and Swagger tools takes care of that.

But since there is so many endpoints and so many different sections, it would be a bit confusing for me too to use Swagger because I would have to do a lot of scrolling up and down. So instead, I will use the Postman tool.

I hope that most of you are also familiar with this. Postman is an easy-to-use API client. I have created a folder called AU 2023, and I have created several sub-folders. And I will be executing endpoints here. So if I expand any of them, it will show me a list of endpoints. And then, I can click through them and execute them.

First thing here when we want to start executing endpoints is, of course, to log in-- or, if we are using our APIs, we need to fetch our API token. For this we have a Fetch Token Endpoint. It takes several parameters that we need to send.

So currently, we are using the Keycloak system, and it works on the OAuth protocol. So for the grant type, if we want to use APIs we will send a password value, but allowed protocol enables some different grant types which you can also use. But in this case, I will use password, client ID, and secret I already mentioned. So you get from the Upchain customer support, and then you also need to insert username and password. And those are the credentials of your Upchain user.

When you will be using API endpoints, I would suggest to use Upchain user that has tenant admin role because some of the endpoints are restricted to tenant admin users. So if you use tenant admin, then you will not meet those restrictions. So it's better to use that user. And then, we also need to send some scope read/write, since we want to read and write data.

And now, on the right side, I can click the Send button. It will send the request to the Upchain, and we will see below the response. Most important thing in this response is our access token. So if I want to do everything manually, I can copy this whole token and then paste it in every other endpoint that I will use. However, since I'm using the Postman tool, it enables me a bit easier way to do that.

So I have this small script in tests, and it extracts-- it reads this response, and extracts access token and stores it into token variable. And then, in the Postman, you can have different variables which you can then use on some other places. So here, if I go to my Global Variables, I have several variables that I have used, like my URLs-- or actually, they are here in the live, sorry.

So they are here. So I have my that URL to my API, then I have my username and password, which are not shown because they are secret-- Client ID, client secret, company ID, and also token, which are extracted from my previous endpoint. But now, also, one nice thing about Postman is, since I have parent folder that contains multiple other endpoints, I can click on the parent folder. And in the Authorization tab, I can select a bearer token. And here I put my token variable that I extracted from before. And now, when I execute any of the endpoints that are in this folder, it will automatically send this bearer token so I don't need to send it manually on each call.

So yeah, that would be the basic setup. And now, let's start executing the endpoints. So for most of the endpoints, apart from token, we also need to send our company ID. It's not necessary in this place since this endpoint will actually give you the company IDs so I can execute this. And we'll see here that I have access to only one company and its ID, 203.

I think most of the users in Neptune have access to at least two tenants or companies, like one sandbox and one production tenant. So if you are starting to use API endpoints and starting to get familiar with Upchain, I would suggest to first try them out at your sandbox tenant because then you will not mess with your production data. So now that I have my ID, I stored it in my variable called Company ID 203. And now, when I want to execute some other endpoint, I go to headers, and I just put UPC selected company and my variable, and it will automatically to send the variables I defined. I don't need to manually put it here. Also, for each endpoint, we need to send content type is application JSON.

OK, so let's get started with using our endpoint. So as I mentioned, items are the main building block in Upchain that you will be mostly using, so let's create one item. Here on the left side, I have put this example of calling this endpoint where it will give you-- in the Body tab, it will give you all possible values that you can send. You can also see everything from here in the Swagger, but I have put it here, so it might be easier. If you will be using Postman, you can also see it here.

So let's say I want to create my first item. I can put my first name. So it will be, let's say, AU2023 item. Nothing special.

We put some description. We need to put its state. State has a limited number of values that you can use. It also applies to the type. And if you don't know from the top of your head which values to use, you can always check the documentation.

So this is where it's good to check the Swagger page. So I can see here that my endpoint is in the BoM version 2 section slash items. So if I go to Swagger, find my BoM version 2, and now I can find my item endpoint-- here it is. And now, I can see also here all the values that can send. But here, I can click on schema, and it will mark me which parameters are required-- these with the small red asterisk.

And now, I wanted to send the state and type. So for the state, I can expand this enum, and it will show me all the values that I can send. Now, I can use just Development item, but I can use any other.

And then, for the type, it doesn't have some fixed values. Values are fetched from the item type picklist. So if I want to check what is in the picklist, I can execute the endpoint and see.

I'll go back to the Postman. I also have here the picklist endpoint. I just need to send it as query parameter, a picklist name. In this case, I want item type. So if I write item type, and I execute, and now, I will see all the item types that have defined in my tenant. And I can pick any of them to use for my item that I will be creating. So in this case, I will create an assembly in development state.

Now, I can also define major/,minor revision and version. And one thing I could mention here is that if we have some fixed item numbers that we want to use, I can specify here item number as well. But if I don't have some fixed one and I want option to generate it, I can just leave it blank. I don't send anything, and option will generate an item number based on the item numbering rule that I have on my tenant.

So in this case, I will not send the item number. I will let option generate it for itself. So that will be all, and I can execute it. And now I get my response, and now we can see that it generated item number 100945.

Now, in this response, once you first start to use it, it might be a bit confusing because there are two properties you have-- this one initial ID, and then you have also versions ID. So this first ID is actually part master ID, and I don't think you need to use it at all-- maybe on few endpoints. But in most of the cases, you will be using this part version ID, so this one is way more important. And for example, here, you can also see master ID, which is the same as this one.

So OK, we have created our first item, but we cannot really see it anywhere in the application. I mean, we could find it with our search, but it would be a lot easier if we could see it on some projects. So let's link our item to the project.

For that, we have an endpoint called End Items. In the URL, I need to provide it with the project ID. So when I put this colon here, it will create it like a path variable here in the Postman, and I need to get project ID. Of course, I don't know what my project ID is from top of my head, but that's why we have another endpoint called Projects.

And I can filter all my projects by status. In here, I will want only active projects. I can send it, and since my tenant has a lot of projects, it might be a bit harder to find the one I need. I can use this Search, and then Search by Name.

But also, one easy trick you can use to find your project ID could be also to go into the option application and open the project that you want. So I have added it to my favorites. I have this AU 2023 Recording. I can double-click on it, and I can open this project.

And now, in the URL, I will see this project equals something. So this is actually the project ID that I can use in my endpoints. So I can use it here, or, for example, I can search for it here, and it will find the same thing in my endpoint. And if I go back to the Link Item to Project, so this is project ID. And in the body, I need to give it item version ID, or part version ID.

So it's the one that I have created. So it's this one. I can copy it, paste it here, hit Send, and now it will say the response is HTTP 204, which means it was successful. So once I go back to the Upchain and have added to this project, I can go did my BoM page, and here is the item I have just created.

So we have our first item, but it is completely empty. It doesn't have anything attached. So let's add some files to it as well.

I will go back to Postman, and we have an end point to upload CAD file. It's called BoM version 1 file version. So this is very powerful endpoint, which can be used to upload any kind of CAD file into the system.

So since I'm creating from scratch, first, maybe, I want to create a CAD model. So in the body, I need to send two parameters-- file, and metadata. So for the file, its type is file, and I need to select from my disk which file I'll upload.

So I have some small parts that I have created in Inventor, so I will open that one. And then, in the metadata, I need to give it file name and Vault ID. And there are some other parameters which I will mention a bit later.

So even though my file itself is called smallparts.itt, this file name does not matter that much. It's the name that Upchain will use is this filename parameter that you will send in metadata. So it's more important what you send here. So here, I can put AU Sample Item, let's say.

And then, I also need to give it the Vault ID. So this is-- Vault is a storage where we store our files. It's not related to Autodesk Vault; it's Upchain Vault. It's like simple data storage.

So I want to get its ID. So again, I have another endpoint for that. It's called Get Vault IDs. It's in the Vault section. So it's a GET request.

So I just hit Send, and it will give me some details about it. And most important is this ID. I will copy it, and I will paste it to my request, and that's it. I send it, and yeah, now, it will create me. As I've mentioned before, it will create file master and file version. So if I would hit Send again, it would create another version. It would create version 2, which would have the same file master but different file version since each version has its own ID.

So we have created a new file, and now we want to link it to our item that I have previously created. So I will call the Link File to Item Endpoint. In this endpoint, I also need to send item version ID in the PATH variable. So I need to, again, go back to my item, copy it, paste it here.

And in the body, I need to send my file version. You can send multiple file versions here. And I'll talk a bit about this primary.

Let me just copy the file version ID. It's the one that I have just created. Copy it here, paste here.

So now, about this primary flag, since now I am attaching a CAD model to my item, I want to mark it as Primary TRUE, as there can be only one primary file on each item. And later on, I will also upload a drawing. And for drawing, I will set this Primary FALSE. Also, you can attach translations, and translations will also have Primary value FALSE.

But since this is CAD model, it is the primary file, and I will execute it once again. It will say 204 No Content, which means that it is created. And if I refresh my project and check the item, now I have this icon that item has model attached.

Now, I can see, in the documents, the save on page. I can see it, I can download it, and so on. So now that I have CAD model attached, I want also to have some thumbnails and to create translations for it.

I could do it manually. I could do the importing of translations manually, not the thumbnails for now. But since we have the file uploaded, we also have an endpoint for generating those translations. So I will use it. Also, as a pet variable, I need to send item version ID.

So I will copy it, add it, and then, as a query parameters, we can send which translations we want to create. And the options are PNG, SDL, and STEP files. So this endpoint right now only allows you to create translations for model files.

So if you have some drawing and you want to create PDF translation, this endpoint does not support it. And we also have this Force parameter. So if we already have some translations existing, we can send this Force value to TRUE, and it will overwrite all existing translations.

But right now, I don't have anything, so it doesn't matter really what I send. So I can send just send the Force TRUE. I can trigger it, and I will get responses 202 accepted. That means that the process of generating translations have started, and it usually is very fast, and maybe we'll immediately see it. Sometimes, if the system is under some bigger load, it might take some time.

So yeah, right here, we see that conversions are in progress. And thumbnail is not visible right now. Maybe if I check again? OK, the most important thing is that I have triggered it, and now it's running in the background and it will be generated. And also, we have this icon that translations are attached to.

Let me see-- yeah, OK, it's still running. While that's running, I can also show you how to attach drawings, because drawings are also one of the most common items, files you will attach to items. So if I go back to my Upload CAD File, I forgot to mention previously that you can expand it.

And I have put different examples that you might use. First example is for all parameters that you can send in the body. So you send some file, but in metadata, you can send some different information.

And since I will be creating drawing, we can see here, for drawings, we can also submit file name, Vault ID, and CAD type. We need to send in some places. I will tell you exactly where.

So yeah, let's say I want to create now my drawing. So instead of the IPT file, which is model, I will import some drawing. I have a DWG drawing. For the file name, I will use auDrawing.dwg. And Vault ID I can reuse.

And now, you will see if I try to call this, I will get an error. It's because DWG files are a bit special because they can be everything. They can be models, they can be drawings, they can be translations, and only based on the DWG file extension, we cannot know what exactly it is.

And now, since we know that it's a drawing, and it says that we need to specify CAD type where it's created from, so if I go to my example, I see that I can send this CAD type parameter. So I will just copy it.

And since this was Inventor file, I will put Inventor. And since, in Inventor, DWG file can only be a drawing, Upchain will recognize it and mark this file as a drawing. So I can execute it. I get the back some information that it's created successfully. And now, same with the model, I need to attach it to my item so I can immediately copy my file version, go to the linking endpoint, and now, as I've mentioned before, instead of sending primary TRUE, I need to send primary FALSE.

So now I have executed it, and I can go back to the web page. I refresh it-- yeah, now we can see the thumbnail and translations are generated, and now we can also see the drawings are here. So if I go to the cBoM, I can see model. For drawings, I can see, we have our drawing. And for translations, there are translations.

However for drawings, drawings have their own cBoM as well. So when we are attaching a drawing which is related to the model file, we also need to create a cBoM relationship between drawing and the model. So I'll show you how to do that.

So for this purpose, we have the Create cBoM Relationship endpoint. It's in the version 2 of our endpoints. And in the PATH variable, we need to send parent file version ID. Parent is our drawing file, so drawings are parents, and CAD models are childs, in this case.

So parent is drawing, and then I need to get also my model file. So here I can use this console tab in Postman, which will show me all the previous endpoints that I have executed. And I can find the first one. This File Versions is the first one which I called to create my file. And in response, I can copy this ID.

I need to put it in the body here. I can leave quantity as 1. I can execute it. And now, I have created a relationship between drawing and model.

So if I again go back to our application, open the Drawings tab, and now, as we wanted to do, now we have our drawing, and we can see that it has a model file as its child. Here I should also mention that since this drawing file is created in Inventor, this Inventor file itself has a file reference to its child. And we need to make sure to use the same file names as how the files are defined in the Inventor because if you upload the file in Upchain and you rename it, Upchain will not open those files and do some re-referencing or anything like that. So you need to make sure that you use the same names as they are in Inventor because if you don't, and you change the name when you import into Upchain, and if you download the drawing, then you might get a Missing Reference error because you have renamed the file some other way, and then Inventor cannot find it.

So that would be about drawings. I can use the same endpoint to create the translations. I can share this example, for example, here, which you need to send file category translation. But since I've already created some translations for model, I don't need to do it right now.

And for the part with creating BoM data, I want to show you only one more endpoint, which is to create eBoM relationships. So right now, we have created our cBoM relationship, a connection between drawing and model. But now, let's say that we want to create another item, and we want to create some-- and it will be the child of the first item.

So I can create, let's say, a AU 2023 child item, and I will leave everything else the same. Because I'm not sending item number, it will generate me a completely new one. So this is my child item, and I can copy its part version ID and put it in the body.

For the parent, I send it in the pet variable parent. You also have one easy trick to fetch the parent. So if you open Item, you open its details, in the URL, you will also see the Preview item, which is the part version ID of the item that you have clicked on.

So I can easily just copy it, paste it here, and that's it. For this endpoint, I need to get my Creator ID, which is my User ID, and I have another get endpoint to fetch it. So I just send it, copy my ID, paste it, and execute it, and that's it.

So this will create an eBoM relationship. Since this will be a child of my other item, I don't need to attach it to the project because to the project, we attach only the so-called end items. Those the end items are actually root items on the project, and for any child item-- or we have here some other children as well-- for all of those you don't need to attach them to the project, it's enough to attach them-- or to only connect them in the eBoM to the parent. So here it is.

So that's some basic about creating all your BoM data. I have created only one file, or one, two items and some files. And now, if you would want to create some bigger assemblies, you would do the same steps again-- just, of course, with different data. And that's the way how you can import data into Upchain.

Now that we have some data imported, let's also try to fetch data to see what we have in the Upchain because you might want to export data, as I mentioned, for some reporting dashboards or whatever else you might use it for. So there is a lot of endpoints for that. Some of them are very similar, and you are feel free to try out different endpoints and see which ones you want to use.

For example, we have this Quick Search. It works similarly like Quick Search in application. We put all description here. Also, you can see it on the Swagger as well. You can search by item name, item number, legacy item number, and so on.

So I can-- for example, I have created this item with this item number. I can copy it, paste it here. So it will give me this specific item.

So I can remove only the last character. So it will-- going to show me all items that start with this item number. So since I created like two items, it will show me now some different. And previously, I also have some other items created, so it will give me all the items that start with this item number.

Now that I have created some items I can also fetch them by part version ID or by part number. It's whatever you want to do. Fetching by ID will give you only one item with the specific ID, but part number might return you multiple items if you have them-- like multiple versions of that same item number. If I execute it, yeah, it will give me some data. It returns a bit more data than the search endpoint, so you might want to use this one if you need some additional data.

So apart from just finding items, we can see which files are attached to items. So we have three different endpoints for that. One is for fetching model, one is for fetching drawings, and one is for translations. So whatever it is you're interested in and what you require, you can execute any of them. I mean, there is no need for me to execute, and right now, they are very simple. Only GET requests, and you need to put some IDs-- for example, these drawings.

In the body, you can send multiple item version IDs, and then it will fetch your drawings for all of them. And then, I can show you also how to fetch different assemblies and different data that exists on your project. So this endpoint is called Project/End Items. So it will give me only end items, which are like the root items that are on my project. So I can get my project ID here.

And you can see here that we have three end items, and this endpoint will also give me those three. And I can send different filters, within the same thing we can use in the application itself. So here we have our three end items.

Now that we have them, we can fetch their children as well. And there are different endpoints for that. These two endpoints are very similar. This is called item children. This is item children extended. It will give you a bit more information than the first one, but it works well very similarly. And it will return only the first-level children.

So if you have some large assemblies, and maybe you want to load it level by level, then you would use these endpoints. However, there are some endpoints to fetch a whole assembly tree. Of course, they might be a bit slow if you have some huge assemblies. But for assemblies that are not too big, we can use them, and it will give us immediately in one call all the details about the whole eBoM.

So I can use it, for example, I have imported one example assembly called Car Seat. I can click on the top one, and in the URL, it will give me the part version ID, which I can copy and use it in my endpoint. And that's it.

So this one might not be the prettiest of our endpoints that we have because, as you can see, when it returns data, some of the data is like a JSON string. So you might need to do some additional processing to extract data out of it. But I wanted to show this because this endpoint will give you, probably, the most information about all items in the eBoM.

So it will give you part version information. It will also give you file version information. It will give you all files-- so all drawings, models, and translations that are attached to this item. And it will also do for all the children and children of children. And for the whole assembly, it will give you all the data. So yeah, if you need one endpoint to fetch all the data, this might be the one to use.

We have this one, it's also for fetching eBoM 3, but this one is also interesting because in this one, you can send it only the data that you want to get back. So in the body, you send attribute list, and you send exact fields that you want to get back, and you can also specify the names. And that's how the response will look like-- it will contain these two fields. So if you want to know which all names you can send, I have created this example called All Parameters, and you can see all the values that you can send.

So you can send-- apart from part version, which is item data, you can also send part part, which are eBoM attributes. There are also manufacturer, which are details about manufacturer, and also custom attributes. So if you have multiple custom attributes, you can put it here-- like custom.name-- and then it will give you all the custom attributes as well.

Next, we have the reverse eBoM. So it's similar to this one, but it works in reverse. So you might want to give it some part that is somewhere deeper in the assembly, and then it will return all the data-- all its parents, and parents of parents, and all up the tree until the project.

Then, also, we have endpoints for fetching file data. Similar with items, we have fetching files by name or by file version ID. And the similar thing is with fetching cBoM. So you can fetch your cBoM by file version ID in this endpoint, or by part version with this other endpoint. So you are free to investigate them, and to try them out and see what works best for you and which information you need from them.

Yeah, OK, maybe tell a bit about this one, fetching cBoM by file, because it has this parameter called Style. And you can say different values. It has full, compact, and reduced.

So if you're interested only about some basic data, you can send this compact value. I can maybe show you in my eBoM 3. It's this one I have executed.

So I can find my file version. If I can find it here, this is the file version ID. Yeah, this is the model file. I can copy it, paste it here.

So since I used Full, it will give me a lot of data about items. But can also use Compact, and it will give me only some basic information. Yeah, it looks like I picked-- I didn't take the root file. I picked some smaller leaf items. So it doesn't have any children, but if it had children, it would return all the children as well.

So that will be pretty much it about fetching eBoM data. These are the endpoints I've prepared, but there are also some other endpoints. So you can examine our Swagger page and see what else is there, and you can try them out.

So I would also quickly like to show you about updating BoM data. We don't have too much end points for updates. For example, for files, we can update only CAD attributes. And these attributes are shown here.

If I go to the CAD Attributes, these are the attributes that you can either import new ones or update existing ones. So once we import the Inventor file using our CAD plugins, it will read all those files from the Inventor file itself and store them here. And now, we can manually update or add some new ones.

But that's not too important right now because those attributes are not updated that often. But I would like to show you more about updating part version, or item. This one is a lot more updated. So for it, I also need to specify which attributes to update and also give part version ID.

So let me just grab, for example, for this one, this parent one. I will get the ID, and for the attributes that I want to update, I can update both the item attributes, different ones, and the custom attributes-- or, basically, all the attributes that we can see here, these common and custom ones, they can all be updated via the API. I have also prepared this all-parameters example, which will show you the names that you can send of all the parameters that you want to send so you know which ones to send.

So in here, I will send some description, updated description, from API-- not that important. And then, for the custom attributes, it depends which attributes you have defined on your tenant. And you can find them with the Get Item Attributes endpoint. I can quickly execute it, and it will give me both the common and custom attributes.

So if I am interested only in custom ones-- and you can only send custom ones in this endpoint-- so I need to find the custom ones. So I can use the search. But instead of if isCommon true, I will say isCommon false. And now, I see that there are 19 attributes, and I can see them.

So I'll pick the first one. Its name is color, so I copy the name. I mean, I have already here. So paste it, put color-- let's say it's blue. And I execute it.

It's successful. And if I go back to the web, update it, so here, we have our description is updated from API. And if I scroll down, color is blue. So we can update all those attributes via the API.

So those are some of the most important endpoints for manipulating and creating and fetching BoM data. And now, I will quickly go through some other inputs that we have. Since we don't have a lot of time, I will quickly go through them.

So for the DMS, we can use the Find DMS 3, which will give us all the DMS documents. So for example, we have the DMS data on various objects in Upchain. For example, if I open this item and I go to the documents, this section here about the documents-- this upper one-- it is the DMS part for this item. But then, this item has its different DMS.