Click on the image below to try out the viewer on an already translated model.
To use Autodesk API, first log in or register an Autodesk ID. Once you are logged in, you can create an app with Autodesk.
Note: the Callback/Redirect URL is for OAuth2 two-leg authentication. Don’t worry if you do not have a callback/redirect set up yet, but a value is required in this field to proceed. Once you have an application set up, you will see a Consumer Key, Consumer Secret, and the Callback/Redirect URL. Save your Consumer Key and Consumer Secret, you will need them for the next step.
Note: if the Consumer Key and Consumer Secret are struck out, your application is pending approval, and you will not be able to authenticate and use the APIs until it is approved.
To get an access token, pass your Consumer Key (as the client_id parameter) and Consumer Secret (as the client_secret parameter) to the Authentication API. However, this cannot be done from the browser context because it would be a security hole to let your keys "leak out" to an unsafe location. Therefore, you need to setup an Auth Token Service and embed your keys safely in that service. Your browser based app will then call that service to get a valid auth token that it can use to make all API calls. For more information on how to set up your own Auth Token Service, click here
If you use your own custom AuthTokenServer, enter the URL. It must return the full response text that comes back from the call to the Viewing Service's authenticate API.
If you want to quickly authenticate, you can just cut and paste the following command to a Terminal window:
cURL Statement curl https://developer.api.autodesk.com/authentication/v1/authenticate --data 'client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&grant_type=client_credentials&scope=data:read data:write bucket:create' --header 'Content-Type:application/x-www-form-urlencoded' -k
Make sure to relplace MY_CONSUMER_KEY and MY_CONSUMER_SECRET with the keys you obtained in Step 2. When you get the result, cut and paste the "access_token" into the field below and then press the "Use AuthToken" button. This AuthToken will expire after approximately 30 minutes and you will have to do this step again.
"Buckets" are containers for data used by the Autodesk Data Management API. Before uploading a file, create a bucket and set a retention policy. Briefly, the policies are:
There are also some restrictions on the characters used in the bucket name. It must be between 3 to 128 characters long and contain only lowercase letters, numbers and the symbols . _ -
Get the details of a previously defined bucket and verify that it exists.
The extensions that have a channel named “Viewing-*” are supported for viewing.
The next step is to put a file into your bucket so that it can be translated and viewed. Currently over 60 file formats are supported, including:
The key piece of information returned upon successful upload is the id, which is needed for the next steps.
If your model consists of several files (such as an Inventor Assembly IAM file and several IPT parts files), upload each of those files to your bucket, and note the ID for each one. Then, you will need to do an extra step outlined here: Composite Design Upload and in Step 9 below.
File not loaded
Get the details of an object (file) in the bucket.
Set references for a composite design (Xrefs/Assemblies). Use the template below that shows the JSON format for specifying the references. First upload the individual files using Step 7 above. Record each of the id and key values and then paste them into the JSON format below to specify how the files work as an assembly.
The template shows "MYBUCKET", "ROOT_FILE", and "LINKED_FILE" as the placeholders you replace with your own data. This template specifies a single linked file, but you can have multiple dependencies. The reason for specifying the "metadata" section is so that you can temporarily rename one of the files to match what the authoring application would expect. For example, if I had a ROOT file "A" that had a LINKED file "B", the translation process will expect the LINKED file to have that name. But, you may have versioned the file upon upload and given it a new name like "B2". You can then specify "childPath" as "B" so that it retains its original name when resolving within the authoring application during translation.
A null string response of "" means success. Then use the id of the root file of the assembly as the one to register in Steps 10 and 11 below.
Once the file has been successfully uploaded, we should have recieved back an id in the form of a URN. It should look something like: "urn:adsk.objects:oss.object:mybucket/myfile.ext"
Subsequent usage of this URN must be base64 encoded. Use the input form below or an online tool (such as this) to convert the URN. Use the entire string value retured for id, including the "urn:" prefix.
Note: Javascript source for the input below is available via the source for this page if you want to programmatically encode the URN in future projects.
Have the viewing service translate your file to a neutral format
See what the current status of your translation is
See your translated file in the viewer
