Onboarding walkthrough
Everything the dashboard can do, in the order a new vendor does it.
The dashboard at keyring.belghalem.fr is an HTTP client of the control plane and nothing more: every action on it is one of the control-plane endpoints, and everything it can do, a krsk_ secret key can do over curl. This walkthrough follows the dashboard's own navigation.
| Step | Dashboard page | Endpoint |
|---|---|---|
| Workspace and secret keys | Sign up, Welcome, Settings | POST /v1/workspaces, /v1/secret_keys |
| Projects | Projects | POST /v1/projects |
| Tenants | Tenants | POST /v1/tenants |
| Keys | API keys | POST /v1/keys |
| Test mode | Mint a key → Mode | The env on every key |
| Rotate and revoke | API keys → the key | /v1/keys/:id/rotate, /v1/keys/:id/revoke |
| Rate limits | Project and key edit forms | default_rate_limits, rate_limits |
| Idempotency | Nothing to configure | The Idempotency-Key header |
| Request logs | The key page, the tenant page | GET /v1/keys/:id/usage, /v1/usage/tenants |
| Embed "Manage API keys" | Settings → embed origins | POST /v1/embed_tokens, @keyring/react |
Two principals show up throughout, and keeping them apart is most of the mental model:
- A
krsk_secret key is your credential. Your server uses it to poll policy and to call the control plane. It is minted once per workspace on sign-up and again from Settings → Secret keys. - A
kr_API key is your customer's credential. It belongs to one tenant, one project and one environment, and it is the thing the SDK verifies on every request.
Neither is ever shown twice. The control plane stores hashes and there is no plaintext recovery for anyone, support included.