Getting started

Authentication

Every request carries an API key as a bearer token. A key acts for your account: it can create, use and destroy any of your sandboxes.

API keys

Create and revoke keys on the API keys page of the dashboard. A key looks like ro_live_ followed by 32 hexadecimal characters. It is shown once when you create it; we store only a SHA-256 hash, so a lost key can’t be recovered — revoke it and create a new one.

The spawn CLI creates its own key when you run spawn login, named Spawn CLI · <hostname>. It’s listed and revoked on the same page; in CI, give the CLI a key through SPAWN_API_KEY instead.

Sending the key

Put the key in the Authorization header of every request:

Authorization: Bearer ro_live_...

For example, listing your sandboxes:

curl -sS "$SPAWN_API_URL/session" \
  -H "Authorization: Bearer $SPAWN_API_KEY"

The only route that doesn’t need a key is GET /health, which reports that the API is up.

When a key is rejected

Credentials that aren’t your key

A few things deliberately don’t use your API key, so it never has to reach a browser:

• Terminals connect over WebSocket with a single-use token that expires after 60 seconds. See Terminals.
• Browser IDE links carry a single-use token that becomes a one-hour cookie for that sandbox only. See Browser IDE.
• Port previews are signed links that expire. See Port previews.

Keeping keys safe

• Call the API from your backend or agent runtime, never from code that ships to a browser.
• Keep keys in environment variables or a secret manager, not in source control.
• Use separate keys per environment or agent so you can revoke one without the others.