Tenancy & Scopes
How Subscriby isolates every API read and write to a single team, and how scope entries on a token narrow it further.
Subscriby is multi-tenant by construction. Every project belongs to a team, and every row that hangs off a project inherits that team's isolation. The API preserves the same boundary — a token minted for Team A can never read or mutate rows that belong to Team B.
Request-scoped team
Every token carries a mandatory scope:team:<uuid> entry in its ability list. When a request arrives on api.subscriby.net:
- Sanctum validates the bearer token.
- The server reads
scope:team:<uuid>from the token's ability list and scopes every query to that team for the duration of the request. No database write happens — the override lives in memory only.
From that point on, every read the request performs is automatically tenant-scoped — the same isolation the creator dashboard uses. You never pass team_id manually in the request body.
Missing the scope:team:<uuid> entry on a token fails every request with
TENANT_MISMATCH before the controller even runs. The dashboard appends the
scope automatically — only hand-crafted tokens miss it.
Optional project scope entries
To further restrict a token, attach one or more scope:project:<uuid> entries alongside the team scope. The server parses them into an allow-list; any request touching a project outside the list returns TENANT_MISMATCH (HTTP 404 — see below).
Typical use cases:
- A Zapier Zap that should only see one project at a time.
- An MCP token handed to a contractor who should only work inside one project.
- A read-only analytics pipeline pulling metrics from a subset of projects.
Cross-team access is 404, not 403
When a token with scope:team:A tries to GET /v1/projects/<id-in-team-B>, the response is:
HTTP/1.1 404 Not Found
Content-Type: application/json
{"error": {"code": "RESOURCE_NOT_FOUND", ...}}This is intentional: a 403 would leak the fact that the project exists under a different team. 404 keeps tenant existence private.
MCP inherits the same contract
The MCP server at mcp.subscriby.net enforces the same team and project scoping. A token issued for Team A that tries to exercise a tool against Team B's project returns the same TENANT_MISMATCH envelope — just wrapped in the MCP response shape.
Related
- Authentication — how tokens are minted and presented.
- Ability catalog — every accepted ability string plus scope entries.
- Error envelope —
TENANT_MISMATCHremediation.
How is this guide?