These docs are a work in progress and may not be fully up to date. Some pages may contain internal notes for our team.
Skip to Content

Decision: Workspaces gated to Premium (and above)

Status: accepted

Context

DropAFinder supports multi-workspace access — a user can be a member of multiple isolated workspaces, each with its own finders, locations, and members. This is positioned as a team/agency feature rather than a solo-user feature.

The question was where to enforce the plan gate: in the UI (hide the workspace switcher / creation UI for lower-tier users), on the server (reject workspace API calls), or both.

UI-only enforcement is a common shortcut. It fails in two ways: (1) a determined user can call the API directly; (2) a frontend bug or incomplete guard can silently expose premium surfaces to free users.

Decision

Workspace endpoints are guarded at the route level in routes/api.php using the subscription_tier:free middleware alias (which maps to EnsureSubscriptionTier with a minimum tier of free).

🔴 [NEEDS CLARIFICATION: The route file shows subscription_tier:free on the workspace group (line 147), which would allow free-tier users. Verify whether this is intentional (free users can have one workspace) or should be a higher tier like subscription_tier:bronze. Check EnsureSubscriptionTier rank logic against the current billing tier definitions.]

The dashboard UI also hides workspace creation and switching for users below the required tier — this is the second layer, not the primary enforcement.

Every workspace-aware API call passes workspace_id as a query param. Requests without a valid workspace association return 403 or 404, so the workspace gate is implicitly enforced on downstream resources too.

Consequences

Benefits:

  • A user who bypasses the frontend (e.g., via curl with a valid JWT) still cannot create workspaces above their plan limit.
  • The server is the authoritative source of plan entitlements; the frontend only needs to match the server’s behavior in the UI.

Costs:

  • Every workspace-related page and component must call the workspace API and handle the 403 gracefully. A component that skips the API call and renders directly will silently succeed for unauthorized users.
  • Plan tier changes (upgrades/downgrades) take effect immediately at the API level but the frontend may show stale workspace data until the next page load or store refresh.

Implementation note: Non-premium users still have an implicit default workspace. They can access it but cannot list, create, or switch to additional workspaces.

Concepts