> For the complete documentation index, see [llms.txt](https://docs.autommate.com/userguide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.autommate.com/userguide/start-here/use-cases/jira-xurrent-sync.md).

# Build a bidirectional Jira–Xurrent integration

Use a webhook-triggered Hyperflow to receive events, route them by source and create or update the corresponding record in the other system. The essential design is the correlation between records: without it, a creation in one system can trigger another creation repeatedly.

## Agree the mapping first

Choose one event type for the first version, such as request or issue creation. Define the Jira project and issue type, Xurrent account and request fields, required values, and which system owns each field after creation. Decide where to store the Jira issue key and Xurrent request ID together.

Configure [application credentials](/userguide/integrations-and-api/apps-connections-and-authentication.md) with access to the selected records. Use the [Jira Software](/userguide/integrations-and-api/libraries/integration/jira-software.md) and [Xurrent](/userguide/integrations-and-api/libraries/integration/xurrent.md) library references for the installed actions. If using a REST action, target the documented resource API; an outgoing webhook registration is not itself a create-record API.

## Receive the source event

1. Create a Hyperflow with a [webhook trigger](/userguide/integrations-and-api/webhooks-api-rules-and-responses.md). Copy its generated URL without reconstructing the path or authentication.
2. Register that URL as the callback for the chosen Xurrent event. Limit the source event scope to the records you intend to synchronise.
3. Create one approved test record and inspect the received payload in [Monitoring](/userguide/operate-and-troubleshoot/monitor-executions-and-retain-useful-evidence.md).
4. Register the Jira event callback. You can route both sources through one Hyperflow if its conditions distinguish the payloads explicitly; separate receiving flows are another design option.

Use the guide for your Jira edition: [Jira Cloud webhooks](https://developer.atlassian.com/cloud/jira/platform/webhooks/) or [Jira Data Center webhooks](https://developer.atlassian.com/server/jira/platform/webhooks/). The existing Xurrent example references the [Xurrent/4me webhook API](https://developer.4me.com/v1/webhooks/); use the endpoint and event schema applicable to your Xurrent environment.

## Route, map and correlate

```mermaid
flowchart TD
  A[Receive webhook] --> B[Validate source and event]
  B --> C{Known processed event or origin marker?}
  C -->|Yes| D[Skip duplicate creation]
  C -->|No| E{Correlated target record exists?}
  E -->|Yes| F[Apply permitted update]
  E -->|No| G[Create target record]
  G --> H[Store both record identifiers]
  F --> I[Record action result]
  H --> I
```

Inspect actual payloads before writing conditions. The documented Jira example uses `webhookEvent` to identify an event. Its Xurrent branch uses a `source` value to identify origin; treat that as an example mapping, not a guaranteed field in every Xurrent event. Reject unknown event shapes instead of sending them down the default write branch.

Map only the required fields initially. Preserve the source record ID and capture the target ID returned by a successful create action. For subsequent updates, locate the existing target through that correlation rather than creating again.

## Prevent echo events and retries from creating duplicates

The original example adds **Created from Xurrent** to a Jira summary and skips reverse creation when it sees that marker. That is a simple demonstration of origin detection. A production design should use a stable correlation field or record and handle duplicate event delivery even if someone edits the summary.

Jira Cloud can retry webhook delivery. Its `X-Atlassian-Webhook-Identifier` identifies the same webhook across retries; use this where your receiving design exposes the header and persist the processed-event decision as appropriate. This is a design requirement, not a claim that Autom Mate deduplicates every webhook automatically. See [Jira Cloud retry behaviour](https://developer.atlassian.com/cloud/jira/platform/webhooks/).

## Acceptance tests

Test creation in each direction, delivery of the same event twice, an echo event caused by your own write, an update of a correlated record, missing required data and target access denied. Confirm exactly one corresponding record exists and that failures are visible in the run log. Retry writes only after checking whether the target record was already created.