CiteFoundry Docs
Open dashboard

Projects, team, and roles

Organizations vs. projects, invitations, project-level access, and seat management.

CiteFoundry’s tenancy has two levels: an organization (the billing and team boundary) and one or more projects inside it (each tracks one brand). Pick the right shape early — it’s painful to move work between organizations later, easy to move between projects.

When to use one organization vs. many

  • One brand, one team — one organization, one project. Most customers.
  • Multiple in-house brands — one organization, one project per brand. Shared seats, shared billing, separate dashboards.
  • An agency with clients — one organization, one project per client. Add team members to the organization and grant per-project access so each consultant only sees their accounts.
  • Two independent business units that don’t share data or billing — two separate organizations.

Creating a project

Settings → Projects → New project asks for a display name and a primary domain. The domain seeds the brand-book and is how citations are attributed back to you across runs. You can edit both later.

A new project starts empty — no prompts, no monitors. Visit Quickstart for the recommended seeding flow.

Inviting teammates

Settings → Team → Invite sends an email with a signed token. The recipient signs in (WorkOS handles the SSO/email flow) and is added at their assigned organization role.

Roles at the organization level:

  • Owner — full control including billing and member management.
  • Admin — manage projects and members; no billing.
  • Member — granted access to one or more projects.
  • Viewer — read-only access to assigned projects.

By default new members are added as Member with no project access — grant them to projects explicitly.

Per-project access

Once a member is in the organization, grant them per-project access under Settings → Projects → [project] → Members. This is what makes the agency pattern work: consultant Alice can see clients X and Y but not Z, even though all three projects live in the same organization.

Removing access

Removing a member from the organization revokes all their project access in the same step. Their personal API tokens stop working immediately.

API

  • GET /v1/me — your user + organization + role.
  • GET /v1/projects
  • POST /v1/projects
  • GET /v1/projects/{projectId}/members