BugDump has four core objects. Understanding how they relate makes everything else straightforward.
Project
The top-level container. A project holds its own reports, captured errors, tasks, board columns, members, widget keys, MCP tokens, integrations, and webhooks.
One project per application is the usual arrangement. Separate staging from production if you want their bugs kept apart — they will have different widget keys, so reports never mix.
Everything else in BugDump belongs to exactly one project. Widget keys and MCP tokens are bound to a single project permanently. The exception is an AI app connected by signing in: it belongs to your account and reaches every project you are a member of.
Report
One submission from one user at one moment: their description plus everything the SDK captured — console, network, session replay, actions, screenshots, and metadata.
Reports are evidence. They are never edited or merged. A report records what happened in one browser at one time, and that record does not change. Reports are kept for the plan's retention period — 30 days on Free, 90 on Pro, 365 on Ultra — and then deleted with their screenshots, recordings and replays. The task they belong to stays.
Task
The thing you actually fix. A task has an ID such as BD-42, a position on the board, an assignee, a priority, comments, and an activity history.
Tasks are work. They move through states and eventually finish.
Many reports attach to one task. This is the key relationship. Forty users reporting one broken checkout become one task with forty pieces of evidence — not forty things to triage.
Board
A kanban view of your project's tasks. You define the columns, and each maps to one of two states: open or closed.
The state is what BugDump uses to determine outstanding work; the column name is for your team. Triage → Confirmed → In Progress → Done → Won't Fix works fine, with the first three open and the last two closed.
How they fit together
Project
├── Reports (evidence, immutable)
│ └── attach to →
├── Tasks (work, moves across the board)
│ └── live in →
├── Board columns (open / closed)
├── Errors (captured automatically, on the Errors page)
├── Members (OWNER / ADMIN / MEMBER)
├── Widget keys (public, submit reports)
├── MCP tokens (personal, one member each)
├── Integrations (Telegram, Slack, GitHub, …)
└── Webhooks (report.created)Why reports and tasks are separate
Most tools conflate them, which forces an unpleasant choice: either every report becomes a ticket and your tracker fills with duplicates, or you merge duplicates and lose evidence.
Keeping them separate avoids both. Reports accumulate freely — duplicates are welcome, because the intersection of many reports on one task is genuinely informative. If all forty are Safari, you have identified the bug before opening a debugger.
Tasks stay few and meaningful. Your board reflects real work, not report volume.
Captured errors
Apart from the four core objects, the widget also captures JavaScript errors by itself, with nobody filing anything. They are not reports: they land on the project's Errors page, where repeats of one bug are grouped into a single row with a count, and they stay off the board. An error becomes work only when someone creates a task from it or links it to an existing task. See Working with captured errors.
Task IDs
Tasks are numbered from 1 within each project, so your project's first bug is 1 no matter how old BugDump is. Each project also has a short key shown in front of the number, which is why a task reads as BD-42.
That label is what you share with your team. The number inside it is what reporters type into the widget when attaching to a task, and what you pass to Claude Code. Both /tasks/42 and /tasks/BD-42 open the task.
Reports have internal UUIDs. You rarely handle them directly — you reach a report through its task.
See Task IDs and project keys for the full rules, including how to change a project key.
The public portal
Each project can publish a portal at https://your-project.bugdump.com, where reporters follow the tasks they filed and upvote them. While it is on, the widget shows a "View reports" link in its footer. See Setting up the public portal.
Next steps
Install the widget
Reading a bug report
Working with tasks and the board
Task IDs and project keys