Workflow HTTP Request Body Array Bug

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

I’ve just come across a strange bug with the HTTP Request body and single object arrays. Wondering if anyone has seen this before. I am calling the PATCH /accounts/:id api in my workflow to update the attributes of a delim source account. Per the API the request body must be sent as an array.

So in my HTTP request for the Request Body field I choose “Enter Value” and send something like this:

    [
        {
            "op": "replace",
            "path": "/attributes/someAttribute",
            "value": "{{$.interactiveForm.formData.someField}}"
        }
    ]

My request was failing every time. I looked at everything to troubleshoot. Then in the workflow output I noticed that after JSON parsing and variable substitution it looks like ISC is sending the JSON body like this:

{
    "type": "ActivityTaskScheduled",
    "timestamp": "2026-04-26T01:10:28.253069277Z",
    "attributes": {
      "displayName": "HTTP Request 2",
      "input": {
        "authenticationType": "OAuth",
        "headerAuthValue": null,
        "jsonRequestBody": {
          "op": "replace",
          "path": "/attributes/someAttribute",
          "value": "ID Only"
        },
        "method": "patch",

abbreviated ...

Notice that in the “jsonRequestBody” field ISC has stripped the array and is sending just as a single JSON object! I guess it thinks it is doing the correct thing since this is a single item array, but stripping it will cause the request to be rejected by the endpoint!

Luckily the workaround was simple. I went back to the Request Body in the HTTP Request added another array:

    [[
        {
            "op": "replace",
            "path": "/attributes/someAttribute",
            "value": "{{$.interactiveForm.formData.someField}}"
        }
    ]]

This time it worked!

{
    "type": "ActivityTaskScheduled",
    "timestamp": "2026-04-26T01:35:18.003287514Z",
    "attributes": {
      "displayName": "HTTP Request 2",
      "input": {
        "authenticationType": "OAuth",
        "headerAuthValue": null,
        "jsonRequestBody": [
          {
            "op": "replace",
            "path": "/attributes/someAttribute",
            "value": "Fully Enabled"
          }
        ],
        "method": "patch",

abbreviated ...

I’m curious if anyone has seen this bug before? Is this not a bug / expected behavior? I don’t mind the work around but I’m afraid if SailPoint notices this and corrects it that my workflows will suddenly break.

Thanks!

2

Yeah, I think you’re right on this. As per the PATCH docs, the body should always be a JSON Patch array, even if it’s just one operation, so sending it as a single object isn’t valid. The Accounts API also clearly calls out that the request body must be a list of operations following the JSON Patch standard, so this lines up with that. I would suggest raising a Support ticket & reporting it, since this looks like a workflow side serialization issue rather than anything with the Accounts API.

Sources:

3

I’ll raise a support ticket then.

@colin_mckibben curious if you have any idea about this?

4

Hey @kyle_knox ,

I liked your workaround issue I will definitely try it out in devrel tenant ,but I see minor configuration missing in your HTTP request

Update-->Content-type:"json patch"

{

"type": "ActivityTaskScheduled",

"timestamp": "2026-04-26T01:35:18.003287514Z",

"attributes": {

  "displayName": "HTTP Request 2",

  "input": {

    "authenticationType": "OAuth",

    "**headerAuthValue**": null, this should be **json** **patch** try with change , I don't think so you need workaround 

    "jsonRequestBody": \[

      {

        "op": "replace",

        "path": "/attributes/someAttribute",

        "value": "Fully Enabled"

      }

    \],

    "method": "patch",

Let me know if need any assistance

If you found fix mark it as solution.

Thanks in advance

Avinash Mulpuru.

5

Thank you @amulpuru! Actually I didn’t take your solution but you did lead me to what I think the best solutions is. Rather than choose JSON for the Request Content Type you can choose JSON PATCH which I didn’t even notice was an option. Choosing this does not update the headerAuthValue as you have said but it does cause ISC to format it the body correctly. So the bug here lied between the chair and the keyboard. Not the software!