Developer docs
Issue tracker sync
Your developers keep their tracker. Every issue a tester reports is pushed there as a ticket with the evidence link, and every status change follows as a comment. With sync back the tracker talks back: a task marked done in Asana, a work item resolved in Azure DevOps, an issue closed on GitHub, moved to Done in Jira or Linear, marks the issue Fixed here and asks the reporter to re-check, and the reporter's answer goes back to the task. Connections live under Settings → Integrations; sync back is a card under each connection.
Fixed is a claim. Verified is evidence.
A tracker can tell DeploySeal that a developer believes the work is done. Only the person who reported the issue can say it is verified, and only a member can close it without that. No tracker event ever moves an issue to Closed, Won't fix or Duplicate. The sealed record keeps saying who verified what.
What the tracker can change here
| In the tracker | The issue becomes | Notes |
|---|---|---|
| Task marked done | Fixed, then Retest requested | The reporter is emailed to re-check. Off by choice: the issue stops at Fixed and someone requests the retest here. |
| Task marked done after a failed re-check | In progress → Fixed → Retest requested | The developer tried again. The failed re-check stays on the trail. |
| Task reopened | In progress, only from Fixed | A re-check already in flight is never pulled back; a verified or closed issue never reopens from a tracker. |
| Comment on the task | Internal comment on the issue | Named “Marc Patel · Asana”. The reporter is not emailed tracker chatter. |
| Assignee changed | Issue assigned to the matching member | Matched by email. No match, no change. |
| Anything else | Nothing | No tracker event ever reaches Closed, Won’t fix or Duplicate. |
Every answer is idempotent: a “done” on an issue that is already Fixed does nothing, a redelivered event is harmless, and DeploySeal's own writes into the tracker come back as no-ops. The record names the tracker and the person: “Marked complete in Asana by Marc Patel”.
What DeploySeal writes into the tracker
| In DeploySeal | The tracker gets | Notes |
|---|---|---|
| Issue filed | A task or ticket | Severity, page, browser, steps and the evidence link. |
| Status changes | A comment | Every status, so the ticket reads as a log. |
| Re-check: still failing | Task reopened + comment | With the reporter’s words and the link. Sync back only; a comment only if you turn reopening off. Azure DevOps: the work item goes back to its first in-progress state (Active, Doing, In Progress). Jira: a transition into an In Progress status, else To Do. Linear: the first started state, else unstarted. |
| Re-check: fixed, or closed | Task completed + comment | Sync back only. Azure DevOps: the work item moves to the first of your fixed states the type has, preferring a completed one (Closed, Done). GitHub: the issue is closed as completed. Jira: a transition into a status you named, else into Done. Linear: the state you named, else the team’s completed state. |
| Comment written in DeploySeal | The same comment on the task | Sync back only, when mirroring is on. |
Text DeploySeal writes carries an invisible marker, so a comment that comes back through the webhook is recognised as its own and never imported twice.
The sync back card
- Sync back — switching it on registers DeploySeal's webhook with the tracker. Asana listens to one project, so the connection needs a project chosen. Azure DevOps listens to the connection's project through two service hooks (work item updated, work item commented); the token needs Work Items read & write and the project's Edit subscriptions permission. GitHub listens to the repository through one webhook (issues, issue comments); a fine-grained token needs Webhooks read & write on the repository, a classic one admin:repo_hook. Linear listens to the team through one webhook (issues, comments); only a workspace admin's API key can create it. Jira Cloud gives an API token no way to create a webhook, so turning sync back on shows a URL and a one-time secret: a Jira admin pastes both into Settings → System → WebHooks (events Issue: updated and Comment: created, JQL filter project = KEY). New secret makes another pair.
- What counts as fixed — Asana: the task marked complete, or moved to a section you name (“Done”, “Ready for QA”). Azure DevOps: the work item entering one of the states you list, “Resolved, Closed, Done” by default; leaving them all reopens. GitHub: the issue closed as completed (closing as “not planned” does nothing), or a label you name added; removing it reopens. Jira: the issue entering a status whose category is Done, or one of the statuses you name; leaving reopens. Linear: the issue entering a completed state, or one of the states you name; leaving reopens, Canceled does nothing.
- Ask the reporter to re-check automatically — on by default.
- Reopen the task when the re-check fails — on by default; off means a comment only.
- Mirror comments — both directions; tracker comments arrive as internal comments.
- Status — “Listening since …, last event …” or the last error, with Reconnect to register the webhook again.
Trackers
| Tracker | Issues become | Sync back |
|---|---|---|
| Asana | Tasks in a workspace or project | Available now: task marked complete, or moved to a section you name |
| Azure DevOps | Work items (Bug by default) with Priority and Repro Steps | Available now: work item moved to one of the states you name, default Resolved, Closed, Done |
| GitHub | Issues with deployseal and severity labels | Available now: issue closed as completed, or a label you name added |
| Jira Cloud | Issues (Bug first) with priority and labels | Available now: issue moved to a Done status, or to a status you name. A Jira admin pastes the webhook URL and secret once. |
| Linear | Issues with priority from severity | Available now: issue moved to a completed state (Done), or to a state you name. The API key must be an admin’s. |
Slack and Microsoft Teams are notification channels, not trackers: they receive cards and do not change issues. See the Slack and Teams guides.
How the webhook is secured
Every delivery proves it comes from the tracker. Asana signs it (HMAC-SHA256 over the raw body) with a secret it presents during the registration DeploySeal initiated, and only then. GitHub and Linear sign the same way with a 256-bit secret DeploySeal generates and hands over when the webhook is created; Jira signs with the secret the admin pasted, which DeploySeal generated and showed once. Azure DevOps service hooks cannot sign, so the same kind of secret rides back as a header on every call, compared in constant time. Either way DeploySeal verifies before anything else, queues the delivery durably and answers at once, and applies the events off the request with the same retries as every other outbound job. The secret is encrypted at rest with the same key as the token and is never shown. Every applied change, and every rejected delivery, is in the audit log.
Connections and sync back live in your workspace settings.
Open integrationsNeed raw events for your own tooling? See the webhook reference and the API reference.