Hey Everyone,
I’m just wondering if anyone else out there has noticed that this end point no longer functions as documented?
Previously it worked by providing the accessRequestId and some other things in the body of the request to close out an Access Request. We used this in a workflow to detect and deny Access Requests that have SOD violations.
We opened a ticket with SailPoint and they have confirmed this was a bug introduced in the last week to 2 weeks while patching a bug for another customer.
They still have not fixed this but are working on it and might have something today in preprod to test.
I’m just curious how we are the only ones using this api endpoint.
love to hear back from y’all.
Kirk
oh, i should mention that the same /access-request/close in v2024 and v2025 although experimental also broke.
oh, i forgot to mention that what broke is it no longer accepts the accessRequestId and instead wants the identityAccessItemId.
this is weird because it takes more steps to get this value and we get the accessRequestId in the response when and Access Request is submitted so it doesn’t make much sense.
are you using /v2024 experimental or non-experimental?
I would expect non-experimental not to change or break.
All the endpoints broke!!! /beta, /v2024 and /v2025!!!
They were supposed to deploy a fix in pre-prod last week but not sure if it went in.
We had to end up completely reworking our workflow to use different triggers and endpoints in the flow.
1 Like
Just posting here in case anyone is curious. We ended up completely reworking our Workflow with different Event Trigger and API endpoints.
We were using the Access Request Dynamic Approver Event Trigger and then if an SOD violation was found on the Access Request Status, then we’d use the subject endpoint to close the request as FAILED with a message.
The new solution we like better is use the Event Trigger: Access Request Submitted with a Async response type.
Then we do the same SOD check on the Access Request Status and if a violation is found, then we use the callbackUrl with the body that has “approved”: false, and “comment”: has a message we want displayed in searches. With this approach the Events we pull for Auditors shows Denied rather than Failed which has better optics.
1 Like