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.

[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

[Bill Sheboy]

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