Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

POST Web Request from Issue Created trigger fails

I have two rules, one that triggers when an issue is created and one that triggers when an issue is transitioned. Each trigger then is set up to make a POST request to a server running Python Flask with the issue information that we then do stuff with.

For some reason, the issue created automation always fails making the POST request with a 400 response code, but it doesn't look like the request even makes it to the server.

The issue transition automation always works and the server successfully gets the issue information.

The web request actions on the automation are identical as well. I am not sure what else to do to figure out why one action works and the other doesn't.

2 answers

0 votes
Stefan Salzl
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Apr 17, 2023

Hi @Liam Cuozzo 

Did you try to add a (or sometimes several) re-fetch data action? sometimes it´s kind of a timing problem. 

Especially in the case of create issue it could be that the api call fires too fast/early. This would also explain why it works on the transition trigger (as data is there already).

Could please furthermore post your rule and your webrequest action?


Hi Stefan,

I'm not sure what changed, but I just simply deleted the rule and re-created it and had no issues now. Same thing where it was an Issue Created trigger and a web POST action. I think it was probably the timing issue before. But I am not sure why re-creating the issue would've changed it.

I kept everything the same. Same URL, same header, and then tried different request body types and they all worked.



Like Stefan Salzl likes this
Stefan Salzl
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Apr 18, 2023

oh I see. Unfortunately that happens sometimes so rules get glitchy after some edits (like deleting/adding several components or so) :-/

Glad to know it´s working now ;)

Could you please either accept any given answer or post your own answer that describes your solution in details and accept this one? This marks the question as solved and makes it easier for other people to find solutions in the future.


Do you happen to use the "Hidden" option to hide any headers with credentials in the Web Request? If these actions are copied or modified it seems that it silently requires you to re-add that information (likely a security thing to keep from people reusing stored credentials for other actions).

Also instead of using two separate automations, you might consider using the Field Changed trigger set to Status (which includes Create), unless you also need to catch transitions that loopback on themselves. 

I did not use the Hidden option. I only have 1 header specified to do a somewhat basic auth check. 

Ideally, I would like to be able to differentiate between create and transition, but I have not checked out this other type of trigger. And the transitions should be able to be moved from any state to any other state and trigger this web request.

Are you sending Custom Data in the Web Request? I don't recall all the circumstances but some fields might not quite exist yet during the "Create" function, like the Teams field I think is one case, or fields set by a post function. You could end up with some bad JSON that your server hangs up on. If that is the case you can use a default smart value to pass instead  like {{customfield_1234|null}} or something. You might try adding an action to Add Log Event before the Web Request, and copy paste your Custom Data to capture what it looks like on the Jira side.  

or check the value first,


I just choose Issue data (Jira Format) for the request body because I'm still in a development stage and would just log the whole request as I wanted to see what Jira would send for the issue. Like I said in the first post, it doesn't look like the request even hits the server for the Issue Created trigger. 

But thanks for the suggestion of using custom data, I'll have to try that out.

Unfortunately I don't have any experience with the Issue Data option. You might create another automation that uses the Incoming Webhook trigger to send the original automations Issue Data to see if there are any format issues that your server might not appreciate or if something is hanging it up before it even gets to the destination?  

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events