Authentication

API keys are workspace-scoped bearer tokens for paid workspaces.

ProteinIQ API requests are authenticated with workspace API keys. Every data route under /api/v1 requires a bearer token in the Authorization header.

API keys

API keys are created from the API keys page. Creating and using API keys requires an active paid workspace plan.

A live key has this shape:

Text

pq_live_<keyId>_<secret>

The full value is shown only once when the key is created. After that, ProteinIQ stores a hashed secret and displays only identifying metadata.

Send a bearer token

Send the full key as a standard bearer token:

curl -s \
  -H "Authorization: Bearer $PROTEINIQ_API_KEY" \
  "https://proteiniq.io/api/v1/account"

Scopes

API keys can carry these scopes:

Scope	Allows
`jobs:read`	Read account metadata, list tools, list jobs, read job status, stream job events, and fetch results
`jobs:write`	Submit jobs, quote jobs, and cancel queued jobs
`files:read`	List saved files, read file metadata, and reference saved files in job inputs
`files:write`	Upload and delete saved workspace files

New keys use jobs:read, jobs:write, files:read, and files:write when no custom scope list is provided.

Workspace scope

API keys are permanently bound to the workspace that created them. Job lists, job status reads, cancellations, result reads, and file reads are scoped to that workspace.

If a valid key tries to access a job from another workspace, the API returns not_found instead of revealing that the job exists elsewhere.

Key metadata

Use GET /api/v1/account to inspect the current key metadata:

JSON

{
  "api_key": {
    "id": "key_123",
    "env": "LIVE",
    "prefix": "pq_live_abc123",
    "scopes": ["jobs:read", "jobs:write", "files:read", "files:write"]
  }
}

Security

Use server-side environments: API keys can spend workspace credits, so keep them in server-side secrets or local environment variables.
Do not ship keys to browsers: Browser code makes the key visible to anyone who can inspect the page.
Do not commit keys: Keep keys out of git history, notebook outputs, public CI logs, and shared support transcripts.
Rotate when needed: Revoke a key from API keys when it is no longer needed or may have been exposed.