Integrations

Proba.run can connect to the tools your team already uses: bug trackers, chat channels, and outbound webhooks, plus a set of built-in AI features. This page covers what each integration does and how to set it up.

Connecting an integration

Open a project's Settings → Integrations tab (an admin or tester can manage this). Add an integration, choose its type, give it a name, and fill in its connection details:

• Webhook — a URL to receive events, with an optional signing secret
• Slack / Teams — an incoming webhook URL for a channel
• GitHub — a personal access token, repository owner and name, and optional labels to apply to created issues
• Jira — your Jira base URL, account email, API token, and project key
• Productive — an API token, organization ID, and task list

You can add several integrations of the same type to a project — for example, separate Slack channels for different teams, or both a staging and production webhook. Secret fields (tokens, webhook URLs) are write-only: once saved, the form only shows that a value is set, never the value itself. Leaving a secret field blank when editing keeps the existing value, so you don't have to re-enter it just to change something else. Use "Test connection" to confirm the details work before relying on the integration, and the switch on each integration to pause it without deleting its configuration.

Outbound webhooks

A webhook integration can subscribe to any combination of events across:

• test cases and folders (including deletions and restores)
• test runs (created, completed, reopened, deleted, assigned)
• test results
• test plans, milestones, tasks, requirements, shared steps, and configurations
• new members added to the project

Pick the events you care about when creating or editing the integration — a webhook only needs to send what you'll actually use downstream.

Each delivery includes headers identifying the event and a unique delivery ID, plus an HMAC signature header when you've set a signing secret, so your receiving endpoint can verify the request came from Proba.run. Failed deliveries (network errors, timeouts, or a 5xx/429 response) are retried automatically a few times; a 4xx response is treated as final and isn't retried. Every delivery attempt — success or failure — is recorded in a delivery log on the integration, where you can inspect what was sent and manually redeliver a failed event once the problem on your end is fixed. The log keeps roughly the last month of history.

Chat notifications (Slack and Teams)

Slack and Teams integrations post formatted messages to a channel when a run is created, completed, or assigned, or when new members are added to the project. Choose which of these events each integration should post — a busy team might only want run completions in a shared channel, for instance, while a QA channel also wants assignments. Messages include a link back to the relevant run or project when your instance is reachable at a public address.

Sending bugs to your tracker

From any test result, a tester can click "Create bug" to open a new issue in a connected GitHub, Jira, or Productive integration (the button only appears when a matching integration exists). If you have more than one matching integration, you pick which one to use. The dialog pre-fills a title and description from the case and result — edit them as needed before submitting. Once created, the issue link is saved and shown under "Related bugs" on that test result, so you don't lose track of it after closing the dialog.

Keeping bug status in sync

Once a bug link exists, Proba.run shows whether the underlying issue is still open or has been closed, without you needing to visit the tracker. The status refreshes automatically in the background when you view a stale link, and you can force an immediate refresh with the "Refresh statuses" button on a test result or on a run's page — the latter updates every linked bug in the run at once. Runs also show an indicator next to any test case that still has open bugs, so a lead can see at a glance where re-testing is still needed before signing off.

In-app notifications

The bell icon in the header shows a count of unread notifications: when you're added to a project, assigned to a run or a test case, mentioned in a comment, or when a run you're involved with is closed. Click the bell for a quick panel, or open the full notifications page for your complete history with pagination. The panel also surfaces upcoming and overdue milestone deadlines across your projects, so you don't have to check each project separately. Mark individual notifications as read by clicking them, or clear everything at once.

AI features

An organization admin configures an AI provider (Anthropic, OpenAI, Google Gemini, or any OpenAI-compatible provider) and its API key on the organization's AI settings page. Until that's done, none of the AI controls below appear anywhere in the product. Once enabled, they show up automatically wherever they apply:

• Case generation — from a requirement, generate up to 10 draft test cases with titles, steps, and priorities. Review them, check the ones you want, and accept — only the ones you select are created, as draft cases linked to that requirement.
• Converting freeform steps — a case written as plain-text steps can be converted into structured step/expected-result pairs with one click, then reviewed before saving.
• Coverage analysis — for a task, get a per-requirement verdict (covered, partially covered, or a gap) with suggested missing scenarios, plus detection of duplicate or overlapping test cases among that task's linked cases. The analysis is read-only and isn't saved — re-run it any time to get a fresh read.

AI results are never applied automatically: generated cases, converted steps, and coverage findings all require you to review and accept them before anything changes. To keep things responsive for everyone, AI actions and connection tests are limited to a modest number of requests per minute per person.