Scopes for API keys and connected apps

Every credential now carries scopes, and every endpoint states the one it needs. What a caller may do comes from what it was granted, not from whether it authenticated with an API key, an OAuth token or a browser session.

Twelve scopes across six resources: jobs, assets, webhooks, billing, orgs and keys, each with read and write. Write includes read, so a credential holding jobs:write can list jobs and you never need both.

Pass scopes when you create a key and it can do only that.

import { createClient } from "@rendobar/sdk";

const rendobar = createClient({ apiKey: process.env.RENDOBAR_API_KEY });

const key = await rendobar.apiKeys.create({
  name: "CI deploy key",
  scopes: ["jobs:write", "assets:write"],
});

key.scopes; // what it actually got

Omit scopes and the key gets everything a key may hold, which is what keys created before today already have. Nothing you are running needs to change.

A request outside a credential’s scopes is refused with 403 and a header naming what was missing, so a client can tell a scope problem from an authentication one.

WWW-Authenticate: Bearer error="insufficient_scope",
  error_description="This endpoint requires the jobs:write scope.",
  scope="jobs:write"

Connecting an app over OAuth now shows what it asked for, area by area, and you can grant less than it requested. A grant is bound to the workspace you chose. Account, Security lists every connected app with what it can reach, and revoking one cuts it off.

Two things move for existing setups. An API key can no longer create or revoke API keys, because a key that can mint keys survives its own revocation: use the dashboard, or an app you granted key management to. Apps connected before today asked for media access, which does not include key management, so reconnecting grants them the current set.

See Scopes and access for the full vocabulary.