Docs Dashboard Sign in

Projects

A project groups shares inside an org. Every share lives in exactly one project, and the project's slug is part of the share URL:

https://anchorify.io/<org>/<project>/<slug>

When you sign up, Anchorify creates a default project called untitled in your home org. Shares you publish without specifying a project land there.

Why projects?

Projects exist because Anchorify is shared with non-technical clients, and per-share access toggles get unwieldy fast. With projects you can:

  • Invite a client as a viewer of one project and keep the rest of your work invisible to them.
  • Move a share between projects later (the URL redirects automatically — old links keep working).
  • Rename a whole batch of share URLs by renaming the project slug, without re-publishing each share.

Creating a project

Web: there's no UI for it yet — use the CLI or the API for now.

CLI:

anchorify project create q1-reports
anchorify project create q1-reports --name "Q1 Reports"

API:

curl -X POST https://anchorify.io/api/v1/orgs/<org-slug>/projects \
  -H "authorization: Bearer $REPO_SHARE_TOKEN" \
  -H "content-type: application/json" \
  -d '{"slug":"q1-reports","name":"Q1 Reports"}'

Slugs follow the same rules as share slugs: lowercase alphanumerics + hyphens, 1–60 chars. Reserved words (settings, members, invite, etc.) are blocked.

Listing projects

anchorify project list           # human-readable
anchorify project list --json    # machine-readable

Output is <slug>, <name>, and the project's logo (the image URL, else the favicon domain, else —) — tab-separated when piped, aligned columns on a TTY.

API: GET /api/v1/orgs/<org-slug>/projects. Org members see every project; project-only viewers see just the ones they're a member of. The JSON carries share_count, domain, and image_url too.

Renaming a project

Renaming a project slug writes a redirect so old share URLs in the project keep resolving (/<org>/<old-slug>/<share> → /<org>/<new-slug>/<share>).

anchorify project rename old-slug new-slug

The CLI prompts for type-to-confirm by default. Pass --yes to skip.

Giving a project a logo

Each project card on the dashboard shows an avatar. By default that's the first letter of the project name. You can replace it two ways:

  • --domain <domain> — shows that site's favicon. The usual choice for a client project: point it at the client's domain and the card becomes recognizable at a glance.
  • --image <url> — an explicit image URL. Wins over the domain when both are set.
anchorify project logo q1-acme --domain acme.com
anchorify project logo q1-acme --image https://acme.com/logo.png
anchorify project logo q1-acme --clear

Exactly one of the three flags per call. The domain is normalized server-side — https://www.Acme.com/pricing and acme.com both store as acme.com — and the command prints what was actually stored, so you can trust the output when scripting a backfill.

anchorify project list shows the current logo per project (— when unset), which is how you find the ones still missing one:

anchorify project list | awk -F'\t' '$3 == "—" { print $1 }'

The same fields are on the API as domain and image_url — settable via PATCH /api/v1/orgs/<org>/projects/<project> and readable from GET /api/v1/orgs/<org>/projects. Pass "" to clear either. See the API reference.

The dashboard's project settings form writes the same two fields, so it doesn't matter which one you use.

Note this is URL-or-domain-referenced only — there's no file upload for project logos. Org-wide branding (including an uploaded logo) is separate; see Branding.

Publishing into a multi-project org

When your org has 2+ projects, the publish endpoint requires a --project flag:

anchorify report.md --project q1-reports

If you forget it the CLI prints the list of available projects and the exact retry command, so you don't have to look anything up.

Deleting a project

Three rules:

  1. Last-project block. An org must keep at least one project. The CLI and API both refuse to delete the only project in an org.
  2. Empty project. Deletes immediately.
  3. Project with shares. You have to pick a strategy:
    • delete: remove the project and the shares with it. The CLI requires you to type-to-confirm the project slug, since this is destructive.
    • move: move the shares to another project in the same org first, then delete the now-empty project.

CLI (interactive):

anchorify project delete q1-reports
# CLI prompts for strategy + target if applicable.

CLI (scripted):

anchorify project delete q1-reports --strategy delete --yes
anchorify project delete q1-reports --strategy move --target q2-reports --yes

API: DELETE /api/v1/orgs/<org-slug>/projects/<pslug>?strategy=delete or ?strategy=move&target=<pslug>.

Sharing access (project viewers)

Adding viewers to a single project — without giving them admin access to the whole org — happens through invites. See invites. On a share page in your org, the chrome includes an Invite button for admins; the modal lets you pick "this project (viewer)" or "this org (admin)".