Skip to main content
Every request to the Autorender API carries an API key. Your workspace has two kinds, and the difference is what each one is allowed to do: The short version: the public key uploads, a private key does the rest. If you are writing browser or mobile code, use the public key. If you are writing server code, use a private key. Find both on the API Keys page — sign in to Autorender and click API Keys under Configurations in the sidebar. Only workspace owners can view or manage keys.

The public key

Your public key already exists — Autorender creates one with your workspace, and you cannot delete it. It is displayed in full on the API Keys page, and you can copy it as often as you like. It is safe to ship inside a web page or a mobile app, because uploading is all it can do. Anyone who views your page source can read it, and the worst they can do with it is upload a file to your workspace.
Uploader in the browser
Everything else is refused. Listing files, reading file details, renaming, deleting, and the optimizer proxy all return 403 for a public key:
403 response
Seeing that 403 means the code doing the work belongs on your server with a private key — not that the public key is broken.
Because uploading is the only thing it permits, the public key needs no rotation and cannot be revoked. It is subject to the same per-endpoint rate limits as any other key.

Private keys

A private key can do everything the API offers, so it must stay on your server. Treat it like a password: anyone holding it can read, rename, and delete files in your workspace.
1

Click Add private key.

Name the key after where it will be used — Production server, CI pipeline, Staging — so you can tell your keys apart later. The name is optional, and you can rename a key any time.
2

Save the key immediately.

Autorender shows the full key once, in a Save your private key dialog. Click Copy or Download, then confirm I’ve Saved It.
This is the only time the full key is shown. Autorender stores only a hash of it, so it cannot be displayed again — close the dialog without saving and you will have to create another key.
Your plan sets how many private keys a workspace can hold, and the page shows how many you have used. Free workspaces get 2, Build 10, and Scale has no limit. At the cap, delete a key you no longer need or upgrade your plan — the public key does not count toward it.

Use a private key in your code

1

Store it as an environment variable.

Never hardcode a private key, and never expose it to the browser. Put it in .env:
.env
Add .env to .gitignore if it isn’t already, so the key never lands in version control. Most frameworks do this for you.
Do not use a NEXT_PUBLIC_, VITE_, or REACT_APP_ prefix for a private key. Those prefixes ship the value to the browser, where anyone can read it. Client-side code takes the public key instead.
2

Pass it to your client.

Every backend SDK follows this pattern — see SDKs for your language.
3

Or call the API directly.

Send the key in either header:

Rename or delete a private key

On the API Keys page, each private key has a pencil icon to rename it and a trash icon to delete it.
Deleting a key takes effect immediately and cannot be undone. Anything still using it starts failing with 401 right away, so if the key is live in production, deploy a replacement first and delete the old key afterward.

Which key does my integration need?

Connecting a plugin with a public key is refused at connect time with a message telling you to use a private key, rather than connecting and then failing on every asset request.

Workspace ID

The same page shows your Workspace ID above the keys. It identifies your workspace — quote it when contacting support — and grants nothing on its own, so it is not a credential and needs no protection.

Next steps

Run quickstart

Turn your key into a transformed delivery URL.

View authentication reference

Header formats, key scopes, and error responses.