Integrations

How pushing works

Connect an integration to a project and every bug filed into that project is pushed automatically, as it arrives. There is no rule to write and no button to press.

Connect more than one and the bug goes to all of them — a Jira issue and a Slack message from the same report is the common setup, and it is what you get by connecting both.

The pushed issue carries the title, the description, the severity, the page URL, and the console and network lines that matter — the failing requests and the error output, not the whole buffer.

Connecting a tracker

All four start the same way, in the dashboard: open the project, then Settings → Integrations → Trackers & Data Sources, and pick a provider. You need the Admin role.

Credentials marked secret are write-only — once saved they come back as •••••••• and there is no screen that will show them to you again. To change one, type a new one over the mask; leaving the mask in place means "leave it alone".

Jira

Use a service account, not your own. Every issue will carry the identity of whichever account this token belongs to, and that account leaving the company takes the integration with it.

GitHub

Issues must be enabled on the repository. If they are turned off, the push fails with a 410 and the bug stays where it is.

Linear

Severity is mapped onto Linear's priority scale: critical → Urgent, high → High, medium → Medium, low → Low.

Slack

The URL is the channel — it is bound to whichever one you picked when you created it. To post somewhere else, make a second webhook.

Check it worked

• Save the integration. The page confirms it by name.
• File a test bug into that project — the widget, the extension or a curl all do.
• Within a few seconds the issue or message appears at the other end.
• The bug's timeline in BugCatch shows a pushed to … entry with the issue reference.

If nothing arrives, the timeline is where the reason is: a rejected credential or a missing repository is recorded there rather than silently dropped.

Sending status back — the tracker webhook

Traffic only goes one way until you do this. The engineer who actually fixes the bug closes a ticket in Jira, because that is where they already are, and BugCatch never learns: the bug stays open, the knowledge base never learns the fix, and the customer who reported it is never told.

One webhook fixes all of it. An issue reaching a terminal state settles the bug here, and everything downstream runs on its own — the resolution is stamped, the knowledge base is taught, the reporter's email goes out, and duplicates of it are cascaded.

1. Get the URL

   In Settings → Integrations → Trackers & Data Sources, open the connected integration and choose Webhook. You get a full address to paste, and a secret.

   For GitHub and Linear the URL is plain and the secret goes in the tracker's own signing field. For Jira — which signs nothing — the secret is carried in the URL itself, so treat that whole address as a credential.

2. Register it in the tracker

   See the per-provider steps below.

3. Test it

   Close the test issue you created earlier. Within a few seconds the bug in BugCatch should move to resolved, and its timeline should say the tracker closed it.

GitHub

Repository → Settings → Webhooks → Add webhook.

The body is verified against X-Hub-Signature-256, so an unsigned or mis-signed delivery is refused.

Linear

Settings → API → Webhooks → New webhook. Subscribe to Issues, and paste the secret into Linear's signing secret field — deliveries are verified against Linear-Signature. As noted above, the delivery is authenticated but will not currently match a bug.

Jira

Jira Settings → System → Webhooks → Create a WebHook. Paste the whole URL, including its ?token=…, and subscribe to Issue → updated. Scope it with a JQL filter of project = ENG so you are not sending every issue in the instance.

What is acted on, and what is deliberately ignored

Only a terminal transition and an explicit reopen. Everything else is dropped on purpose: Jira fires an update webhook when somebody edits a label, and a mapping that read "not done" as "open" would reopen a fixed bug every time a colleague tidied a field.

Status categories and state types rather than names, because every team renames "Done" to "Shipped" and adds three of its own — the category is the field that survives that. A cancelled Linear issue counts as finished: it is not coming back, and leaving the bug open forever waiting for it is the worse of the two wrong answers.

A delivery that arrives intact always gets a 200, even when there was nothing to do with it. Trackers disable an endpoint that keeps answering with errors, and "we have no bug for that issue" is not an error — it is every issue your team files by hand.

Slack has no webhook of its own, because a message has nothing to close. Connect Jira, GitHub or Linear to have a fix settle the bug.

Recording links

A URL you can send to anyone — a customer on the phone, a tester, a client — that lets them file a report into one project with no account, no extension and nothing embedded in your product. It is the fastest integration on this site, because there is nothing to integrate.

1. Create one

   Project Settings → Recording Link → Create. Optionally give it an expiry. You need the Admin role.

2. Send it

   The link looks like https://app.bugcatch.sphoro.com/report/<token>. Anyone holding it can file into that project — so treat it like a password, and give it an expiry when it is for one conversation.

3. What they see

   A page that records their screen, takes a description, and submits. They can prove their email address with a code if they want to hear back — and unlike an address that arrives through identify(), that one is proved rather than claimed.

4. Revoke it when you are done

   From the same screen. Revoking is immediate; existing reports are unaffected.

Which of these do you actually need?