Skip to main content
Every resource in abadge belongs to an organization. The dashboard always operates against the active organization, shown in the sidebar org switcher. A personal account is structurally a single-member organization flagged as personal. It is labelled “Personal” in the switcher and is not in custody mode. See Items.

​
Creating an organization

1

Open the org switcher

Click the workspace name at the top of the sidebar, then Create organization…. (The same form is the Create a new organization option during onboarding.)
2

Name it

Enter a display name. The slug is auto-generated from the name; override it if you want a specific URL fragment. Slug availability is checked live.
3

Land inside the new org

The dashboard switches context and lands you on the overview. The org is created with a default server_managed profile in the same transaction, so you can store secrets immediately — there’s no separate profile-bootstrap step.
Add more profiles — including zero-knowledge profiles with their own password — later from the Profiles page.

​
Switching organizations

The org switcher lists every organization (and personal account) you belong to. Selecting one updates the active context; org-scoped views — items, agents, permissions, audit — refetch for the new org. The switcher also offers Create organization… and Join another organization…. The active organization is persisted locally, so subsequent dashboard visits land in the same place. Members apply to team organizations only. A personal account is a single-user vault, so the Members section is hidden in its Settings.

​
Inviting members

1

Open Settings → Members → Invite member

The members table and invite card are available to owner and admin roles.
2

Pick a role and generate a link

Choose owner, admin, or member, then Generate link. The dashboard returns a one-time invite link.
3

Send the invite link

Copy the link from the card and send it through your usual channel. The link expires after 7 days; the token can be redeemed exactly once.
4

Recipient accepts

The recipient signs in (or creates an account) and opens the link (/invite/accept?token=...). They can also paste the raw token or URL at /join or via the org switcher’s Join another organization… dialog. After confirming the org name and role, they’re added with the assigned role.
The invite token is shown once. Only its SHA-256 hash is stored. If you lose the link, revoke the pending invitation and create a new one.

​
Member roles

​
Managing members

The members table on Settings → Members lists each member’s name, role, and join time. Owners and admins can Remove a member; removal disables that member’s agents and deletes their permissions. (Removal is confirmed in a dialog.)

​
Personal API keys

Settings → API keys lets you mint personal API keys to script the management surface without a browser. Each key is bound to your user and the active org.
1

Create the key

In the Create API key card, give it a name and pick an expiry (Never, 30 days, 90 days, or 1 year), then Create key.
2

Copy the secret

The card then shows the full abu_... secret exactly once, with a warning. The server stores only its SHA-256 hash plus a short prefix.
3

Use it as a bearer token

Send Authorization: Bearer abu_..., or pass it as the sessionToken to AbadgeUserClient.
The keys table lists each key’s name, prefix, created time, last-used time, and status (Active / Expired / Revoked). Revoke disables a key immediately.
A personal API key authenticates the management surface only — organizations, profiles, items metadata, agents, permissions, audit, settings. It resolves to a session identity, not an agent, so it can never reveal or mount secret values. Reading secrets still requires a keypair agent plus an explicit permission. A personal API key also cannot create or revoke other API keys — use a browser session for that.
See Authentication for personal API key details.

​
Removing the organization

Settings → Danger zone deletes the organization (or personal account). Deletion cascades to its agents, permissions, profiles, and items. Audit entries persist (they have no foreign-key constraints). This is irreversible. Deletion is not blocked when items exist — those items are deleted along with everything else. Because the action is destructive, the confirmation dialog requires two things, both re-checked server-side:
1

Type the exact workspace name

Type the organization (or personal account) name to confirm you know which workspace you’re deleting (GitHub-style). It must match the current name. Re-verified by the server — a mismatch returns CONFIRMATION_MISMATCH.
2

Re-enter your account password

Owning the org is not enough; the server re-authenticates the password against your credential account. A wrong password returns REAUTH_FAILED and is shown inline on the password field, so you can correct it without re-opening the dialog. A social-login-only account with no password set returns REAUTH_PASSWORD_REQUIRED (set a password via password reset first).
Only an owner can delete the organization. If either gate fails, the dialog stays open and surfaces the reason in place rather than dismissing. Both allowed and denied attempts are written to the audit log.