Derive ownership on the server
A record ID identifies something; it does not prove who may read it. supastack scopes user-owned records by workspaceId. The server resolves the authenticated user’s workspace and includes that scope when reading or changing a record.
Do not treat a workspace ID sent by the browser as evidence of ownership. The browser can request an action, but the trusted server context must establish whose action it is. This rule needs to hold for task status, saved provider configuration, usage records, and every product-owned resource.
Make recovery useful without granting access
A task URL lets a user return after a refresh. It is useful precisely because it preserves a reference to the work. The authenticated API must still verify that the requested task belongs to the current workspace before returning status or results.
The same principle applies to submission recovery. An idempotency key helps identify a repeated request and prevent duplicate work. It is neither a session nor an access token. Retrying a saved submission still requires authentication, workspace ownership, and the appropriate entitlement.
Test the requests that must fail
A test that lets an owner retrieve a record proves the happy path. It does not prove isolation. Pair it with a second workspace requesting the same record, an anonymous request, and a write that attempts to substitute another owner.
Assert the external behavior as well as the persisted result. A rejected request must not mutate another workspace’s data, and an error response must not leak secrets or raw database details. These checks make the boundary reviewable when implementation changes.
Carry the rule into your product
When you add a new product table, decide its ownership before building the screen. Include workspaceId in its persistence model, resolve the workspace through the existing server boundary, and use that context in both list and detail operations.
Background workers need the same care. A queued task must carry enough trusted context to load the correct record, while provider credentials stay on the server. A consistent ownership rule is easier to maintain than a collection of route-specific exceptions.