Skip to main content
Swisstools uses a two-level hierarchy to organize your work: teams and projects. Teams group people together, and projects hold all the resources you create — mock endpoints, webhook inboxes, feature flags, and more. Understanding this structure helps you plan how to share access and keep different environments or services cleanly separated.

​
Teams

When you sign up, Swisstools automatically creates a personal team for you. You can also belong to additional shared teams, which let you collaborate with other members. Each team has two identifiers:
  • Slug — a human-readable name used in the dashboard (for example, acme-corp)
  • Reference ID — an 8-character alphanumeric ID used to build your project’s subdomain URLs (for example, aB3kL9mX)
You can find your team’s reference ID in your team settings. It appears in every subdomain URL your projects use, so it’s worth knowing where to look.

​
Projects

Projects belong to a team. Each project has a name, slug, and optional description. When you open a project in the dashboard, you see all of its associated resources organized by feature area. Projects are the primary unit of isolation in Swisstools. Every mock endpoint, webhook inbox, and feature flag you create lives inside exactly one project, and each project gets its own subdomain URL for serving those resources.
Deleting a project permanently removes everything under it — all mock endpoints, webhook inboxes, and feature flags are deleted along with the project. This action cannot be undone.

​
How the hierarchy fits together

1

You sign up

Swisstools creates your account and provisions a personal team automatically.
2

You create a project

Inside a team, you create one or more projects. Each project gets a name, slug, and a unique subdomain URL derived from your team’s reference ID and the project slug.
3

You add resources

Inside a project, you create mock endpoints, webhook inboxes, or feature flags. All resources belong to the project and are accessed through its subdomain.
4

You share access (optional)

Other team members can access the same projects and their resources without needing separate accounts or configurations.
This structure gives you flexibility: use a single project for a small side project, or create separate projects per service, environment, or team initiative.