Webhook with status 200 but no body

[Mario GELES]

Hi community,

I need a little help with an automation using a webhook. I am not a master with API and webhook so any help would be greatly appreciated. 

 What I want to do : 
In issue description I want to get the name of a person and set the Reporter field with this name. For this I use API, authorization is ok but I have an empty body.

My Automation : 

So I get the name and put in a variable called {{NomRapporteur}}. In the audit log this variable is ok with this format : FirstName LastName. 

After this I set my webhook like this :

URL : https:/Mydomain.atlassian.net/rest/api/3/user/search?query={{NomRapporteur.urlEncode}}

Method : GET

Request Body : Empty 

(because if not empty authorization don't work https://community.atlassian.com/forums/Jira-articles/Jira-Confluence-Cloud-APIs-return-403-Error-The-request-could/ba-p/2928153 )

Headers :
Authorization Basic mytoken

Content-Type application/json 

Accept application/json

My audit Logs : 

Variable {{NomRapporteur}} works fine

URL with variable {{NomRapporteur}} works fine too (I tested it with postman using the same token as in automation and everything works)

webhookResponse.status : 200

webhookResponse.Headers : it seems ok (it matches response header in postman)

{{webhookResponse.body}} : no log, for this section, it's empty

{{webhookResponse.body.size | 0}} : 0

I don't understand why I have an empty body in Automation with a status 200 whereas it works on postman. Maybe I did something wrong in my webhook.

[Bill Sheboy · Accepted solution]

Hi @Mario GELES 

One possible cause of this symptom is racetrack timing problems...

Some rule triggers and actions, particularly Send Web Request, can use a smart value expression before it is fully evaluated.  For Send Web Request, this can happen for the URL and any request data sent.

The way to check and mitigate this is:

• Create a variable for the URL, perhaps named varUrl.  This will fully evaluate the expression before it is needed...and it can help with debugging when it is also logged.
• Then use {{varUrl}} as the URL in the rule action

Please note I added a var prefix to the variable name to reduce the risk of collision with any existing (or future) smart value naming.

Kind regards,
Bill

[Mario GELES]

Hi @Bill Sheboy 

Sorry for my late reply. 
I try to create a variable for the URL

And of course I also created an entry in the Audit Log for this variable.

The variable is OK (my URL is correct) but I have the same error than previously.

I think I will keep this variable in my automation because it seems to be a good practice.

Kind regards,

Mario

[Mario GELES · Accepted solution]

Here's the full solution for anyone facing the same issue

After a lot of debugging (with the help of Atlassian's Rovo AI assistant, which was incredibly useful throughout the process), I finally got my automation working perfectly. Here's a summary of everything that was wrong and how I fixed it.

My goal: Automatically set a user picker field (Reporter + a custom user picker field) based on a name extracted from the issue description (coming from an external tool via MailToTicket).

❌ What was wrong → ✅ What fixed it

1. Wrong API endpoint
   ❌ I was using /rest/api/3/user/search — this endpoint requires an exact accountId or query match and doesn't work well for fuzzy name lookups.
   ✅ Switched to /rest/api/3/user/picker?query=... — this is the right endpoint for searching users by display name. It returns a users array with accountId and displayName.

2. Wrong URL format
   ❌ I was using https://your-domain.atlassian.net/rest/api/3/...
   ✅ The correct format for API calls from automation webhooks is: https://api.atlassian.com/ex/jira/cloudId/rest/api/3/user/picker?query=...

3. Authentication not properly encoded
   ❌ I was passing the API token as-is in the Authorization header.
   ✅ It must be Base64-encoded: Authorization: Basic base64(email:apiToken)

4. URL not stored in a variable (timing issue)
   ❌ I was building the URL directly in the webhook URL field with smart values — but the smart values weren't always evaluated in time (thanks to @Bill Sheboy  for flagging this!).
   ✅ Store the full URL in a variable first (e.g. VarURL), then reference {{VarURL}} in the webhook. This guarantees the smart values are resolved before the HTTP call. I didn't actually hit this problem head-on since I was still working with the wrong URL at the time, but it saved me from extra headaches once I had the right one. A really good practice to know about.

5. No validation of the API response
   ❌ I was blindly assigning the first result without checking if it actually matched.
   ✅ Added an IF block to compare the returned displayName with the extracted name, using normalized comparison:
   — toUpperCase() → case-insensitive
   — replace("-", " ") → handles hyphenated names
   — substringAfter(" ") → compare last name only (avoids accent issues on first names)
   — contains instead of equals → more tolerant matching

6. No guard against empty/garbage values
   ❌ If the name extraction failed (empty string, parsing residue), the API call would still fire and could return a false positive.
   ✅ Added a length guard: IF {{extractedName.trim().length}} > 5 before making the API call.

🔧 Final working flow (for each user picker field)

1. Trigger: Issue created + JQL condition

2. Create variable: Extract the name from description using substringBetween()

3. IF block: Check that the extracted name length > 5

4. Create variable: Build the API URL with the extracted name

5. Webhook (GET): Call the User Picker API (empty body, Basic auth header, Accept: application/json)

6. IF block: Validate that displayName contains the expected last name (normalized)

7. Edit issue: Set the field to {{webhookResponse.body.users.first.accountId}}

Hope this helps someone else! This took me a while to figure out, but working through it step by step with Rovo AI made the debugging process much faster and more structured.

[Philipp Sendek _catworkx_]

Hi @Mario GELES ,

great you've figured it out and also cool that Rovo was a great help there!
Those are some very good findings and 5 and 6 are exactly what I was suggesting with one of my answers.

Where I don't agree is point 2. This looks to me like an undocumented API endpoint that might be risky to use. The URL of your site and the endpoint mentioned in 1 should be the correct combination.

Other than that, great you've solved it and thanks for sharing this detailled solution for those who stumble upon the same issue in the future!

Greetings
Philipp

[Mario GELES]

Hi @Philipp Sendek _catworkx_ ,

Yes 5 and 6 were good suggestions that I applied as soon as I got a response from my webhook.

For point 2, that was really the hard part. I tried every combination I could with my domain URL but none of them worked. So RoVo came up with the Atlassian gateway URL and then it worked. 

the api.atlassian.com gateway URL is actually not undocumented. It's a valid approach recognized by Atlassian in several contexts, such as service account API tokens or ad-hoc API calls with basic auth.

Here are some references where it's mentioned:

• Manage API tokens for service accounts | Atlassian Support
• The Jira Service Management Cloud REST API
• The Jira Software Cloud REST API

It's worth noting that apart from the base URL (api.atlassian.com/ex/jira/cloudId instead of your-domain.atlassian.net), the endpoint structure remains exactly the same.

In my case, the domain URL simply didn't work from Jira Automation webhooks, while the gateway URL did.

Best Regards,

Mario

[Philipp Sendek _catworkx_]

Hi @Mario GELES ,

apologies, you're absolutely right! I've forgotten about the service account REST endpoints. 
Even better to have this base also covered in your detailled solution above. 👏

Greetings
Philipp

[Philipp Sendek _catworkx_]

Hi @Mario GELES

Just to get the facts right:
In your screenshot you are creating an audit entry for the URL and the smart value {{NomRapporteur.urlEncode}}. And you are using the output of this exactly as it is in your test in Postman and still the response differs?
If I read correctly, in your message you just mention that the url with variable {{NomRapporteur}} (so without the urlEncode) works fine.

One thing I always do when I push webhooks to a service where I can't verify what's really coming through, is that I create a new instance on https://webhook.site and trigger a test-webhook to the URL I get. This gives you the fully overview of the webhook and is great for troubleshooting.

But please keep in mind to use a test entry instead of a real name for pushing it to such sites.

I hope this helps you finding the issue in the automation. I assume it's related to the URL encode or some other character issue within the variable.

And one more suggestion from experience: I've had issues with this particular REST endpoint in the past where it returned false entries instead of nothing when it couldn't find a user. So I went ahead and created an IF bracked after the result to confirm that the e-mail address of the person I was looking for matches with the e-mail address the search endpoint returned. That way you can be sure that you have the right account before you continue to work with it.

Greetings
Philipp

[Mario GELES]

Hi @Philipp Sendek _catworkx_  ,

Thank you for your answer 

Yes I use the exact output of the URL with {{NomRapporteur.urlEncode}} in Postman. 

The result of my variable is quite simple, no specific characters and the URL seems correct : 

https://Mydomain.atlassian.net/rest/api/3/user/search?query=+FirstName+LastName%0D%0A%0D%0A

I will see if I can try https://webhook.site to troubleshoot as you suggest

[Philipp Sendek _catworkx_]

Hi @Mario GELES ,

have you had any luck with testing against webhook.site? Can you confirm that the incoming data is exactly like the data you used when testing with Postman?
Did you identify any other changes that might've cause the endpoint to return no body?
Maybe one thought: What happens when you use Accept: */* as header? Any changes?
I don't see an error in the headers you provided, but it's worth a try if all else looks good.

Greetings
Philipp

[Marc -Devoteam-]

Hi @Mario GELES 

Using a web request in automation, you require to use the {{webResponse.body}} smart value to use information from the returned call.

You will get the accountId from the user found.

Then use {{webResponse.body.accountId}} as smart clause in the reporter field.