Multitenancy & RBAC

How team-based access control and workspace isolation work.

Spindle is built for teams. Every workspace keeps its own members, API keys, quotas, and settings isolated from the others.

Workspace Model

Each user starts with a default team and can belong to multiple teams over time.

• Teams group people, keys, and usage under one workspace.
• Isolation keeps team resources and usage separate.
• Switching lets users move between teams they belong to without creating new accounts.

Roles

Spindle supports role-based access control for team administration.

• Owner: Full control over billing, members, API keys, and team settings.
• Admin: Can manage most operational settings and members.
• Member: Can use the product within the permissions granted to them.

Why It Matters

Workspace isolation is important when:

• an agency manages multiple client environments,
• a company separates internal teams by business unit,
• different products or environments need distinct API keys and quotas.

Team Context in the API

Many API requests require an x-team-id header so Spindle knows which workspace the request belongs to.

This keeps extraction activity, limits, and permissions scoped to the correct team.

Common Use Cases

• Separate production and sandbox workspaces
• Different teams for different client accounts
• Shared admin oversight with restricted member access

Next Steps

• Create keys for each workspace in API Key Configuration.
• Review authentication patterns in Authentication.
• Explore team-aware endpoints in the API Reference.