Projects

Each game you manage in Bugnet is represented as a project. Projects are the top-level organizational unit that contains all your bugs, team members, labels, templates, and settings.

Every project has the following properties:

• Name — The display name of your game (e.g. "Starfield Explorers")
• Slug — A URL-friendly identifier used in all API URLs. Bugnet derives it from the name and adds a short prefix to keep it unique (e.g. a1b2c3-starfield-explorers)
• Description — A short summary of what the game is about
• Website URL — A link to the game's website or store page
• Logo — An image that represents the project in the dashboard

Create new projects from the dashboard by clicking New Project. The maximum number of projects you can create depends on your plan.

The project slug is used in all API routes. For example, to list bugs for a project with the slug my-game, you would call:

GET /api/projects/my-game/bugs

Project Settings

Each project’s card on the Projects page holds its settings:

• Details — Name, description, website and logo
• Public — Whether the project accepts SDK reports and can have public pages. Turning it off makes the API key stop working
• SDK capture — Screenshot capture, session capture (Studio Plus), auto-filing of errors, editor errors, warnings, and bug grouping

The API key (copy and rotate) is on the Integrate page, and the public tracker and roadmap are configured on the Public Roadmap page.

Team & Roles

Add team members to your project to collaborate on bug triage and resolution. Every team member can view bugs, leave comments, and be assigned to fix issues.

Roles

Bugnet uses three roles with increasing levels of access:

All team members can see all bugs in the project and can be assigned to fix them.

Team Size Limits

The maximum team size depends on your plan:

• Indie Up to 2 team members
• Studio Up to 20 team members
• Studio Plus Unlimited team members

Need more seats on any plan? Contact us for volume discounts.

Invitations

Invite new team members by email address from the Team page. An invitation joins someone to your whole account, not to a single project: when they accept they get every project on the account, its bug reports, and its shared usage and plan — including projects you create later.

• Invitations remain in a pending state until accepted by the recipient
• Owners and admins can revoke pending invitations at any time
• If the invited user does not have a Bugnet account, they will be prompted to sign up before joining
• Each invitation is tied to a specific role — the invitee receives that role when they accept
• Removing someone removes them from the account, and so from every project on it at once

Invite via API

POST /api/account/invites
{
  "email": "developer@example.com",
  "role": "member"
}

The per-project routes (POST /api/projects/:slug/invites) still work and do the same thing — they invite to the account that project belongs to.

Permissions

Roles set a sensible starting point; permissions decide the details. Every member of an account starts on their role's defaults, and an admin can grant or revoke any individual permission for a specific person — no promotion required. Permissions apply account-wide, like membership itself: they cover every project on the account, existing and future.

Edit them from the Team page: click Permissions next to a member. Permissions are arranged in groups so you can hand over a whole area at once (Allow all / Allow none on the group header) and then fine-tune individual boxes underneath.

Permission Groups

Defaults

• Owner — everything, always. An owner's permissions cannot be edited, so nobody can be locked out of their own account.
• Admin — everything except deleting a whole project.
• Member — the day-to-day work: viewing, filing, editing, assigning, closing, commenting on and exporting bug reports, plus analytics.
• billing.manage starts on for everyone, because any member may buy the first plan and have it cover the whole account. Revoke it from someone to take those controls away. Whoever is already paying always keeps control of the subscription on their own card.
• project.delete is owner-only and cannot be granted — deleting a project destroys other people's reports. The person who created a project can also delete that one.

Who can edit permissions

Editing access needs the team.permissions permission, which owners and admins hold by default. Three rules hold no matter what is granted:

• An owner's permissions are fixed.
• Admins are peers — only the owner can change another admin's permissions or role.
• Nobody edits their own permissions.

Per-User Overrides

Every box you tick or untick is stored as an explicit decision for that person, so it sticks if they are later promoted or demoted. For example, you might grant a member labels.manage without making them an admin, or revoke bugs.delete from an admin.

Use Reset to role defaults on the Team page to drop every override and put someone back on their role.

API

GET    /api/permissions                              # your own effective permissions
GET    /api/permissions/available                    # the catalog: groups, keys, role defaults
GET    /api/account/members/:userId/permissions      # one member's access
PUT    /api/account/members/:userId/permissions      # set it
DELETE /api/account/members/:userId/permissions      # reset to role defaults

A PUT body takes permissions (individual keys), groups (a whole group at once), and reset (clear existing overrides first):

{
  "groups": { "billing": false },
  "permissions": { "bugs.delete": true },
  "reset": true
}

The per-project routes (GET|PUT|DELETE /api/projects/:slug/permissions/:userId) still work and act on the same account-wide roster.

Labels

Labels let you organize and tag bugs with custom categories. Each label has a name and a color, making it easy to visually identify groups of bugs at a glance.

• Add or remove labels from any bug in the bug detail view
• Filter bugs by label in the bug list to narrow down your view
• Labels are per-project — each project maintains its own set of labels

Common Label Strategies

Labels are flexible and can be used for many purposes. Here are some common patterns:

• Platform — iOS, Android, Windows, Mac, Linux
• Feature area — combat, inventory, UI, audio, networking
• Sprint / Milestone — v1.2, sprint-14, launch-blocker

Labels via API

# Create a label
POST /api/projects/:slug/labels
{"name": "iOS", "color": "#5856D6"}

# List all labels
GET /api/projects/:slug/labels

# Add a label to a bug
POST /api/projects/:slug/bugs/:number/labels
{"label_id": "uuid-of-label"}

Bug Templates

Bug templates let you create reusable formats for common types of bug reports. When a team member files a bug from the dashboard, they can select a template to pre-fill the form with a standardized structure.

Each template can pre-fill the following fields:

• Body template — A structured description with sections like "Steps to Reproduce", "Expected Behavior", "Actual Behavior"
• Category — Pre-select a bug category
• Priority — Pre-set the priority level

Templates are per-project, so each game can have its own set of templates tailored to its QA workflow. Manage them from Settings > Bug Templates or with /api/projects/:slug/templates (fields: name, description, priority, category, body_template).

Custom Fields

Extend your bug reports with custom data fields specific to your game. Custom fields let you capture structured information beyond the default bug report fields.

Field Types

Configuration

• Create fields from Settings > Custom Fields; dropdown options are entered as a comma-separated list
• Fields can be flagged as required through the API; the flag is shown next to the field
• Custom field values are set per-bug and displayed in the bug detail view

Custom Fields via API

# Create a number field
POST /api/projects/:slug/custom-fields
{
  "name": "Player Level",
  "field_type": "number",
  "is_required": true
}

# Create a dropdown field (options are a comma-separated string)
POST /api/projects/:slug/custom-fields
{
  "name": "Game Mode",
  "field_type": "dropdown",
  "options": "PvP, PvE, Co-op"
}

# Set a value on bug #42
POST /api/projects/:slug/bugs/42/custom-fields
{"field_id": "uuid-of-field", "value": "PvE"}

Saved Filters

Save the bug list’s current filters under a name so you can re-apply them with one click from the bug list.

• A saved filter stores the filters that were active when you saved it (status, label, source and search)
• Saved filters are personal — each team member has their own
• Delete a saved filter from the same menu

Through the API, POST /api/saved-filters takes {name, project_id, filters}, where filters is a string your client defines (the dashboard stores its filter state as JSON) and project_id optionally ties it to one project.

Saved Views

Saved views store a named filter and sort order, and can be pinned and ordered. They are per-user and are currently available through the API only:

GET    /api/saved-views
POST   /api/saved-views              {"name", "project_id", "filters", "sort_by", "pinned"}
PATCH  /api/saved-views/:viewId      {"name", "filters", "sort_by", "pinned", "position"}
DELETE /api/saved-views/:viewId

SLA Rules

Service Level Agreement (SLA) rules record your response and resolution targets for each bug priority, and each bug can carry a due date.

Configuration

Set response and resolution hours for each priority level:

These are example values — configure the hours that match your team's capacity and commitments.

How It Works

• Save your targets from Settings > SLA Rules, or with PUT /api/projects/:slug/sla
• Due dates are set automatically. When a bug is filed (from the SDK, the web form, the dashboard or an import), it gets a due date of its creation time plus the resolve-hours target for its priority
• Changing a bug’s priority, or saving new SLA rules, recalculates the automatic due dates of open and in-progress bugs. Removing the rule for a priority clears the automatic dates it set
• Resolved and closed bugs keep the due date they had
• Setting a due date by hand, from the bug’s detail page or with PATCH /api/projects/:slug/bugs/:number/due-date, overrides the rule, and that date is never recalculated. Clearing a due date leaves the bug without one until its priority or the SLA rules next change. The detail page shows whether a date came from your SLA rule or was set by hand
• Bugs whose due date has passed are marked Overdue

Audit Log

The audit log records project-level administrative changes: who made the change, what changed, and when.

Tracked Events

• Settings changes — Project settings updated
• Team changes — Invitation sent, member removed, role changed
• Label changes — Label created or deleted
• Imports — Bugs imported
• Deletion — Project deleted

Log Entry Details

Each audit log entry includes:

• Actor — The team member who performed the action
• Action — What was done (e.g. label_created, member_role_changed)
• Target — What was affected (project, team, label, import)
• Timestamp — When the action occurred

The audit log is essential for security reviews and compliance. Read it with GET /api/projects/:slug/audit-log. The per-bug history of status, priority and assignment changes is on each bug and in Settings > Activity Log.

Import / Export

Import

Bulk import bugs from other platforms to migrate your existing issue tracking data into Bugnet. Supported sources include:

• GitHub Issues
• GitLab Issues
• Jira
• Trello
• CSV file
• Other (generic format)

Imports go through POST /api/projects/:slug/import with up to 500 bugs per request, mapped from your source into Bugnet’s fields. Imported bugs keep their original external IDs and URLs, so you can always trace a bug back to its source; GET /api/projects/:slug/imports lists them. Imported bugs do not trigger notifications.

Export

Export your bugs to CSV for reporting, backup, or migration purposes. Exports can be filtered to include only the data you need:

• Filter by status (open, in progress, resolved, closed, won’t fix)
• Filter by priority (critical, high, medium, low)

Exported CSV files have these columns: Number, Title, Description, Status, Priority, Category, Platform, Version, Reporter, Assignee, Upvotes, Private, Created, Updated, Resolved. Custom field values are not included.