For the technical replacement itself: youâll find numerous examples in the feed, depending on the case. But donât hesitate to jump in if you need help. (POST /api/source/loadAccounts - #106 by tdelorge-mmb)
@colin_mckibben thanks for the clarification. I am assuming thatâs going to get fixed before the private API is depreciated. Or it needs to get fixed in the UI.
@swcoleman Engineering has opened a ticket (ISCAIM-23238) to provide a solution that allows disableOptimization to be used in Workflows. They are looking at two possible solutions.
Support x-www-form-urlencoded as an additional content type, which workflows supports. This would be how the CC API currently behaves: it supports both form-data and x-www-form-urlencoded.
Make disableOptimization a query parameter, which workflows supports.
Engineering will try to release this enhancement before /api/source/loadAccounts is turned off.
I was attempting to use this API with client credentials set up via the API Management in ISC an kept getting a 500 error, other beta endpoints appear to be working fine using client credentials. Switching this over to using a PAT instead appeared to fix the issue. Is this endpoint configured to only use a PAT?
Welcome to the Developer Community Alec. Yes, this API requires a user context, which means either a PAT or an Oauth token with AUTH_CODE grant type. You can usually tell which endpoints require a user context (AKA PAT) if they call out specific user levels in the description. In the case of this endpoint, it states that one of the following user levels are needed.
A token with ORG_ADMIN, SOURCE_ADMIN, or SOURCE_SUBADMIN authority is required to call this API.
@colin_mckibben I think that is by far not correct that there is even the possibility of the old endpoint being shutoff without a proper replacement in place and without giving time to your clients to make the necesary changes.
This particular case does not affect us, but you have already shutdown other endpoints without a proper replacement (import entitlements or get pending tasks for example) without providing a proper replacement.
I will be raising this with our CS and I have already done it to Christopher Caruso (on the Customer Satisfaction & Effort Survey).
I think Sailpoint is not handling this API replacement process in a proper way.
Iâd like to recommend to everyone in this chat that they raise the concern over the replacement for a production endpoint being a /beta endpoint with their Customer Success Manger or equivalent SailPoint representative if they havenât already done so.
Weâve been able to see while testing the behaviour of the replacement endpoint that there has been a change (likely related to troubleshooting and fixing a bug/permission issue) between last week and this week without any notification about it. Have a look at The documented scope for /beta/sources/:id/load-accounts doesn't work - #4 by RRLatFlinders for the details.
@colin_mckibben i liked your post until the last line. I donât think that âtryâ to release before the current API is turned off is acceptable. Not having this feature is going to create work by my team and cycles in our tenant as IDN tries to do things that either were manually done or that IDN just canât do automatically yet. I know you are just he messenger but to take away things before they are fully replaced isnât acceptable.
When I tried to run the replacement for the API :cc/api/source/loadAccounts, â/beta/sources/:id/load-accountsâ,I am getting â500Internal Server Errorâ.In the body part have added the csv file.See the screenshots below . Please help us to understand how we can use it and call the API â/beta/sources/:id/load-accountsâ from postman to do a source aggregation.
The only thing I notice is that you are missing âfileâ as the Key for the file. Besides that, check if the credentials you are using are for a user or an API (it must be a user one)
This particular endpoint is scheduled to be turned off this month. The exact date may vary as we are turning APIs off in batches to prevent widespread issues. If anyone is still using the CC version of this API, I highly recommend you migrate to the beta ASAP.
Colin, the issue with migrating to the new public endpoint is that we canât trigger an unoptimized aggregation with it yet, at least via workflows; and thatâs our use case. I canât migrate to something that doesnât meet my use case at this point.
Then itâs an easy decision - Delay the disablement of the existing until a valid replacement is available and gone through the testing.
Itâs clear this is the most talked about API by far and yet the left hand doesnât seem to be aligned with the right hand which means SailPointâs customers suffer in the end which doesnât seem right to me.
When I tried to do this from postman,I am getting 500 Internal Server Error.
Please go through the screenshots and make me uderstand where I have gone wrong.
