API Keys

📘 Note
All applications submitted to the Onshape App Store (Onshape Apps) must follow the instructions on the OAuth2 page and use OAuth2 for authorization. Automation scripts (or applications not meant for the Onshape App Store) may use either OAuth2 or API Keys for authentication. OAuth2 allows applications to call Onshape APIs on behalf of the users of the application; API keys will only perform operations on behalf of the Onshape user who generated the API keys.

Why API Keys?

API keys are useful for small applications meant for personal use, allowing developers to avoid the overhead of the OAuth workflow. Creating an app is very easy with API keys: create an API key with the Developer Portal, set up a function to build your API key header as in the samples, and make your API calls! There’s no need to deal with OAuth redirects or things like that.

We’ve moved over to using API keys for authenticating requests instead of using cookies for several reasons.

Security: Each request is signed with unique headers so that we can be sure it’s coming from the right place.
OAuth: The API key system we’re now using for HTTP requests is the same process developers follow when building full-blown OAuth applications; there’s no longer a disconnect between the two.

Once you create an API key, it will only be valid in the stack on which it was created. An API key created on the partner stack, for example, will not function on the production stack.

If you need information or have a question unanswered in this documentation, feel free to chat with us by sending an email to api-support@onshape.com or by checking out the forums. If you are a member of the DevPartners group (see the Development help page for information) more detailed instructions and code examples are in the apikey sample repo.

1. Create API Keys

Go to https://dev-portal.onshape.com.
In the left pane, click API keys.
Click the Create new API key button.
Select the desired permissions for your app.
Click the Create API key button.
Copy both the access key and secret key from the pop-up window, save them somewhere, then click the Close button.
IMPORTANT NOTE: You will not be able to find the secret key again, so save it somewhere safe!
The details for your application appear.
Now that you have a key pair, see Generate a Request Signature for information on signing your requests to use our API.

Once you have your access key and secret, you will want to avoid giving others access to them, since they’re tied directly to your personal Onshape account. Think of your API key as a username and password pair. Do not place them directly in the code for your application, especially if others might see it. The samples we provide here use a separate configuration file to contain this information, but there are other ways to keep the access key and secret safe, like setting them as environment variables.

Scopes

There are several scopes available for API keys (equivalent to OAuth scopes):

OAuth2Read - Read non-personal information (documents, parts, etc.)
OAuth2ReadPII - Read personal information (name, email, etc.)
OAuth2Write - Create and edit documents, etc.
OAuth2Delete - Delete documents, etc.
OAuth2Purchase - Authorize purchases from account

2. Select an Authentication Option

Please select an option for authentication:

Basic Authorization: Lowest security. For local testing only.
Request Signature: Medium security. For testing and internal use.
OAuth2: Highest security. Required for all Onshape Apps.

Basic Authorization

For local testing, you can provide a basic authentication via your API Keys.

Open your terminal/command prompt and run the following command, replacing ACCESS_KEY and SECRET_KEY with the access key and secret key you created earlier. Remember to include the colon (:) between the keys. You will receive a long, base-64-encoded string as output.
- MacOS:
```
printf ACCESS_KEY:SECRET_KEY | base64
```
- Windows:
```
powershell "[convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes(\"ACCESS_KEY:SECRET_KEY\"))"
```
- For example, given an access key of abcdefghi0123456789jkl and secret key of abcdefghijklmnopqrstuvwxzy0123456789abcdefghijkl, the corresponding command would be:
  - MacOS
```
printf abcdefghi0123456789jkl:abcdefghijklmnopqrstuvwxzy0123456789abcdefghijkl | base64
```
  - Windows
```
powershell "[convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes(\"abcdefghijklmnopqrstuvwxzy0123456789abcdefghijkl:abcdefghijklmnopqrstuvwxzy0123456789abcdefghijkl\"))"
```
Make note of the output string; these are your credentials.

Add the authorization header to your code, replacing CREDENTIALS with the string you received in Step 2:

-H 'Authorization: Basic CREDENTIALS' \

For example:

-H 'Authorization: Basic ZnBpZnE1cm92d2VjeHZRU0k0MmxHbn0m4r5ydXNXczRPRUJLWTduS1NObVhoMzlrN2dzVE5QWEdqb0gzSUU4dFVnTlREdDZaYQ==' \

See our Quick Start Guide for an example of using Basic Authorization in an app.

Request Signature

For additional security, you can include your API Keys as part of a request signature. This provides more security than the Basic Authorization above, but less security than OAuth2.

To ensure that a request is coming from you, we have a process for signing requests that you must follow for API calls to work. Everything is done via HTTP headers that you’ll need to set:

Date: A standard date header giving the time of the request; must be accurate within 5 minutes of request. Example: Mon, 11 Apr 2016 20:08:56 GMT
On-Nonce: A string that satisfies the following requirements:
- At least 16 characters
- Alphanumeric
- Unique for each request
Authorization: This is where the API keys come into play. You’ll sign the request by implementing this algorithm:
- Input: Method, URL, On-Nonce, Date, Content-Type, AccessKey, SecretKey
- Output: String of the form: On <AccessKey>:HmacSHA256:<Signature>
- Steps to generate the signature portion:
  1. Parse the URL and get the following:
    1. The path, e.g. /api/documents (no query params!)
    2. The query string, e.g. a=1&b=2
      - NOTE: If no query paramaters are present, use an empty string
  2. Create a string by appending the following information in order. Each field should be separated by a newline (\n) character, and the string must be converted to lowercase:
    1. HTTP method
    2. On-Nonce header value
    3. Date header value
    4. Content-Type header value
    5. URL pathname
    6. URL query string
  3. Using SHA-256, generate an HMAC digest, using the API secret key first and then the above string, then encode it in Base64.
  4. Create the On <AccessKey>:HmacSHA256:<Signature> string and use that in the Authorization header in your request.

Below is an example function to generate the authorization header, using Node.js’s standard crypto and url libraries:

// ...at top of file
var u = require('url');
var crypto = require('crypto');

/**
* Generates the "Authorization" HTTP header for using the Onshape API
*
* @param {string} method - Request method; GET, POST, etc.
* @param {string} url - The full request URL
* @param {string} nonce - 25-character nonce (generated by you)
* @param {string} authDate - UTC-formatted date string (generated by you)
* @param {string} contentType - Value of the "Content-Type" header; generally "application/json"
* @param {string} accessKey - API access key
* @param {string} secretKey - API secret key
*
* @return {string} Value for the "Authorization" header
*/
function createSignature(method, url, nonce, authDate, contentType, accessKey, secretKey) {
    var urlObj = u.parse(url);
    var urlPath = urlObj.pathname;
    var urlQuery = urlObj.query ? urlObj.query : ''; // if no query, use empty string

    var str = (method + '\n' + nonce + '\n' + authDate + '\n' + contentType + '\n' +
        urlPath + '\n' + urlQuery + '\n').toLowerCase();

    var hmac = crypto.createHmac('sha256', secretKey)
        .update(str)
        .digest('base64');

    var signature = 'On ' + accessKey + ':HmacSHA256:' + hmac;
    return signature;
}

Redirects

Some API endpoints return 307 redirects. You must generate an Authorization header for the redirect as well, but please note that the server portion of the URL might be different, the redirect URL may contain query parameters that must be encoded in the Authorization header, etc.