Version

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:

  1. Sanctum validates the bearer token.
  2. 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.

How is this guide?

Version

On this page

Subscriby is a product
designed by you — for you.
No boardroom full of executives deciding what we ships next. Our roadmap always shaped by you with your feedback.

Share feedback or a request