I currently use the SailPoint v2025 Python libraries to pull SailPoint approval data into databricks for auditability purposes. This has been working for the past year now with no issues and have not touched the code, but something must have recently changed to break it. I believe it may have to do with the new mandatory end dates in access requests feature but I’m not sure.
When specifically using the list_completed_approvals api call (Access_Request_Approvals | SailPoint Developer Community) I now get a new error that says:
1 validation error for CompletedApproval
requestType
Input should be 'GRANT_ACCESS' or 'REVOKE_ACCESS' [type=enum, input_value='MODIFY_ACCESS', input_type=str]
The code that produces the error:
with sailpoint.v2025.ApiClient(configuration) as api_client:
api_instance = sailpoint.v2025.AccessRequestApprovalsApi(api_client)
try:
approvals = Paginator.paginate(api_instance.list_completed_approvals, sorters="-created", result_limit=100000, limit=250)
This error doesn’t make any sense to me as I am using “list_completed_approvals” which is simply a GET call to the " /v2025/access-request-approvals/completed" endpoint. This call requires no input and I am not providing any input, yet the error is complaining about input. The API documentation itself (list-completed-approvals | SailPoint Developer Community) doesn’t even mention a MODIFY_ACCESS requestType as a possible value, but I understand why it exists. This is why I think it may have to do with the new mandatory end dates, because of the timing and since there are likely end date modification requests due to the feature.
Please advise as this has broken an integration we need for auditing purposes.
Hey @benjaminoriold,
This occured when a new enum was added to the response of the API but the documentation has not reflected those changes as you’ve pointed out:
I’ve modified the SDK to allow for values outside of the current enums while still allowing you to use those enums that do exist in the SDK as inputs to the models and classes.
Please update the SDK to the latest release and let me know if you still experience issues!
Looks like this is working now for me Tyler, thank you so much for getting it fixed up so quick!
Of course! I’m glad it is working again. We need to keep those auditors happy 
If you’re allowed to share, may I ask what kind of report you’re generating? I am always curious how the SDKs are being used out in the wild.
I use the SDK in a Databricks Notebook that pulls in approved access request information (includes requests not requiring approval, so basically any access request that went through to completion). This way we can easily see who requested/approved what access requests and when, as the SailPoint UI doesn’t really give us a great way to do that.
Having the data in a databricks table makes it much easier to search and report on in general, allowing us to easily get info like “I want to see all of the approved requests for Microsoft Visio in the past month and who has been approving them”, “give me the history of the revoke requests for Microsoft Visio over the past week”, “can you show me everything that Benjamin Oriold approved last tuesday”, stuff like that.
Here’s where the SailPoint criticism comes in, sorry if this isn’t really relevant to you but I want to get it out there: a lot of this would be easy to check in the Access Request Administration UI if there were better filters, and maybe a way to download a report of the data displayed after filtering. I’m still baffled that the feature was released without the ability to filter on the name of the access requested, as you’d expect that to be one of the most common use cases for it. It also doesn’t make clear whether the access request was a REVOKE, GRANT, or MODIFY access request unless you click on each individual request to see. It seems like a bit of a common trend that useful features like this get released in half-finished states, needing simple but impactful improvements, then are completely abandoned.
I am aware though that some of this could be gathered via Search, but having it all together in Databricks gives us redundancy and easier querying.