I'm creating an API connector using the SOAR function. I've done some testing and it works perfectly, but how can I send a variable within the field?

The documentation only mentions using "playbook.inputs.xxxxxx", but the query can't possibly be an input!

What alternatives do you think are possible?

Hi Juan,

If I understand correctly, you wish to mix constant text with variable text so that the request string matches what the endpoints expects.

You are going to have to manage this with a script. 

To do this, I have created a subplaybook that take one parameter as input for the artifact.value.
I define the output for the subplaybook with the json schema so that the data navigator knows the subplaybook will return a string as part of the result.

{  "type": "object",  "properties": {    "request": {      "type": "string"    }  },  "required": [    "request"  ]}

I setup the subplaybook with just one start and one end point. In the end point, I define  the result in that way:

playbook.results = {"request": "param1=hard-value1&param2=value2&artifact=" + playbook.inputs.artifact}

Add the subplaybook node just before your connector add a result name and save the playbook. For the subplaybook input select the field you want to use with the data navigator.
For the request parameter select the subplyabook request attribute from result object.

I'm creating an API connector using the SOAR function. I've done some testing and it works perfectly, but how can I send a variable within the field?

The documentation only mentions using "playbook.inputs.xxxxxx", but the query can't possibly be an input!

What alternatives do you think are possible?

Hi,
I've just stumbled upon the very same issue today.
I find it quite odd that IBM has provided us with ability to define Form and Raw input for connector function's request body, but we can't do the same for Request Parameters.

And what is even more frustrating - I did properly format my input via local script and stored it within playbook.properties object via playbook.addProperty function before passing it to connector function. And yet, it was to no avail - request parameter schema wouldn't show properties object under playbook.

All of this fiddling with sub-playbooks just to do this simple operation seems like IBM has done a poor job with connector function usability.

I don't even know why I wrote it hear - just my cry of the soul, I guess 😅

Hi Juan,

If I understand correctly, you wish to mix constant text with variable text so that the request string matches what the endpoints expects.

You are going to have to manage this with a script. 

To do this, I have created a subplaybook that take one parameter as input for the artifact.value.
I define the output for the subplaybook with the json schema so that the data navigator knows the subplaybook will return a string as part of the result.

{  "type": "object",  "properties": {    "request": {      "type": "string"    }  },  "required": [    "request"  ]}

I setup the subplaybook with just one start and one end point. In the end point, I define  the result in that way:

playbook.results = {"request": "param1=hard-value1&param2=value2&artifact=" + playbook.inputs.artifact}

Add the subplaybook node just before your connector add a result name and save the playbook. For the subplaybook input select the field you want to use with the data navigator.
For the request parameter select the subplyabook request attribute from result object.

I'm creating an API connector using the SOAR function. I've done some testing and it works perfectly, but how can I send a variable within the field?

The documentation only mentions using "playbook.inputs.xxxxxx", but the query can't possibly be an input!

What alternatives do you think are possible?

Hi,
I've just stumbled upon the very same issue today.
I find it quite odd that IBM has provided us with ability to define Form and Raw input for connector function's request body, but we can't do the same for Request Parameters.

And what is even more frustrating - I did properly format my input via local script and stored it within playbook.properties object via playbook.addProperty function before passing it to connector function. And yet, it was to no avail - request parameter schema wouldn't show properties object under playbook.

All of this fiddling with sub-playbooks just to do this simple operation seems like IBM has done a poor job with connector function usability.

I don't even know why I wrote it hear - just my cry of the soul, I guess 😅

Hi Juan,

If I understand correctly, you wish to mix constant text with variable text so that the request string matches what the endpoints expects.

You are going to have to manage this with a script. 

To do this, I have created a subplaybook that take one parameter as input for the artifact.value.
I define the output for the subplaybook with the json schema so that the data navigator knows the subplaybook will return a string as part of the result.

{  "type": "object",  "properties": {    "request": {      "type": "string"    }  },  "required": [    "request"  ]}

I setup the subplaybook with just one start and one end point. In the end point, I define  the result in that way:

playbook.results = {"request": "param1=hard-value1&param2=value2&artifact=" + playbook.inputs.artifact}

Add the subplaybook node just before your connector add a result name and save the playbook. For the subplaybook input select the field you want to use with the data navigator.
For the request parameter select the subplyabook request attribute from result object.

I'm creating an API connector using the SOAR function. I've done some testing and it works perfectly, but how can I send a variable within the field?

The documentation only mentions using "playbook.inputs.xxxxxx", but the query can't possibly be an input!

What alternatives do you think are possible?

Hi,
I've just stumbled upon the very same issue today.
I find it quite odd that IBM has provided us with ability to define Form and Raw input for connector function's request body, but we can't do the same for Request Parameters.

And what is even more frustrating - I did properly format my input via local script and stored it within playbook.properties object via playbook.addProperty function before passing it to connector function. And yet, it was to no avail - request parameter schema wouldn't show properties object under playbook.

All of this fiddling with sub-playbooks just to do this simple operation seems like IBM has done a poor job with connector function usability.

I don't even know why I wrote it hear - just my cry of the soul, I guess 😅

Hi Juan,

If I understand correctly, you wish to mix constant text with variable text so that the request string matches what the endpoints expects.

You are going to have to manage this with a script. 

To do this, I have created a subplaybook that take one parameter as input for the artifact.value.
I define the output for the subplaybook with the json schema so that the data navigator knows the subplaybook will return a string as part of the result.

{  "type": "object",  "properties": {    "request": {      "type": "string"    }  },  "required": [    "request"  ]}

I setup the subplaybook with just one start and one end point. In the end point, I define  the result in that way:

playbook.results = {"request": "param1=hard-value1&param2=value2&artifact=" + playbook.inputs.artifact}

Add the subplaybook node just before your connector add a result name and save the playbook. For the subplaybook input select the field you want to use with the data navigator.
For the request parameter select the subplyabook request attribute from result object.

I'm creating an API connector using the SOAR function. I've done some testing and it works perfectly, but how can I send a variable within the field?

The documentation only mentions using "playbook.inputs.xxxxxx", but the query can't possibly be an input!

What alternatives do you think are possible?

------------------------------
Martin Feeney
Product Manager, IBM Security QRadar SOAR
martin.feeney@ie.ibm.com

Original Message:
Sent: Tue February 03, 2026 06:15 AM
From: Lucian Sipos
Subject: Connector API

------------------------------
Lucian Sipos

Original Message:
Sent: Fri January 30, 2026 07:06 AM
From: Juan Cruz Del Col
Subject: Connector API

------------------------------
Juan Cruz Del Col

Original Message:
Sent: Thu January 29, 2026 04:26 PM
From: Mykhailo Honcharov
Subject: Connector API

Hi,
I've just stumbled upon the very same issue today.
I find it quite odd that IBM has provided us with ability to define Form and Raw input for connector function's request body, but we can't do the same for Request Parameters.

And what is even more frustrating - I did properly format my input via local script and stored it within playbook.properties object via playbook.addProperty function before passing it to connector function. And yet, it was to no avail - request parameter schema wouldn't show properties object under playbook.

All of this fiddling with sub-playbooks just to do this simple operation seems like IBM has done a poor job with connector function usability.

I don't even know why I wrote it hear - just my cry of the soul, I guess 😅

------------------------------
Mykhailo Honcharov

Original Message:
Sent: Thu December 18, 2025 06:01 AM
From: YANNICK LAVANANT
Subject: Connector API

Hi Juan,

If I understand correctly, you wish to mix constant text with variable text so that the request string matches what the endpoints expects.

You are going to have to manage this with a script. 

To do this, I have created a subplaybook that take one parameter as input for the artifact.value.
I define the output for the subplaybook with the json schema so that the data navigator knows the subplaybook will return a string as part of the result.

{  "type": "object",  "properties": {    "request": {      "type": "string"    }  },  "required": [    "request"  ]}

I setup the subplaybook with just one start and one end point. In the end point, I define  the result in that way:

playbook.results = {"request": "param1=hard-value1&param2=value2&artifact=" + playbook.inputs.artifact}

Add the subplaybook node just before your connector add a result name and save the playbook. For the subplaybook input select the field you want to use with the data navigator.
For the request parameter select the subplyabook request attribute from result object.

------------------------------
YANNICK LAVANANT

Original Message:
Sent: Wed December 17, 2025 10:43 AM
From: Juan Cruz Del Col
Subject: Connector API

I'm creating an API connector using the SOAR function. I've done some testing and it works perfectly, but how can I send a variable within the field?

The documentation only mentions using "playbook.inputs.xxxxxx", but the query can't possibly be an input!

What alternatives do you think are possible?

------------------------------
Juan Cruz Del Col
------------------------------

Greetings, Martin

It looks like a lot of decisions around the custom connectors were made instead of playbook designers make these decision themselves. The value substitution for request parameters is one among many I've come across while struggling to create my own connector. My use case that I have decided to implement was custom connector for some of QRadar SIEM API functionality, specifically AQL searches.

I've started out with a simple playbook that takes next values as inputs:

• SELECT properties as multiselect;
• FROM database as select (events/flows);
• WHERE conditions as string;
• ORDER BY sort expressions as string;
• START/END time limits as datatime.

A custom script before the connector function call was actually used to compile these inputs into a complete AQL query which is then used to POST an AQL search. First of the obstacles was the aforementioned request parameter value substitution, which I've managed to get by with an additional sub-playbook. Then I've got another hiccup with a way request parameters are encoded within custom connector implementation. The thing is connector request parameters encoding, as far as I can say, was implemented via plus-encoding, which substitutes any spaces present withing the parameter with +. These get passed to QRadar SIEM API as literal plus signs which breaks the whole AQL expression. The best variant would be to encode spaces via percent-encoding as %20 (which is more widely supported across APIs) but I haven't managed to find a way I can alter this behavior. Instead of building a playbook that would form up proper AQL and then call an uncomplicated connector function I have to jump hoops with value substitution only to run into another wall with request parameter encoding.

Then there is also an inability to handle multipart data as a connector function response. I simply can't access this data in a way I want to (e.g. to later on create an incident attachment) - the only way to access it is via response data JSON object, but this data is further encoded for the function to return it as application/json, I guess. At least this issue seems to be looked upon as I can see a response field called Body Content Type in connector function form, although there is no way to change it (yet?).

So as you can see the frustration is genuine and I'm sorry that these posts are sometimes the only way for community members to express themselves in a desperate attempt for their plead to be heared 😅 

------------------------------
Mykhailo Honcharov

Original Message:
Sent: Fri February 06, 2026 06:53 AM
From: Martin Feeney
Subject: Connector API

------------------------------
Martin Feeney
Product Manager, IBM Security QRadar SOAR
martin.feeney@ie.ibm.com

Original Message:
Sent: Tue February 03, 2026 06:15 AM
From: Lucian Sipos
Subject: Connector API

------------------------------
Lucian Sipos

Original Message:
Sent: Fri January 30, 2026 07:06 AM
From: Juan Cruz Del Col
Subject: Connector API

------------------------------
Juan Cruz Del Col

Original Message:
Sent: Thu January 29, 2026 04:26 PM
From: Mykhailo Honcharov
Subject: Connector API

Hi,
I've just stumbled upon the very same issue today.
I find it quite odd that IBM has provided us with ability to define Form and Raw input for connector function's request body, but we can't do the same for Request Parameters.

And what is even more frustrating - I did properly format my input via local script and stored it within playbook.properties object via playbook.addProperty function before passing it to connector function. And yet, it was to no avail - request parameter schema wouldn't show properties object under playbook.

All of this fiddling with sub-playbooks just to do this simple operation seems like IBM has done a poor job with connector function usability.

I don't even know why I wrote it hear - just my cry of the soul, I guess 😅

------------------------------
Mykhailo Honcharov

Original Message:
Sent: Thu December 18, 2025 06:01 AM
From: YANNICK LAVANANT
Subject: Connector API

Hi Juan,

If I understand correctly, you wish to mix constant text with variable text so that the request string matches what the endpoints expects.

You are going to have to manage this with a script. 

To do this, I have created a subplaybook that take one parameter as input for the artifact.value.
I define the output for the subplaybook with the json schema so that the data navigator knows the subplaybook will return a string as part of the result.

{  "type": "object",  "properties": {    "request": {      "type": "string"    }  },  "required": [    "request"  ]}

I setup the subplaybook with just one start and one end point. In the end point, I define  the result in that way:

playbook.results = {"request": "param1=hard-value1&param2=value2&artifact=" + playbook.inputs.artifact}

Add the subplaybook node just before your connector add a result name and save the playbook. For the subplaybook input select the field you want to use with the data navigator.
For the request parameter select the subplyabook request attribute from result object.

------------------------------
YANNICK LAVANANT

Original Message:
Sent: Wed December 17, 2025 10:43 AM
From: Juan Cruz Del Col
Subject: Connector API

I'm creating an API connector using the SOAR function. I've done some testing and it works perfectly, but how can I send a variable within the field?

The documentation only mentions using "playbook.inputs.xxxxxx", but the query can't possibly be an input!

What alternatives do you think are possible?

------------------------------
Juan Cruz Del Col
------------------------------

Hi Mykhailo,

Thanks for providing this overall summary, will get this reviewed later.

That said, can I just double check whether we should be looking at this in the context of improvements to make to one of our existing SIEM apps rather than to the connectors. E.g. The SIEM functions app ?

https://apps.xforce.ibmcloud.com/extension/a9bcc3eaebf2a6efc04258b4964a48a4

or the EDM app ?

https://apps.xforce.ibmcloud.com/extension/e83034dc0987f0c9a0f23edfae6cfe0a

Greetings, Martin

It looks like a lot of decisions around the custom connectors were made instead of playbook designers make these decision themselves. The value substitution for request parameters is one among many I've come across while struggling to create my own connector. My use case that I have decided to implement was custom connector for some of QRadar SIEM API functionality, specifically AQL searches.

I've started out with a simple playbook that takes next values as inputs:

• SELECT properties as multiselect;
• FROM database as select (events/flows);
• WHERE conditions as string;
• ORDER BY sort expressions as string;
• START/END time limits as datatime.

A custom script before the connector function call was actually used to compile these inputs into a complete AQL query which is then used to POST an AQL search. First of the obstacles was the aforementioned request parameter value substitution, which I've managed to get by with an additional sub-playbook. Then I've got another hiccup with a way request parameters are encoded within custom connector implementation. The thing is connector request parameters encoding, as far as I can say, was implemented via plus-encoding, which substitutes any spaces present withing the parameter with +. These get passed to QRadar SIEM API as literal plus signs which breaks the whole AQL expression. The best variant would be to encode spaces via percent-encoding as %20 (which is more widely supported across APIs) but I haven't managed to find a way I can alter this behavior. Instead of building a playbook that would form up proper AQL and then call an uncomplicated connector function I have to jump hoops with value substitution only to run into another wall with request parameter encoding.

Then there is also an inability to handle multipart data as a connector function response. I simply can't access this data in a way I want to (e.g. to later on create an incident attachment) - the only way to access it is via response data JSON object, but this data is further encoded for the function to return it as application/json, I guess. At least this issue seems to be looked upon as I can see a response field called Body Content Type in connector function form, although there is no way to change it (yet?).

So as you can see the frustration is genuine and I'm sorry that these posts are sometimes the only way for community members to express themselves in a desperate attempt for their plead to be heared 😅 

------------------------------
Mykhailo Honcharov

Original Message:
Sent: Fri February 06, 2026 06:53 AM
From: Martin Feeney
Subject: Connector API

------------------------------
Martin Feeney
Product Manager, IBM Security QRadar SOAR
martin.feeney@ie.ibm.com

Original Message:
Sent: Tue February 03, 2026 06:15 AM
From: Lucian Sipos
Subject: Connector API

------------------------------
Lucian Sipos

Original Message:
Sent: Fri January 30, 2026 07:06 AM
From: Juan Cruz Del Col
Subject: Connector API

------------------------------
Juan Cruz Del Col

Original Message:
Sent: Thu January 29, 2026 04:26 PM
From: Mykhailo Honcharov
Subject: Connector API

Hi,
I've just stumbled upon the very same issue today.
I find it quite odd that IBM has provided us with ability to define Form and Raw input for connector function's request body, but we can't do the same for Request Parameters.

And what is even more frustrating - I did properly format my input via local script and stored it within playbook.properties object via playbook.addProperty function before passing it to connector function. And yet, it was to no avail - request parameter schema wouldn't show properties object under playbook.

All of this fiddling with sub-playbooks just to do this simple operation seems like IBM has done a poor job with connector function usability.

I don't even know why I wrote it hear - just my cry of the soul, I guess 😅

------------------------------
Mykhailo Honcharov

Original Message:
Sent: Thu December 18, 2025 06:01 AM
From: YANNICK LAVANANT
Subject: Connector API

Hi Juan,

If I understand correctly, you wish to mix constant text with variable text so that the request string matches what the endpoints expects.

You are going to have to manage this with a script. 

To do this, I have created a subplaybook that take one parameter as input for the artifact.value.
I define the output for the subplaybook with the json schema so that the data navigator knows the subplaybook will return a string as part of the result.

{  "type": "object",  "properties": {    "request": {      "type": "string"    }  },  "required": [    "request"  ]}

I setup the subplaybook with just one start and one end point. In the end point, I define  the result in that way:

playbook.results = {"request": "param1=hard-value1&param2=value2&artifact=" + playbook.inputs.artifact}

Add the subplaybook node just before your connector add a result name and save the playbook. For the subplaybook input select the field you want to use with the data navigator.
For the request parameter select the subplyabook request attribute from result object.

------------------------------
YANNICK LAVANANT

Original Message:
Sent: Wed December 17, 2025 10:43 AM
From: Juan Cruz Del Col
Subject: Connector API

I'm creating an API connector using the SOAR function. I've done some testing and it works perfectly, but how can I send a variable within the field?

The documentation only mentions using "playbook.inputs.xxxxxx", but the query can't possibly be an input!

What alternatives do you think are possible?

------------------------------
Juan Cruz Del Col
------------------------------

Hi Martin,

Yes, as a matter of fact I tried to achieve the same results by using AQL function from QRadar EDM app, which yielded nada. Disregard the function name, I just renamed it for my own convenience without changing its API name. At first the playbook just finished but made no visible changes to the datatable it was supposed to populate, so I've added a debug output with helper.fail function. The output clearly shows that EDM function for some reason fails to form proper AQL even though all the inputs are correct. Details below.
I've only attempted connector integration with QRadar SIEM API because it was referenced within Tutorial: Creating custom connectors in the official documentation, although to be fair not that particular usecase of AQL interactions. I just gave it a try and failed miserebly 😓

Hi Mykhailo,

Thanks for providing this overall summary, will get this reviewed later.

That said, can I just double check whether we should be looking at this in the context of improvements to make to one of our existing SIEM apps rather than to the connectors. E.g. The SIEM functions app ?

https://apps.xforce.ibmcloud.com/extension/a9bcc3eaebf2a6efc04258b4964a48a4

or the EDM app ?

https://apps.xforce.ibmcloud.com/extension/e83034dc0987f0c9a0f23edfae6cfe0a

Greetings, Martin

It looks like a lot of decisions around the custom connectors were made instead of playbook designers make these decision themselves. The value substitution for request parameters is one among many I've come across while struggling to create my own connector. My use case that I have decided to implement was custom connector for some of QRadar SIEM API functionality, specifically AQL searches.

I've started out with a simple playbook that takes next values as inputs:

• SELECT properties as multiselect;
• FROM database as select (events/flows);
• WHERE conditions as string;
• ORDER BY sort expressions as string;
• START/END time limits as datatime.

A custom script before the connector function call was actually used to compile these inputs into a complete AQL query which is then used to POST an AQL search. First of the obstacles was the aforementioned request parameter value substitution, which I've managed to get by with an additional sub-playbook. Then I've got another hiccup with a way request parameters are encoded within custom connector implementation. The thing is connector request parameters encoding, as far as I can say, was implemented via plus-encoding, which substitutes any spaces present withing the parameter with +. These get passed to QRadar SIEM API as literal plus signs which breaks the whole AQL expression. The best variant would be to encode spaces via percent-encoding as %20 (which is more widely supported across APIs) but I haven't managed to find a way I can alter this behavior. Instead of building a playbook that would form up proper AQL and then call an uncomplicated connector function I have to jump hoops with value substitution only to run into another wall with request parameter encoding.

Then there is also an inability to handle multipart data as a connector function response. I simply can't access this data in a way I want to (e.g. to later on create an incident attachment) - the only way to access it is via response data JSON object, but this data is further encoded for the function to return it as application/json, I guess. At least this issue seems to be looked upon as I can see a response field called Body Content Type in connector function form, although there is no way to change it (yet?).

So as you can see the frustration is genuine and I'm sorry that these posts are sometimes the only way for community members to express themselves in a desperate attempt for their plead to be heared 😅 

------------------------------
Mykhailo Honcharov

Original Message:
Sent: Fri February 06, 2026 06:53 AM
From: Martin Feeney
Subject: Connector API

------------------------------
Martin Feeney
Product Manager, IBM Security QRadar SOAR
martin.feeney@ie.ibm.com

Original Message:
Sent: Tue February 03, 2026 06:15 AM
From: Lucian Sipos
Subject: Connector API

------------------------------
Lucian Sipos

Original Message:
Sent: Fri January 30, 2026 07:06 AM
From: Juan Cruz Del Col
Subject: Connector API

------------------------------
Juan Cruz Del Col

Original Message:
Sent: Thu January 29, 2026 04:26 PM
From: Mykhailo Honcharov
Subject: Connector API

Hi,
I've just stumbled upon the very same issue today.
I find it quite odd that IBM has provided us with ability to define Form and Raw input for connector function's request body, but we can't do the same for Request Parameters.

And what is even more frustrating - I did properly format my input via local script and stored it within playbook.properties object via playbook.addProperty function before passing it to connector function. And yet, it was to no avail - request parameter schema wouldn't show properties object under playbook.

All of this fiddling with sub-playbooks just to do this simple operation seems like IBM has done a poor job with connector function usability.

I don't even know why I wrote it hear - just my cry of the soul, I guess 😅

------------------------------
Mykhailo Honcharov

Original Message:
Sent: Thu December 18, 2025 06:01 AM
From: YANNICK LAVANANT
Subject: Connector API

Hi Juan,

If I understand correctly, you wish to mix constant text with variable text so that the request string matches what the endpoints expects.

You are going to have to manage this with a script. 

To do this, I have created a subplaybook that take one parameter as input for the artifact.value.
I define the output for the subplaybook with the json schema so that the data navigator knows the subplaybook will return a string as part of the result.

{  "type": "object",  "properties": {    "request": {      "type": "string"    }  },  "required": [    "request"  ]}

I setup the subplaybook with just one start and one end point. In the end point, I define  the result in that way:

playbook.results = {"request": "param1=hard-value1&param2=value2&artifact=" + playbook.inputs.artifact}

Add the subplaybook node just before your connector add a result name and save the playbook. For the subplaybook input select the field you want to use with the data navigator.
For the request parameter select the subplyabook request attribute from result object.

------------------------------
YANNICK LAVANANT

Original Message:
Sent: Wed December 17, 2025 10:43 AM
From: Juan Cruz Del Col
Subject: Connector API

I'm creating an API connector using the SOAR function. I've done some testing and it works perfectly, but how can I send a variable within the field?

The documentation only mentions using "playbook.inputs.xxxxxx", but the query can't possibly be an input!

What alternatives do you think are possible?

------------------------------
Juan Cruz Del Col
------------------------------

Hi,
I've just stumbled upon the very same issue today.
I find it quite odd that IBM has provided us with ability to define Form and Raw input for connector function's request body, but we can't do the same for Request Parameters.

And what is even more frustrating - I did properly format my input via local script and stored it within playbook.properties object via playbook.addProperty function before passing it to connector function. And yet, it was to no avail - request parameter schema wouldn't show properties object under playbook.

All of this fiddling with sub-playbooks just to do this simple operation seems like IBM has done a poor job with connector function usability.

I don't even know why I wrote it hear - just my cry of the soul, I guess 😅

Hi Juan,

If I understand correctly, you wish to mix constant text with variable text so that the request string matches what the endpoints expects.

You are going to have to manage this with a script. 

To do this, I have created a subplaybook that take one parameter as input for the artifact.value.
I define the output for the subplaybook with the json schema so that the data navigator knows the subplaybook will return a string as part of the result.

{  "type": "object",  "properties": {    "request": {      "type": "string"    }  },  "required": [    "request"  ]}

I setup the subplaybook with just one start and one end point. In the end point, I define  the result in that way:

playbook.results = {"request": "param1=hard-value1&param2=value2&artifact=" + playbook.inputs.artifact}

Add the subplaybook node just before your connector add a result name and save the playbook. For the subplaybook input select the field you want to use with the data navigator.
For the request parameter select the subplyabook request attribute from result object.

I'm creating an API connector using the SOAR function. I've done some testing and it works perfectly, but how can I send a variable within the field?

The documentation only mentions using "playbook.inputs.xxxxxx", but the query can't possibly be an input!

What alternatives do you think are possible?

Hi,
I also encountered a problem with entering parameters via playbook.properties. The workaround, if you can call it that, is to use incident.properties. Before the function, enter the data into the incident property and then refer to it in the connector function. However, I don't know if this will work in your case. You will need to test whether the data is transferred correctly to incident.properties and then whether it is transferred correctly to the function. Maybe this will help you.

Hi,
I've just stumbled upon the very same issue today.
I find it quite odd that IBM has provided us with ability to define Form and Raw input for connector function's request body, but we can't do the same for Request Parameters.

And what is even more frustrating - I did properly format my input via local script and stored it within playbook.properties object via playbook.addProperty function before passing it to connector function. And yet, it was to no avail - request parameter schema wouldn't show properties object under playbook.

All of this fiddling with sub-playbooks just to do this simple operation seems like IBM has done a poor job with connector function usability.

I don't even know why I wrote it hear - just my cry of the soul, I guess 😅

Hi Juan,

If I understand correctly, you wish to mix constant text with variable text so that the request string matches what the endpoints expects.

You are going to have to manage this with a script. 

To do this, I have created a subplaybook that take one parameter as input for the artifact.value.
I define the output for the subplaybook with the json schema so that the data navigator knows the subplaybook will return a string as part of the result.

{  "type": "object",  "properties": {    "request": {      "type": "string"    }  },  "required": [    "request"  ]}

I setup the subplaybook with just one start and one end point. In the end point, I define  the result in that way:

playbook.results = {"request": "param1=hard-value1&param2=value2&artifact=" + playbook.inputs.artifact}

Add the subplaybook node just before your connector add a result name and save the playbook. For the subplaybook input select the field you want to use with the data navigator.
For the request parameter select the subplyabook request attribute from result object.

I'm creating an API connector using the SOAR function. I've done some testing and it works perfectly, but how can I send a variable within the field?

The documentation only mentions using "playbook.inputs.xxxxxx", but the query can't possibly be an input!

What alternatives do you think are possible?