Web Service Connector - Enable Account Operation Error

[pradipniladhe1 (Pradip Niladhe)]

Hi All,

I am using the Web Services SaaS connector in SailPoint ISC and facing issues with the Enable Account operation.

I am trying to configure two API calls as described in the documentation(using the exact naming as there is no other way of linking two Enable Account calls): Enable Account

The first call is to GET user which works fine. However, in the second call, the $response variable does not seem to have any value.

• If I hardcode the required values in the body of the second call, the request works fine.
• But when I try to use $response variables (e.g., $response.email$), the call fails.
• The logs indicate a missing required parameter, which suggests the variable is resolving to empty.

Has anyone encountered this issue or knows how to properly pass data between the two calls in the Enable Account flow?

Thank you!

Regards,

Pradip

[SatishAtike]

Hi @pradipniladhe1 ,Using response of one request as the input to the another request, is nothing but parent child endpoints, We can use this for Aggregation operations and Get object operations.
You cannot use it for Enable account operation.
Here the document

Multiple Independent Endpoints

[SatishAtike]

Could you please explain your requirement more clearly, why do you want two api calls for enable account, what is the input required to call api and which attribute is declared as account id, and please provide the api response if possible.

[SivaprakashRNTBCI (Sivaprakash P)]

@pradipniladhe1 Have you configured the root path and response mapping in your first call? If not set it and then try.

Ex:

{
  "user": {
    "email": "test@example.com",
    "id": "12345",
    "status": "disabled"
  }
}

Configure:

• Root Path: $.user
• Response Mapping:
  • Schema Attribute: email → Attribute Path: email
  • Schema Attribute: id → Attribute Path: id

Then in Enable Account - 2, you can use $response.email$ and $response.id$.

[Mobou123 (Mohamed Boualam)]

Hi Pradip!

fix is do not use the schema/mapped name in the second call. Use the raw response attribute name from Enable Account - 1.

SailPoint’s doc confirms this pattern: Enable Account - 1 does the get object, and its returned response object is used as input for Enable Account - 2.

Try this:

{
“email”: “$response.email$”,
“firstName”: “$response.firstName$”,
“lastName”: “$response.lastName$”,
“enabled”: true
}

But only if the first API response is actually:

{
“email”: “user@domain.com”,
“firstName”: “John”,
“lastName”: “Smith”
}

If the first response is nested, like:

{
“data”: {
“email”: “user@domain.com”
}
}

then use:

{
“email”: “$response.data.email$”
}

The key point: $response.attribute$ must reference the raw JSON response field, not the SailPoint schema attribute you mapped it to. SailPoint community confirmed this exact behavior for chained Web Services calls.

Also verify these:

Enable Account - 1 has Response Mapping configured
Even if the GET works, if response mapping/root path is wrong, Enable Account - 2 may see blank values.

[kannan_sb85 (Kannan Sriniyappan Balakrishnan)]

@pradipniladhe1 - I have faced this similar problem, in order to resolve this issue is to pass data between the two calls in the Enable Account.

1. Verify the Raw JSON Response of Enable Account - 1
   • Execute the GET request using Postman or cURL to see the exact JSON structure returned by the API.

{
  "user": {
    "id": "12345",
    "email": "test123@example.com",
    "status": "disabled"
  }
}

2. Configure Response Information and Mapping for Enable Account - 1
3. Correctly Format the Body of Enable Account - 2

{
  "email": "$response.user.email$",
  "id": "$response.user.id$",
  "enabled": true
}

If the requests continues to cause an issues due to complex JSON structures or connector limitations, SailPoint is recommends using a Before Operation Rule or After Operation Rule.

Regards,

Kannan

[pradipniladhe1 (Pradip Niladhe)]

Thank you.

I am now using the raw JSON response in the second call and both the root path and response configuration are correct. However, it seems that SailPoint is skipping the first call and only executing the “Enable Account - 2” call.

[SatishAtike]

Could you please confirm if both the operations types set as Enable Account? or is it different?

[Blazelip (Dmitrii Filiukov)]

@Mobou123 @kannan_sb85 @SivaprakashRNTBCI

Hello guys,
Let me jump in for my colleague, here is the current config of Enable Operation

The error message is

[SatishAtike]

Hi @Blazelip , response mapping attribute path should start with “$.”
It should be like this
Supervisor Attribute path------$.approver.username
Even though you configured rooth path, in the response mapping, it should be started with $ always.

[SatishAtike]

Try this and let us know if this works for you.

[Blazelip (Dmitrii Filiukov)]

@SatishAtike Hi
Nothing changed, here is the Attribute Mapping I’ve tried

[KRM7 (Krishna Mummadi)]

Enable Account -1 URL, you should use plan not getobject

[Blazelip (Dmitrii Filiukov)]

@KRM7 Hello

The official documentation prescribes to use the getobject, but I’m desperate enough to test with the “plan.” and it also didn’t work out

[KRM7 (Krishna Mummadi)]

getobject should be used when it is single account aggregation, since it is provisioning operation you should use plan

What is the response mapping configured in first call and get us the sample API response masking sensitive data to cross check the root path

[Blazelip (Dmitrii Filiukov)]

@KRM7

API Sample

{
    "username": "noe.sandbox.DEMENALE",
    "entity": "9999",
    "firstname": "Alexander",
    "lastname": "Test",
    "active": true,
    "email": "Alexander.Test@email.com",
    "isCompanyAdministrator": false,
    "isController": false,
    "expensePolicy": "Expense General",
    "additionalReference": "01000000",
    "approver": {
        "username": "noe.sandbox.DEDODODO",
        "firstname": "Dodo",
        "lastname": "Dododo",
        "entity": "9999"
    },
    "created": {
        "on": "2026-04-14T14:12:00",
        "action": "Created"
    },
    "updated": {
        "on": "2026-05-08T17:02:00",
        "action": "Updated"
    }
}

[KRM7 (Krishna Mummadi)]

Put $ in root path and remove from attribute path, it will work

[Blazelip (Dmitrii Filiukov)]

@KRM7
I tried it as well, no luck

[Blazelip (Dmitrii Filiukov)]

Pinging this again in case anyone has any insight here, I’m kind of hitting a wall and don’t understand why this isn’t working

[SatishAtike]

For the user you are testing in Sandbox, did you test through postman directly? Please check if same api through is working or not.
Also, looks like in the enable account-1, you are doing getObject, not actually doing enable operation. Could you please confirm?