Jira Webhooks: Send Jira Cloud Events to Sazabi

Webhook facts checked on the platform’s docs on Nov 8, 2026.

Jira Cloud can call a URL whenever an issue, comment, sprint or project changes. Atlassian's support docs describe these webhooks as user-defined HTTP POST callbacks that push changes out without polling. This page shows how to aim them at Sazabi.

What Jira sends

The webhook documentation lists the events by the name that appears in the webhookEvent field. Issue events are jira:issue_created, jira:issue_updated and jira:issue_deleted. Others include comment_created, comment_updated, comment_deleted, sprint_started, sprint_closed, project_created, board_created and the jira:version_* family.

An issue event body is a JSON object with timestamp, webhookEvent, issue_event_type_name, user and issue. The issue object has the same shape as the REST API's issue response. For jira:issue_updated there is also a changelog array with one entry per changed field.

Why send it to Sazabi

Tickets are a timeline of decisions: who moved an incident to Done, which bug was reopened after a release. Sazabi's Webhook Events source stores each JSON payload as a searchable log record under webhook.* attributes, so that timeline sits next to your logs. When an error appears after a deploy, you can look for tickets created or reopened in the same window.

Use a path suffix to label the stream. Appending /jira to the intake URL stores webhook.path as /jira on every record, which separates Jira events from other sources on the same intake.

Set it up in Jira

You need the Administer Jira global permission.

1. Choose Settings, then System. Under Advanced, select WebHooks.
2. Create a new webhook and give it a name.
3. Enter your Sazabi intake URL with the /jira suffix. Jira accepts only HTTPS URLs on a fixed list of ports that includes 443.
4. Choose all events or a specific set. If you only care about one project, add a JQL filter. Only some events support JQL.
5. Optionally generate a secret. Jira then signs each delivery in the X-Hub-Signature header.
6. Save, then change an issue to produce the first event.

Jira follows up to five redirects per URL. Keep the intake URL free of redirects anyway, because Jira treats any response other than 200 as an unsuccessful attempt.

Example payload

An abbreviated jira:issue_updated body using field names from the Jira docs. It is an example, not a captured delivery.

{
  "timestamp": 1606480436302,
  "webhookEvent": "jira:issue_updated",
  "issue_event_type_name": "issue_generic",
  "user": { "accountId": "5b10a2844c20165700ede21g", "displayName": "Sam Rivera" },
  "issue": {
    "id": "10002",
    "key": "OPS-142",
    "fields": { "summary": "Checkout 500s after deploy", "status": { "name": "Done" } }
  },
  "changelog": {
    "id": 10124,
    "items": [{ "field": "status", "fromString": "In Progress", "toString": "Done" }]
  }
}

In a Sazabi thread, search for a top-level field such as webhook.webhookEvent to isolate one event type.

What to watch for

• Delivery failures. Jira retries on 408, 409, 425, 429 and 5xx responses and on connection failures or timeouts. Other 4xx responses aren't on that list, so a misconfigured URL can fail without retries.
• Duplicates. A retry can follow a delivery whose acknowledgment failed. Jira adds an X-Atlassian-Webhook-Identifier header that stays the same across retries, and an X-Atlassian-Webhook-Retry header on retried sends. Those are headers, so rely on body fields such as timestamp and issue.key if you dedupe in a query.
• Bulk edits. A bulk operation adds a bulkOperationMetaData field to the body. Expect a burst of events after a bulk change.
• Volume gaps. If a busy project goes quiet in Sazabi, open the webhook in Jira administration first. Then check the Intake page for the source's ingestion volume.
• Allow lists. Jira documents IP address ranges for outgoing connections that you may need to allow.

Retries

Jira resends a failed webhook up to five times, with each attempt delayed by a randomized back-off of 5 to 15 minutes. Webhooks that still fail after the last retry can be listed with the Get failed webhooks operation in the Jira REST API. Jira also notes that if a recipient hasn't answered successfully within 30 minutes, it sends only a single attempt per webhook until one succeeds, so a long outage can leave holes in your records.

If you also track code changes, the GitLab page covers merge request and pipeline events, and DocuSign covers envelope events from contract workflows.