When a Request Becomes a Team System

This chapter moves Hoppscotch from the local execution boundary into the collaborative control plane around a request. The focus is what changes when a personal artifact becomes a team collection or a self-hosted deployment: who owns the data, who may change it, how other clients learn about the change, and what the operator must run. Readers will be able to distinguish local transport state from role-governed workspace state and see why self-hosting is an operating responsibility, not simply a way to serve the frontend.

A request that lives only on one device has a relatively simple ownership model. The person using the editor owns the collection, the environment, the history, and the local execution settings. Once that request becomes a shared team artifact, the system must answer harder questions. Which user can view it? Who can edit or move it? How do other members see a change? Which values belong in the shared collection, and which must remain local to a particular machine or session?

Hoppscotch's backend exists to answer those questions around the same request concepts that the local application already understands. It is not merely an account service attached to a browser tool. The repository models users, teams, nested collections, requests, environments, history, mock servers, published documentation, personal access tokens, infrastructure tokens, and administration. The shared workflow becomes a system of ownership and synchronization.

The collaborative control plane

The backend combines a NestJS application, Apollo GraphQL, Prisma persistence, authentication, throttling, subscriptions, health checks, administration, and infrastructure configuration. The database model separates user workspaces from team workspaces. A user collection belongs to a user and can contain nested child collections and requests. A team collection belongs to a team, has an order and parent relationship, and is linked to team requests and team members.

This structure turns a collection into more than a JSON blob. A request has a place in a hierarchy, an owner or team relationship, an order, and potentially associated environments or response examples. The hierarchy matters to the user experience, but it also matters to authorization: an operation on a nested team collection is an operation on shared state and must be evaluated in the context of team membership and role.

The backend's team collection resolver makes that relationship visible. Collection queries and mutations use authentication and team-member guards, then apply role requirements such as viewer, editor, or owner. A viewer can be allowed to inspect a team collection without being allowed to change it. An editor can update or create artifacts without receiving every administrative power. The exact role matrix belongs to the server's authorization layer rather than to the visual collection tree.

The practical result is that the same request has two different dimensions. Its request data describes what to send. Its workspace data describes who may see, edit, move, or export it. The request can remain semantically recognizable across those dimensions, but they should not be conflated. A request's bearer token is not a team membership role; a collection's parent folder is not a transport proxy; a local Agent registration is not a server-side workspace identity.