Start

Introduction to NoteBugs

A local Kanban board, in Docker, with your data in your own PostgreSQL, and a whole HTTP API behind it.

NoteBugs is a Kanban board for centralising and validating internal projects. It runs entirely in Docker, keeps everything in a PostgreSQL that is yours, and depends on no external service to work: not to attach a screenshot, not to make a backup.

This documentation has two halves. The first describes what the product does, feature by feature. The second is the API reference: every route, with the fields it takes, request examples in cURL and TypeScript, the success response and the possible refusals.

The mental model

Almost everything in NoteBugs follows from one short hierarchy, and knowing it explains most of the API:

workspace (tenant)
  ├── card ──────────── the first-class entity
  ├── project ─ epic ── the epic inherits the project's workspace
  ├── label
  └── column
          └── comment · attachment · history · link

The card is the first-class entity. projectId is nullable: a project is a filter label, not an owner. What isolates is the workspace.
`tenantId` is immutable. Card, project, label and column are born inside a workspace and never leave it: no edit schema accepts that field.
The epic is the one exception: it does not carry the workspace, it inherits the project's. That is why it is the only creation that does not ask for tenantId.

Where to start

Quickstart

Bring the container up, create the first account, make a token and the first call.

Authentication

Session cookie, Bearer token, the two role axes and the rate limit.

System overview

How the application is put together and where each rule is applied.

API conventions

What holds for EVERY route: validation, error shape, batches and confirmation.

The examples point at localhost

Every call in this documentation uses http://localhost:3000, which is where Compose publishes the application. On an installation behind a proxy, change only the host, and nothing else moves.