renza

Authentication

Every request to the API authenticates with an org-scoped API key, sent as a bearer token:

curl https://api.renza.io/v1/me \
  -H "Authorization: Bearer rza_sk_live_…"

Everything requires a key except /health and the /v1/public/* endpoints (public share resolution, anonymous import, CLI pairing).

Getting a key

  • From the terminal: renza login opens the browser, you approve the pairing, and the CLI stores a key bound to you and your org in ~/.renza/config.json. This is the right path for humans and for agents working on your machine.
  • From the dashboard: Settings → API keys, for CI and server integrations.
  • From the API/CLI: POST /v1/api_keys or renza keys create.

The secret is shown once, at creation. Afterwards, only a last-4 hint is retrievable. Treat a leaked key like a leaked password: revoke it and mint a new one.

User keys vs service keys

A key is one of two kinds, fixed at creation:

  • A user key acts as the person who owns it. Its actions are authored as that user — comment author, created_by — so an agent driving Renza with your key is you, automated. renza login mints this kind.
  • A service key (renza keys create <name> --service) is a machine identity with no acting user — right for CI and shared integrations.

Either way, the audit trail always records which credential performed the action — acting-as never erases provenance.

Org scoping

A key is bound to exactly one org, so requests carry no org header. Humans on a dashboard session (who may belong to several orgs) select the active org with Renza-Org: org_…. Every request acts within exactly one org — there is no cross-org key.

Where credentials live

SurfaceCredential source (highest first)
CLI--api-key flag → RENZA_API_KEY env → ~/.renza/config.json (mode 0600)
SDKcreateRenzaClient({ apiKey }) — read it from your secret store
curl / rawAuthorization: Bearer … header

Renza never asks for credentials inside a document, and auth UI only ever appears top-level on renza.io — see Security.