Organizations, workspaces & keys
Four concepts carry everything about who spends what on Heimdallm. From the top down:
| Concept | What it holds |
|---|---|
| User | You — a Google or GitHub sign-in. |
| Account | The money: the credit balance, ledger and account-wide spend limit. Personal or organization. |
| Workspace | A compartment inside an account: its own API keys, its own spend limit, optionally its own members. |
| API key | Credentials for the API. Lives in a workspace; optionally assigned to a person. |
A request's cost settles against the account behind the key's workspace, is capped by the three spend limits (key, workspace, account), and is attributed to the key — so a dashboard can answer "which integration spent this" without separate accounts per project. All of the below is managed from your account page.
Personal accounts
Signing in for the first time creates your personal account with one workspace, named Default.
For an individual that is the whole model: deposit into the account, create keys in the default
workspace, go. More workspaces are useful the moment you want separation — one per project or per
environment, each with its own keys and its own spend limit, all drawing on the same balance.
Organizations
An organization is the shared version of the same shape: its own account (balance, ledger, account-wide limit) and its own workspaces, with members on top.
- Members are added by email — the address must belong to an existing, verified Heimdallm
user. Each member is
adminormember; an organization always keeps at least one admin (the last admin can neither demote themself nor leave). - Admins manage everything: members, workspaces, all keys, spend limits — and only admins (or a personal account's owner) see money: the balance, the ledger and account activity.
- Members work inside the workspaces they belong to: they can create keys there, and they see and manage the keys they created or that are assigned to them — not the whole account, and not the money.
An organization's account is funded directly by any of its admins on the Credits tab — by card, or from a wallet bound to the organization, which credits it for every transfer that wallet sends. See Deposits.
Its traffic reads the same way its money does. The organization page's Activity tab carries the 30-day rollup and, beneath it, the request log — every request the organization made, with the same filters, and each row opening onto the request itself. An organization admin sees the same view from the account switcher on their account page. A request belongs to the account that paid for it, so which organization admins may open one is the same question as who may see the organization's balance: admins, and nobody else.
Organization workspaces can carry an explicit member list, so a contractor can hold keys in one project's workspace without existing anywhere else in the organization.
API keys
Keys are minted in a workspace and shown once — only a SHA-256 hash is stored, and the hash doubles as the key's identifier in the dashboard. Everything about a key is per key:
| Property | Meaning |
|---|---|
| Name | A label (production, ci, alice-dev). |
| Spend limit | A USD ceiling with an optional daily / weekly / monthly UTC reset window — lifetime when no window is set. Breaching it stops this key with a 402 and touches nothing else. |
| Expiry | An optional timestamp after which the key stops authenticating. |
| Assignee | Optionally an organization member, so usage reads as a person's, and the key follows them in visibility rules. |
| Revocation | Disables the key immediately. The row stays, so its ledger history keeps its attribution. Revocation is permanent — mint a new key rather than expecting one back. |
The key authenticates; the workspace locates it; the account pays. Inspect the key you are
calling with at GET /key, and its account's balance at
GET /credits.
Which account does a key bill?
The account that owns the key's workspace — a personal-workspace key bills you, an organization-workspace key bills the organization. One user can carry both: your memberships and your personal account coexist, and the workspace a key lives in decides where its spend lands.
Practical shapes
- Solo — default workspace, one key per integration, a monthly limit on each.
- A team — one organization; workspaces
production,staging,dev; the production workspace capped and its keys unassigned service keys; dev keys assigned per member. - An agency — one workspace per client with an explicit member list, so each contractor sees exactly one client's keys and nothing else.