Organizations and projects
Group work into projects inside an organization, the way LLMGateway does.
Work on Repeat separates who you work with from what you are working on:
- An organization owns billing-level identity and membership. Members hold
the role
owner,admin, ormember. - A project lives inside an organization and owns the actual work: routines, runs, connections, and API keys.
Signing up creates a personal organization containing one project named Default project. Nothing else is created implicitly.
Choosing a shape
| Situation | Suggested shape |
|---|---|
| One product, one team | One organization, one project. |
| Staging and production routines | One organization, a project per environment. |
| An agency running client work | An organization per client, or a project per client. |
| Separate credentials per business unit | A project per unit — connections do not cross projects. |
The deciding question is usually credentials. Connections and API keys belong to a project, so anything that must not share a GitHub token or a Stripe key belongs in its own project.
Switching projects
The sidebar shows the active organization and a project picker grouped by
organization. Choosing a project stores it in the wor_project cookie, which
both the browser and the server-rendered dashboard send to the API.
An API request may also name a project explicitly with the X-Project-Id
header, which takes precedence over the cookie. Either way the API verifies
that you are a member of the organization that owns the project, and falls back
to your personal project when you are not.
Creating organizations and projects
Use + Project or + Organization in the sidebar. Creating an
organization also creates its default project and makes you its owner. Creating
a project requires the owner or admin role in that organization; otherwise
the API returns 403 organization_forbidden.
Both are session-only operations — an API key is already bound to a single project and cannot create the scope above itself.
Isolation
Every repository read and write is scoped by project id. A routine, run, connection, or API key created in one project is not visible from another, even inside the same organization. Integration tests assert this boundary directly rather than relying on route-level checks.
API keys belong to a single project. A key issued in one project cannot read or
trigger anything in another, and an identifier from another project returns
404, never 403 — the API does not confirm that a resource you cannot see
exists.