Jira Cloud Integration

Route AllyProof violations into Jira Cloud — one site per Jira project, configurable severity threshold per site, optional auto-push when scans complete. When the Jira issue closes, the corresponding violation flips to resolved in AllyProof. The integration is built for agencies running multiple client sites on multiple Jira boards from a single connection.

What the integration does

  • Per-site routing.One AllyProof org connects to one Jira Cloud site, but each scanned website routes to its own Jira project. ACME's violations land on the ACME board, BetaCorp's on BETA — no shared dump.
  • Per-site severity threshold. Decide which severities flow to Jira on a site-by-site basis. Production can push everything; staging can push Critical only.
  • Three ways to push. A single-violation Push to Jira button on issue detail pages; a bulk Push N to PROJECTbutton on each site's page; an expandable picker for choosing exactly which violations to push from a scan.
  • Optional auto-push. Toggle on per site, and new violations sync to Jira automatically as scans finish. Forward-only by default — enabling auto-push never dumps the historical backlog.
  • Status sync back.When a Jira issue moves to a status in Jira's Done category, AllyProof marks the linked violation resolved. Other transitions are left to your team.
  • Idempotent and loop-safe.Re-pushing a violation returns the existing Jira key — never a duplicate. Changes we make via the API are tagged so an incoming webhook on our own edit doesn't re-fire the sync.

Prerequisites

  • You're an Owner or Admin in AllyProof. Members can use the push button once the connection exists, but only an admin can connect, configure sync rules, or disconnect.
  • You have a Jira Cloud site (your-org.atlassian.net) and permission to create issues in every project you want to route to. Jira Server and Data Center are not currently supported.
  • The Atlassian account you use to connect can grant the scopes: read:jira-work, write:jira-work, read:jira-user, and manage:jira-webhook.

Connect Jira

  1. Go to Settings → Integrations.
  2. Click Connect Jira. You'll be redirected to Atlassian's consent screen.
  3. Grant the requested scopes. You'll land back on the Integrations page with a "Connected" badge.
  4. New connections start with every site opted out. This is deliberate — it prevents the integration from auto-routing every site to a single project the moment OAuth completes. Continue to Configure sync rules below to enable the sites you want.

Configure sync rules

On the Integrations page, the Sync rules section lists every active site in your org as a row with four controls:

  • Site checkbox. Off means this site is excluded from Jira sync entirely — no manual or auto push will do anything until you tick it.
  • Jira project. The project key (e.g. ACME, WEB, SCRUM) where this site's violations should land. Find it in Jira under Project Settings → Details. A site can't push without one — the row shows an amber warning if blank.
  • Severities. Per-site picker for Critical, Serious, Moderate, Minor. Only violations whose impact matches one of the ticked levels can flow to Jira for that site. Most teams gate on Critical + Serious to keep Jira focused on remediation work that matters.
  • Auto-push. Off (default) means new violations stay in AllyProof until someone clicks Push. On means new violations push automatically when each scan completes — see Auto-push below for the forward-only safeguard.

Click Save sync rules after making changes. The button only enables when something has changed and every active site has a project key.

Pushing violations

Per-violation button

On any issue detail page, click Push to Jira. The button is replaced by a direct link to the created issue once the call completes (usually under two seconds). Subsequent loads of that violation show the Jira key instead of the push button. The button is automatically disabled with a tooltip when:

  • The site is excluded from sync
  • The site has no Jira project key configured
  • The violation's severity is below this site's threshold

Bulk push from a site

On every site's page (after a scan completes), a Jira syncblock summarises that site's relationship to Jira:

  • N violations ready to push to PROJECT. Click Push N to PROJECTto ship every matching unpushed violation in one go. Pushes are paced (~150 ms apart) to stay under Jira's rate limits.
  • M already linked. Violations that already have a Jira ticket from prior scans are surfaced for transparency but not re-pushed.
  • All matching violations are in PROJECT.Quiet confirmation when there's nothing pending.

Per-violation picker

Inside the bulk-push block, click Choose violations to expand a checklist. Every pushable violation is listed with its severity badge, description, page count, and WCAG tags; all rows are pre-selected so the default behaviour matches the collapsed button. Untick any rows you want to skip — the primary action becomes Push N selected. The server re-validates each id against your sync rules so a stale tab can't bypass them.

Auto-push

When a site has auto-push On, every new violation detected in a scan that matches the site's rules gets pushed to Jira automatically as the scan completes. Three guarantees:

  • Forward-only. Enabling auto-push stamps a since timestamp; only violations first detected at or after that moment are eligible. The historical backlog is left to manual / bulk push, so flipping the toggle never dumps 200 tickets into Jira at once.
  • Same rules apply. Auto-push goes through the same per-site project, severity, and exclusion gates as the manual flow. If you tighten rules, the change applies to the next auto-push immediately.
  • Idempotent. The same dedupe key is used as for manual pushes; a re-scan that re-detects the same violation never creates a duplicate ticket.

Toggling auto-push Off stops the automation immediately. Re-enabling later sets a fresh since cutoff — the time between off and on is treated as backlog, not auto-pushed retroactively.

Status sync back to AllyProof

When the Jira issue's status category moves to Done, AllyProof flips the linked violation to resolved. Nothing else in Jira is interpreted — we deliberately don't mirror Jira's In Progress back to our workflow because your AllyProof team might already have moved the issue there via the dashboard, and two-way live mirroring in that middle state is the classic source of drift.

Authentication, tokens, and security

  • We use Atlassian's OAuth 2.0 (3LO) flow — no API tokens, no shared passwords.
  • Access and refresh tokens are encrypted at rest (AES-256-GCM) with a server-managed key before hitting the database.
  • Atlassian's refresh tokens rotate on every use; we re-persist the new pair atomically, so a replayed old refresh is rejected.
  • Inbound webhooks from Atlassian carry a JWT signed HS256 with our app's client secret — we verify it before touching the request body, and deduplicate on (event + issue + timestamp) so a replay doesn't re-apply a status change.

Disconnect

Under Settings → Integrations, click Disconnect Jira. The connection is soft-deleted (we keep the row for audit), tokens are revoked on our side, the inbound webhook is deregistered with Atlassian, and all push paths stop working immediately. Existing violation-to-issue links remain in AllyProof as historical records but no longer sync.

Limits and caveats

  • One Jira Cloud site per AllyProof org. Multiple projects within that site are fully supported via per-site routing.
  • Atlassian's dynamic webhooks expire after 30 days. We refresh them automatically on a schedule; no manual action required.
  • Bulk push is paced at ~150 ms between calls and respects Atlassian's Retry-After header on 429 with exponential backoff. For very large backlogs (hundreds of violations on first push), expect the batch to take a minute or two — it streams into Jira in the background and the page refreshes when complete.
  • Severity rule changes take effect on the next push (manual or auto). Already-pushed tickets are not retroactively recalled if you tighten the filter — the idempotency guarantee intentionally wins over after-the-fact rule changes.
  • Need help with a specific routing setup or running into a ban / 403 from Jira? Open a support request and we can look at the logs together.