nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Is there a way to define an "auth callback" at an incoming Jira webhook?

I guess this is some combo of "feature request" and "seeking implementation advice". If webhooks are only returning 2xx status codes then we need some other way to retain server-side observability over webhook auth. I'm not sure if Atlassian has provided any standard recommendations on achieving this or on migrating away from 4xx auth verification (and to be fair there are potentially lots of strategies…)

What I'm looking for is a way to attach an "auth callback" to a given incoming Jira webhook which is guaranteed to fire after the auth step (ideally, in both success and failure cases). This to me seems to be the logical alternative to retain server-side observability over webhook auth, when only 2xx status codes are available.

Does such a thing exist? I can cobble together a "success callback" manually by adding an http callback as the first authenticated step of the webhook automation. However I am still missing a "failure callback". The closest I can think of is to use some server-side listener timeout as an indirect proxy for auth failure. This approach is quite fine for asynchronous logging and notification but less suitable if it is directly relevant to returning a response to a user (e.g. to unambiguously tell them their form submission failed because of some downstream auth error).

Accepted answers

All comments

Ah, I can already think of another cobbling together — remove the webhook token altogether and instead send the token in the body. At Jira's end, manually compare the received token to the stored token. Then hit the callback endpoint with the success or failure. After this request, only continue to execute the remainder of the webhook if the auth was successful.

Very pretty! But seems like something that should rather be natively implemented using the standard header auth.

Viswanathan Ramachandran

Hi,

No, it does not exists. Incoming webhooks are decoupled. If authentication fails, the request is dropped before the automation engine ever runs, so there is no rule context available to trigger an outbound notification or callback.

As a workaround, you can use REST APIs, or API gateway like AWS Lambda.

Forge using the webtrigger module is one option if you're setting up custom logic on the Atlassian side.

Narek Pirumyan

Hi @IL,

Short answer: it doesn't exist, and I wouldn't expect it to change.

Atlassian does this on purpose. If a request has no token, the endpoint returns a 400. If the token is wrong, it returns a 200, runs nothing and writes nothing to the audit log. Atlassian's reasoning is security: an endpoint that answers "wrong secret" would help attackers guess credentials by brute force. Their own KB article says the HTTP code isn't a reliable success indicator. So an auth failure never reaches the automation engine, and there's no rule context to hang a callback on. I'd expect this to stay as it is.

I agree with @Viswanathan Ramachandran: the cleanest fix is to put your own auth layer in front of the rule, and Forge is a good fit. A Forge web trigger gives you a URL where you can check the secret yourself, return real 401/403 responses, log every attempt, and only then pass valid requests on to your automation rule.

You may not even need to open a code editor. Rovo Studio can build Forge apps from a plain-language prompt:

https://community.atlassian.com/forums/discussion/3248678/5-new-ways-to-build-forge-apps-in-rovo-studio-build-visually-stay-in-the-flow

Here's a prompt you can paste in as a starting blueprint:

Build a Forge app with one web trigger (dynamic response) that works as an authenticated front door for a Jira Automation incoming webhook.

**Behavior:**
1. Accept POST only. Return 405 for any other method.
2. Require two headers: `X-Timestamp` (unix seconds) and `X-Signature` (hex HMAC-SHA256 of `timestamp + "." + rawBody` using a shared secret).
3. If either header is missing, return 401 with JSON `{error, requestId}`.
4. If the timestamp is more than 5 minutes old, return 401 (replay protection).
5. Recompute the signature and compare it in constant time (`crypto.timingSafeEqual`, checking lengths first). If it doesn't match, return 403.
6. Accept two secrets (current and next) so I can rotate without downtime.
7. If auth passes, forward the JSON body plus the `requestId` to my Jira Automation incoming webhook URL, sending the automation token in the `X-Automation-Webhook-Token` header. Return 202 `{status: "accepted", requestId}`, or 502 if the webhook call fails.
8. Log one structured line per request with the `requestId` and the outcome (`auth_missing`, `auth_stale`, `auth_failed`, `forwarded`). Never log secrets or tokens.

**Config:** store the shared secrets, the webhook URL and the webhook token as encrypted environment variables, not in code. Declare the external fetch permission for the Automation webhook host.

**Optional alternative:** instead of forwarding to Automation, create the Jira issue directly through the Jira REST API (as the app) and return the issue key in the response, so the form can show the user a real result.

Optional alternative: instead of forwarding to Automation, create the Jira issue directly through the Jira REST API (as the app) and return the issue key in the response, so the form can show the user a real result.

Two tips. Pass the requestId into your rule and log it there as well, so you can match your logs with the audit log. And treat the webhook's 200 as "received", not "rule succeeded".

It's also worth voting on AUTO-4 (more auth options for incoming webhooks), and filing a separate suggestion for auth-failure visibility, since I couldn't find one.

Hope that helps.

Keep us updated on what solution you decided to apply.

Cheers,

Narek

Thanks Narek— not sure if this answers my question, I'm familiar with the 200/202 client-facing obfuscation. What I'm talking about is a backend, asynchronous authorisation callback to a fairly well restricted app context, which the original actor has no idea about even in principle.

Edit: but I like the forge layer, I think that might do the trick. The key is that I need somehow to check the secret's validity (it does beg the question a little bit of where the obfuscation ends up if there is still a URL somewhere that returns 4xx…..)

Narek Pirumyan

Thanks for the clarification @IL

Natively, Jira has no such hook. A request that fails the token check is dropped before any rule context exists, so there's nothing on Atlassian's side to call back from. A backend auth signal can only come from a layer in front of the webhook. For example, a Forge web trigger or a small gateway could check the secret itself, return the same bland 200 either way, and quietly notify your restricted backend on failure. The caller would never know.

To make sure I point you in the right direction: could you describe the use case a bit more? Who or what is calling the webhook (a form, an external system, a partner), what do you need to happen when auth fails, and does the sender have to keep calling the Jira webhook URL directly?

Yep for sure, I understand your first point. Just to emphasize a bit, I'm not seeking to 'beat' or override the client-facing obfuscation by any means, only to come up with an appropriate backend auth signal that I can ingest via a serverside callback.

My use case is something like this: a user submits a form and a backend server passes it on to the Jira webhook with its stored secret. What I would like is to be able to unambiguously report back to the user if the 'lodgement' (webhook submission) immediately fails because of an auth issue in the response (say the secrets were rotated out of sync or expire by mistake). With classic 4xx status responses this is possible. I guess if I really need to I just convert everything in the backend to sync api actions to achieve something similar.

However if it's possible to have the secret currently stored by a server tested with explicit auth error codes through an independent web trigger before making the webhook call, that solves my problem very nicely! I'll look into the Forge web trigger approach, thanks for pointing it out.

Narek Pirumyan

Thanks @IL, that makes the use case clear, and I think the Forge route fits it well.

Point your backend's webhook URL and secret at a Forge web trigger. It checks the secret and returns real 401/403 responses, so you can tell the user straight away.

One caveat: if the Automation token itself expires, Forge won't know either, since Automation still answers 200. To cover this 100%, you may end up building the automation logic directly in the Forge app (e.g. creating the issue via the Jira REST API). That could even be the better decision: with Atlassian's usage-based billing for automations, moving your heaviest rules into custom Forge apps may be worth it if your site relies heavily on automation.

If this answers your question, please mark it as answered so others with the same use case can find it.

Viswanathan Ramachandran

Hi @IL

On top of what @Narek Pirumyan said.. and to address your queries..

Yes, you can definitely use the Jira REST API as your immediate bridge solution while building out your Forge app.

In fact, this is the most reliable way to get synchronous error handling right now. Here is how to handle it safely and effectively:

Route through a backend (Do not call Jira directly from frontend code):
To keep your Jira API token secure, have your form submit to your own backend or a lightweight serverless endpoint (e.g., AWS Lambda). Never expose API tokens or basic auth in client-side.
Get immediate, synchronous feedback:
When your backend calls POST /rest/api/3/issue, it can return this directly to the user form in real time, completely bypassing the blind 200 OK limitation of automation incoming webhooks.
In Summary: Use your backend + Jira REST API today for synchronous auth/error handling, and migrate the endpoint logic into a Forge webtrigger once your Forge app is ready to deploy.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

webhook