Identity Security Cloud BP Rule – Recommended Way to Access Attributes from Another Source

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

Hi @punna0001

As part of the solution above, I am trying to enable an account using the following API:

POST ``https://sailpoint.api.identitynow.com/accounts/v1/:id/enable

I have verified that the account ID is correct by retrieving the account using:

GET ``https://sailpoint.api.identitynow.com/accounts/v1/:id

The request body I am sending is:

{
  "externalVerificationId": "manual-enable-via-app-11222111121",
  "forceProvisioning": true
}

The API call completes successfully, returning HTTP 202 Accepted along with a task ID. However, the account remains disabled in ISC.

To rule out any connector issues, I verified that enabling and disabling the same account manually through the ISC UI works correctly, and the corresponding Enable/Disable HTTP operations are configured on the source.

I’m curious why the account is not being enabled when invoking the API, despite the request being accepted.

Could you please shed some light on what might be causing this or suggest any additional troubleshooting steps?

Regards

22

Hello Lalitha, HTTP 202 only means ISC accepted the request and created an async task. It does not confirm that the account was actually enabled. The first thing I would try is sending an empty JSON body:

{}

For this test, remove both externalVerificationId and forceProvisioning.

There is also a similar community case where the API returned a task ID but the account did not change, and using an empty body resolved it.

image
image1832×946 95.1 KB

If it still does not work, check the returned task/account activity and compare it with the activity generated when enabling the same account from the ISC UI.

23

Hi @punna0001

Thanks yes, the empty body did the trick,

Almost reaching the final solution now