Integrations

Connect OMG QA to where your team already works

Findings don't live in a vacuum. OMG QA connects to GitHub, Jira, GitLab, Azure DevOps, and Slack — each over OAuth with a verified inbound webhook, no long-lived tokens. A finding stays in sync with the issue, work item, or merge request it maps to, and the right channel hears about it. You connect in your workspace under Settings → Integrations.

🔌 Connect (OAuth) → 🔁 Two-way sync → ✅ Retest on merge · notify out

⎇ GitHub

Connect through a one-click GitHub App — no personal access tokens, no manual webhooks. Once installed on the repos you choose:

Link a pull request to a finding (or let an agent do it); the finding shows the PR's live state.
When the fixing PR merges, the linked finding moves to Ready for retest.
Open a GitHub issue straight from a finding, using the installation's own short-lived token.

Full GitHub setup guide →

🟦 Jira

Two-way sync between findings and Jira issues:

Outbound: push a finding to Jira as an issue — created once, then updated idempotently (one issue per finding), with its workflow status transitioned to match the finding via a configurable status map.
Inbound: a secret-verified Jira webhook maps a Jira status change back onto the linked finding.
An out-of-band edit on the Jira side is surfaced as a conflict for review rather than silently overwritten.

🦊 GitLab

Mirror the GitHub flow on GitLab:

Link a merge request or pipeline to a finding.
A merged MR moves its linked findings to Ready for retest; pipeline events update the linked pipeline's recorded state.
The inbound webhook is token-verified and binds the tenant itself — idempotent.

🔷 Azure DevOps

Two-way sync between findings and ADO work items:

Outbound: create / update an ADO work item from a finding (one item per finding, idempotent).
Inbound: a secret-verified service hook (work-item-updated / pipeline-completed) updates the linked finding.
Divergent edits on the ADO side surface as a conflict rather than an overwrite.

Ingest test results from Azure Pipelines — no GitHub needed. After your tests write a JUnit/TRX report, POST it to the import endpoint; OMG QA opens a run, turns failures into findings, and feeds flaky-test detection. The endpoint auto-detects JUnit, TRX, NUnit & Allure.

# azure-pipelines.yml — after the test step - script: | curl -sS -X POST \ "https://api.omgqa.com/api/v1/projects/$(OMGQA_PROJECT_ID)/test-runs/import?format=junit&branch=$(Build.SourceBranchName)&commit=$(Build.SourceVersion)&ciUrl=$(Build.BuildUri)" \ -H "Authorization: Bearer $(OMGQA_API_KEY)" \ -H "Content-Type: application/xml" \ --data-binary @"$(System.DefaultWorkingDirectory)/test-results/junit.xml" displayName: Send test results to OMG QA condition: always()

Create a project-scoped API key under Account → API keys and store it as the secret pipeline variable OMGQA_API_KEY.

💬 Slack

Keep the team in the loop and let them act without leaving Slack:

Notify: new and updated findings (type / severity / status / link) post to a configured channel with inline Acknowledge, Assign-to-me, and Resolve buttons.
Act: a signature-verified button click runs as the mapped OMG QA member with their real permissions — out-of-band users get nothing — and every action is audited.

How they connect. Each connector uses OAuth and a verified inbound webhook; secrets are encrypted at rest and OMG QA never holds a long-lived password. Driving findings from an AI agent instead? See the MCP guide. Prefer plain HTTP? Everything is in the API reference.