Docs Dashboard

Orgs

Every Anchorify user belongs to one org. An org owns projects, which in turn own shares. Sharing collaborator access happens at the org level (admin) or the project level (viewer).

Your home org

When you sign up, Anchorify creates your home org automatically. Its slug defaults to your username, and your dashboard shows it under the top-of-page nav.

The home org is permanent — even if you later get invited into someone else's org and merge yours in, signing back in creates a fresh home org if you ever end up org-less.

Roles

Anchorify has two roles:

  • Admin (org-level). Can publish, edit, delete, and rename shares anywhere in the org. Can invite other admins. Can rename or delete projects. Can change org settings.
  • Viewer (project-level). Can read shares in projects they're a member of, including members-visibility shares. Cannot edit or publish.

A user keeps their own home-org admin role and can hold viewer slots in other orgs' projects at the same time — cross-org viewership is the whole point of project members.

Settings

Visit /dashboard/settings/org to:

  • Change the display name (purely cosmetic; doesn't affect URLs).
  • Rename the slug. Renaming writes a redirect entry so old URLs at the old slug 301 to the new one. The old slug is then permanently retired — no one (including you) can claim it later.

The CLI mirrors this:

anchorify org show
anchorify org rename <new-slug>

org rename prompts for type-to-confirm by default. Pass --yes to skip.

Adding members

Adding another admin uses POST /api/v1/orgs/<slug>/members with {user_email}, or the dashboard's members tab. The recipient must already have a Anchorify account; if they don't, the API returns a 400 hint and you should send them an invite link instead — see invites.

The same email can't be admin of two orgs at once. If they already admin somewhere else, you get a 409 and they need to merge orgs through the invite flow.

Removing members

You can remove a co-admin from /dashboard/members (or DELETE /api/v1/orgs/<slug>/members/<username>). Two guards:

  • Self-removal: you can't remove yourself. Another admin has to do it.
  • Last-admin: the org must keep at least one admin.

Deleting an org

You can't, in practice. The DELETE /api/v1/orgs/<slug> endpoint exists but always returns 400 in V3 because:

  • An org must have zero projects to delete (and project delete refuses to remove the org's last project — see projects).
  • An org must have exactly one admin (and admins can't remove themselves).

This is intentional. If you need to wind one down, transfer ownership through a future flow or contact support.