Skip to main content

Workspaces and team access

Workspaces are the core sharing boundary in OpenDocs.

What a workspace does​

When you complete onboarding, OpenDocs associates you with a workspace. That workspace becomes the primary scope for:

  • workspace-visible documents
  • team membership
  • invitations
  • visibility defaults and policies

Workspace visibility​

If a post is workspace visible, active workspace members can read it.

That makes it the best default for:

  • architecture docs
  • rollout notes
  • specs
  • runbooks
  • AI-generated drafts that should stay internal

Team workflows​

OpenDocs supports team and invitation flows in the dashboard, and the full API surface is also exposed for automation:

  • add teammates — POST /api/v1/workspace/team/invite
  • manage roles — PATCH /api/v1/workspace/team/members/:memberId/role (owner / admin / member)
  • resend or cancel pending invitations
  • remove a member — DELETE /api/v1/workspace/team/members/:memberId

See Team and invitations API for the full reference. Member counts are capped by plan: Free = 3, Pro = 5, Team = unlimited. On Team, seats are account-scoped and billed by unique active members across all workspaces owned by the subscriber.

Username vs. workspace slug​

The personal-profile URL (opendocs.cc/@<username>) and the document URL (opendocs.cc/<workspace-slug>/<post-slug>) use two different identifiers. See Usernames and workspace slugs for the distinction.

Best practice​

If you're using OpenDocs with agents, keep the agent default at workspace unless you explicitly want an outward-facing URL.