BugBoardDocs

Introduction

BugBoard turns runtime errors into cards on a kanban board. Instead of a separate error inbox you triage somewhere else, every reported error becomes a task you can prioritise, assign, comment on, and move to done — in the same board your team already works from.

There is exactly one public ingestion endpoint — POST /api/v1/tasks — and everything else is built on top of it.

Two ways to report

You can integrate BugBoard in two ways. They hit the same endpoint and produce the same cards.

Method Best for What you write
HTTP API (recommended) Any language or platform, full control, no dependency A signed (or bearer) POST request
SDK JavaScript/TypeScript and PHP apps A few lines of setup + named helpers

We recommend the API as the source of truth. It works everywhere, has no moving parts to keep up to date, and the SDKs are a thin, ergonomic wrapper around it. Reach for an SDK when you want the queue, retries, and shutdown flushing handled for you.

How it fits together

your app  ──►  POST /api/v1/tasks  ──►  BugBoard  ──►  card on your board
              (API key + payload)        dedupes,         triage, assign,
                                         routes to a      comment, resolve
                                         board column
  • A report carries a severity (critical | major | moderate | minor) and a priority (low | medium | high). Together they decide how the card looks and where it lands.
  • Repeat reports are deduplicated into a single card with an occurrence count, so a spike of the same error doesn't flood your board. They don't have to be identical — reports sharing a title group together, and each distinct payload is kept beneath the card as a variant you can browse. See Deduplication.

Where to go next