Skip to main content

Integrations

Integrations push BugPort bugs into the issue tracker your engineers already live in. When a report lands in BugPort — from the widget, the browser extension, the API, or MCP — you triage it, then create a real issue in GitHub or GitLab from the bug's detail view. The generated issue carries the bug's context and a link back to BugPort, and that external issue link is shown on the bug so both sides stay connected.

In progress Connectors are being built. The flow and data model described below are real, but the providers are not generally available yet. This page is honest about what's done and what remains.

Why integrations exist​

BugPort is where bugs are reported and triaged; your issue tracker is where engineering work is planned and tracked. Rather than asking people to re-type a bug into Jira-style tickets by hand, integrations let you create a tracker issue from a BugPort bug in one action, preserving the captured context and keeping a durable two-way link. The goal is to remove the manual copy-paste step between "a user reported this" and "an engineer is working on it."

The connector approach​

BugPort uses its own connector abstraction. It does not embed a third-party automation engine — there is no general-purpose workflow runner under the hood. Each provider is a first-class, BugPort-owned client, which keeps the surface small, the security model explicit, and the issue body exactly what BugPort wants it to be.

The data model backing this already exists:

connector_accounts
A connected provider account for a workspace, including a base_url so self-hosted instances can be addressed.
connector_project_mappings
The mapping from a BugPort project to a specific repository or GitLab project, so "create issue from bug" knows where the issue goes.
external_issues
The record linking a BugPort bug to the issue created in the external tracker, which powers the external issue link shown on the bug.

The connector endpoints also exist today: GET /v1/connectors, the OAuth start/callback pair, a test endpoint to verify a connection, and POST /v1/bugs/{bug_id}/export to create the issue. See the API overview.

Supported targets​

The active targets are GitHub and GitLab. Others appear only as future registry entries.

🐙GitHub Issues

A GitHub App is the preferred connection: fine-grained, revocable, per-repo installation tokens rather than a broad personal token. You install the app on the repos you want BugPort to write issues into.

🦊GitLab.com

Connect via OAuth (or a personal access token) and map BugPort projects to GitLab projects.

🏢Self-hosted GitLab

Same flow as GitLab.com, plus a configurable instance base URL so BugPort talks to your own GitLab deployment.

💡
Jira, Linear, and Slack appear in the connector registry as future entries, but they are not active targets. Only GitHub and GitLab are being built right now. Do not plan on the others yet.

How the flow works​

  1. Connect a provider

    In the Integrations area, connect GitHub (via the GitHub App) or GitLab (via OAuth/PAT). For self-hosted GitLab, set the instance base URL. The connection is verified with the test endpoint before it's usable.

  2. Map a BugPort project to a repo or project

    Create a project-to-repo mapping so BugPort knows where issues from that project should be filed. A project maps to a specific GitHub repository or GitLab project.

  3. Create an issue from a bug

    Open a bug's detail view and choose Create issue from bug. BugPort exports the bug to the mapped repository and creates a real tracker issue.

  4. Follow the link back to BugPort

    The generated issue body includes a link back to BugPort, so anyone in the tracker can jump to the full captured context. In return, the external issue link is shown on the BugPort bug — the two records reference each other.

Integration flow​

What the generated issue includes​

The issue BugPort creates is meant to be actionable on its own while still pointing back for the full record. It should carry:

  • A clear title derived from the bug.
  • The reporter's feedback text and the bug's status/severity.
  • Key page context (the path or URL where the issue occurred) to help reproduction.
  • References to captured media and debug context (screenshots, logs, network) that live in BugPort.
  • A prominent link back to the BugPort bug for the complete, interactive context.

Heavy media and debug payloads stay in BugPort (backed by Cloudflare R2); the issue links to them rather than duplicating large binaries into the tracker.

What's done vs remaining​

Being precise so you can plan around it.

Already in place

  • Connector data model: connector_accounts (with base_url), connector_project_mappings, external_issues. Done
  • Connector endpoints: GET /v1/connectors, OAuth start/callback, test, and POST /v1/bugs/{bug_id}/export. Done

Remaining work

  • Provider issue-create clients (the GitHub/GitLab calls that actually file the issue). In progress
  • Encrypted token storage for connector credentials. In progress
  • Status and comment sync-back from the tracker to the bug. Planned
  • Disconnect / revoke a connected provider. Planned
  • The Integrations dashboard page to manage connections and mappings. In progress
Not yet available

Do not treat GitHub or GitLab issue creation as a shipped feature. The data model and endpoints are scaffolded, but the provider clients, encrypted credential storage, and the Integrations dashboard page are still being built. This page describes the intended flow, not a feature you can rely on in production today.

Next steps​

🐞Bug reports

See what context a bug carries — the same context that flows into a created issue.

Understand the data🔌API

The connector and export endpoints behind integrations.

See the connectors API🔒Security

How connector credentials and workspace scoping are handled.

Review the model