Skip to main content

Create a Webhook in Jira for Status Sync with Hyver

Learn how to create a Jira webhook that updates Hyver when an issue's status changes.

Updated over 4 months ago

Overview

This article shows you how to set up a webhook in Jira that notifies Hyver when an issue’s status changes. This lets you keep Hyver updated in real time — without writing any custom code.

You’ll need Jira admin access and a Hyver access token to complete the setup.


1. Generate or locate your Hyver access token

To send authenticated requests from Jira to Hyver, you’ll need a valid access token.

  1. In Hyver, go to Settings > Access Token.

  2. Create a new token, or copy an existing one.

  3. If you are copying an existing one, Copy the token value and the following URL:

    https://customer.hyver-labs.com/api/v1/finding/jira/status

You’ll use both when setting up the webhook in Jira.


2. Set up the Jira automation rule

To set up the Jira automation rule, you need permission to create automation rules in that specific project — nothing more, nothing less.

In your Jira project:

  1. Go to Project Settings > Automation.

  2. Click Create rule.

  3. Add a Field value changed trigger:

    • Field to monitor: Status

    • Change type: Any changes to the field value

      • This lets Hyver match status updates based on the mapping you’ve defined there.

      • You can also add a filter to limit the rule to a specific project. Just note that this rule works at the project level in Jira — not per individual issue. If you don’t filter it, the rule may apply across all projects.

    • For: All work item operations

Here's an example of how the Field value changed trigger should look in Jira:


Then:

  1. Add a Send web request action:

    • URL: https://customer.hyver-labs.com/api/v1/finding/jira/status

    • HTTP method: POST

    • Web request body: Issue data (Jira format)

    • Enable: Delay execution of subsequent rule actions until we’ve received a response

    • Add the following header:

      • Key: Authorization

      • Value: Token <your-token-here>

Here's an example of what the web request configuration should look like when sending data from Jira to Hyver:

(Optional): Add a third action to log the webhook response: Use the audit log component to log {{webResponse.status}}


Two key things to know about these checkboxes:

  • Delay execution setting: Make sure to check the box labeled: “Delay execution of subsequent rule actions until we’ve received a response.”

    • This prevents Jira from moving on before the webhook finishes. Without this, Jira might wait on background processes that never complete — which can silently break the sync.

  • Logging the response: The webhook response isn’t required for Hyver to process the update.

    • Logging it is optional and only helpful if you want to monitor whether the webhook request was successful (e.g., for debugging or auditing purposes).


Important notes

  • Permissions: You don’t need to be a Jira admin. You just need permission to create automation rules within the specific project. If you can already create rules in that project, you're good to go — no extra admin access required.

  • Token security: Treat your Hyver access token like a password. Store it securely and rotate it periodically.

  • Payload format: Jira sends the full issue context as JSON. No additional formatting is needed.

  • Trigger scope: This rule runs on any status change by default, but you can narrow it down using filters if needed.

It’s important to note that only issues created by Hyver can be updated through this webhook. If the issue wasn’t originally created by Hyver, the status change won’t be processed.


Wrap-up / Next Steps

That’s it — no scripts, no extra logic. Just a simple automation rule that syncs status changes directly to Hyver.

If you're coming from the ServiceNow integration, you'll notice that Jira doesn't require any scripting. Its built-in automation features make setup smoother and more accessible.

Feel free to test it, tweak it, or filter for specific transitions — whatever fits how you like to work.

Did this answer your question?