How to pass any JIRA REST API parameters via Webhooks?

Hi, everybody!
I wonder is it possible to pass any JIRA REST API parameter via Webhooks from another application to JIRA.

I would like to do a JIRA transition (or update an issue field value) by GitLab Webhooks.
For example:
curl -D- -u USER:PASS -X POST --data ‘{“transition”:{“id”:“TRANSITION_ID”}}’ -H “Content-Type: application/json” JIRA_URL:JIRA_PORT/rest/api/latest/issue/<JIRA_ISSUE>/transitions?expand=transitions.fields
(it given from

If webhooks a common tool witch used to send POST request(REST API) to application aside, is it means what I can pass any REST API parameters to another application?

As I know webhooks can pass REST API parameter only in query strings using ‘?’ and ‘&’ sign. But often REST API documentation gives you info how to pass parameters only via a request body(JSON).
But I can’t use it in webhooks. Sometime I just trying to pass those parameters via query string and it goes well, but in case of a transition I can’t do it.

So I confused.
Can I use Webhook to pass any parameters to JIRA or not? Is there a special key to include a request body(JSON) in webhooks as in cURL command “–data”,"-d" key?
Or it is impossible at all and I can pass via query strings only some parameters and other via request body(JSON)?

Could you help me to figure out Webhooks and JIRA REST API?

The Jira REST API end-point for performing a workflow transition accepts an HTTP POST.

A webhook is just a callback that is implemented using HTTP requests. The receiving end commonly accepts an HTTP POST indicating that an event of some kind has occurred.

I haven’t used GitLab Webhooks, but it seems that they are fairly conventional:

“GitLab will send a POST request with data to the webhook URL.”

The body of the HTTP POST request that GitLab sends is a big JSON structure. It’s not the same JSON structure expected by Jira’s workflow transition end-point, but it’s certainly juicy: full of many interesting data.

You’ll need to write your own end-point to receive the HTTP POST from GitLab. You could write a Jira add-on, for example, that deploys a servlet in Jira that accepts POST requests from GitLab. Your end-point code will have to:

a) check that the POST request from GitLab is authentic.

“If you specify a secret token, it will be sent with the hook request in the X-Gitlab-Token HTTP header. Your webhook endpoint can check that to verify that the request is legitimate.” - GitLab

b) send an HTTP POST to Jira to perform the workflow transition, passing a new JSON object containing the data that Jira needs. If you implement your end-point as a servlet inside a Jira add-on, then you could use Jira’s com.atlassian.jira.bc.issue.IssueService interface to more efficiently perform the workflow transition.

Thank you for reply, David!
I got it… Passing REST API parameters is a secondary thing which turned a webhook into in another useful tool it was’t intended.

But I wondering!..
I just think if I can pass some parameters via URI(in query string) by a webhook to another application (JIRA) which accepts them, maybe there is a way to pass other parameters the same way? I try to consider this question aside of a webhook.

At now I run into the problem of passing “structured” parameters (e.g. issue fields value, transition) via a POST http request. Parameters which are far than the first level of nested structure of parameters are inaccessible.

sample of parameters structure for transition:

“transition”: {
“id”: “5”

(I can change a value of “param1” and “param2”, but can’t change the value of “id” parameter for transition)

Passing “the second level structured” parameters can allow me to do a “light automation” without writing a Jira add-on/servlet which required development knowledge.

I can’t understand:

  1. Is there any way to pass another “the second level structured” parameters? Is there any special sign in query string in URI like “?” and “&” to allow me to do this.
  2. Or receiving part(JIRA) just is not accepting another “the second level structured” parameters?

Maybe there is a way to pass these “the second level structured” parameters via URI(in query string)?..

Not that I know of, unfortunately.