The PLM 360 API, like most REST API’s, have a version component to their URLs. However, the meaning of the version changes from system to system. So let me explain what that version means for the PLM 360 API.
The API version is the part you see in the URL for a REST call. So if you are getting a list of workspaces from https://mytenant.autodeskplm360.net/api/v2/workspaces/, 2 is the API version number. In PLM 360, this number identifies a compatible API set. In other words, v2 will maintain compatibility as new releases of PLM come out. Things may be added to REST v2, but existing content will still work the same as before.
At some point in the future, there will be a v3 API, which will probably not be compatible with v2. When new API versions are introduced, they will live side-by-side with existing API versions. This gives developers ample time to move their code to the latest API version. Here is a rough diagram of what I’m talking about.
There is no set time for any of this. The v3 API may come out in a year, two years, or maybe never at all. Likewise the end-of-life for v2 is not set either. It may be a year after v3 comes out, or two years, or maybe never. All I can say is that the end-of-life for an API version will be announced ahead of time.
The product version for PLM 360 gets updated for every major PLM 360 release, which happens about every month. You can easily find the current version by going to /version.txt on your tenant. At the time of writing, 9.1 is the current version. When PLM updates, new features may be added to the API. So if you want to name a specific API schema, you need to include both the API version and the product version. For example, “API schema 2:9.1” or something like that. Most of you shouldn’t have to care about exact schemas. The API version is usually sufficient. However, I do recommend that you record the current PLM 360 product version somewhere in your code and/or readme documentation. It will be a helpful data point if you run into issues later on.