We are currently running 3.0.2 and still testing the File Upload Utility 4.0.0. Will this api still continue to work after July 8th or just unsupported? Hopefully try and get this out the following week.
Hello @putty , do you have any updates on whether the deprecation will be postponed OR if itâs possible to use this endpoint in Workflows?
I just tried swapping the new api in our workflows. Still doesnât appear to be working.
Hi,
What is the latest update on this? When is the deprecation date for this API?
Regards,
Jishnu
The deprecation for POST /api/source/loadAccounts has been pushed out to July 15th, 2024.
The enhancement to POST /beta/sources/:id/load-accounts to support x-www-form-urlencoded as an additional content type so that unoptimized aggregations can be triggered from workflows is now in final testing. I will post an update here as soon as the ETA for GA release is confirmed.
3 Likes
thank you so much Christina;
1 Like
Our planned release schedule for the enhancement to support x-www-form-urlencoded is:
- Sandbox tenants: Thursday, July 11
- Production tenant phased rollout:
- Batch 1: Wednesday, July 24
- Batch 2: Wednesday, July 31
- Batch 3: Tuesday, August 6
Thanks @colin_mckibben.
So does this mean that the deprecation of âPOST /api/source/loadAccountsâ has been extended beyond July 15?
So this has broken some of my workflows in my production now, as the old API has been turned off and the solution has not been implemented yet. This really is unacceptable.
What will be the exact solution for when this does roll out?
Is it the same as it was:
I am not trying to be mean here, just offering up some advice. This thread is full of not so great things⌠Come on Sailpoint you can definitely do better here.
This isnât good:
- Scheduled shutdown dates without clear replacement dates (this is not the first API I have seen this done with). Downstream Developers need time to react, and are being âsqueezedâ by other upstream developers?
- Significant alarm from customers without any changes to how things are being handled.
- Multiple schedule slips from not properly implementing api replacements. (this other sailpoint tool alot of customers use also uses this apiâŚ)
Iâm used to declaring something deprecated (along with a message of you should use this other new documented thing instead!), (time passes) Declaring something Obsolete (heads Up! your headed for a bad time!), (time passes) and then removing something.
Thats not happening here, your skipping some steps, and to be honest, it makes SailPoint look bad. It definitely is stressing out your customers.
Again. please read this as a âweâre in this together for the long run, and the way your doing stuff is stressing us out, we love you, dont hurt usâ tone.
<3
9 Likes
Itâs not even my birthday and our team echos chad Carltonâs sentiment, this is unacceptable to have no final build or production ready solution for our production environments. We are not interested in implementing a workaround to an existing workaround, this issue is part of standard functionality within the product and should be addressed immediately! SailPoint please resolve this before our loyalty is completely lost.
We are also requesting that the production release date be pushed out until a stable and production ready solution is available.
Thank you.
4 Likes
Totally agree, this is already a workaround for something that is supposed to be a product functionality that is NOT available when it should be available in the UI under Scheduled Aggregations. Being able to run Unoptimized Aggregations is pretty important to be able to get real time changes from our Authoritative Sources. I donât see why we need to use workflows to compensate for a product feature that is lacking.
It is totally bad API design/practice to replace an existing functionality with one that is lacking feature that is available in the current version. And replacing the CC version with a Beta one means, we are still not in a stable API for core functionality that is needed.
If there is no proper replacement, SailPoint should consider moving the timeline of when they should push the changes to PRODUCTION. Leaving everyone hosed with no proper course of action or even support is not acceptable.
3 Likes
Or just allow scheduling Unoptimized Aggregations via the UI, removing the need to use workflows as a workaround! It would be nice to be able to schedule | SailPoint Ideas Portal
1 Like
@colin_mckibben @colin_mckibben @christina_gagnon Can you confirm if the deprecation has been pushed back to accommodate the prod rollout dates?
I was wondering what was this about since the old endpoint was working for me ⌠until now âŚ
Hi All,
First, we thank you for your patience as we recognize that the Non-Public API Deprecations have required that many of our customers take action to accommodate changes to call our updated public APIs that that are used in their implementations. The public APIs replace outdated APIs with more secure and performant APIs that will allow us to support our customers more effectively in the future.
In regards to the deprecation of the /api/source/loadAccounts endpoint and its replacement:
- We heard your frustrations with a potential weeksâ long gap. The team has expedited the change to support x-www-form-urlencoded in POST /beta/sources/:id/load-accounts which would allow for disabling optimization via workflows. This has been enabled for all production tenants last night. If you still find issues, please flag this to me immediately so our team can react.
- We know that this endpointâs deprecation in particular has had to get pushed out a couple times past our original deprecation date, and that was to accommodate a late replacement as a result of unforeseen engineering hurdles. We apologize for any inconvenience here.
- Customers should feel confident in leveraging Beta APIs in production. We release APIs in Beta to allow for our team to make updates to the APIs prior to versioning them, but our process requires that we provide advance notice if any breaking change is to be made prior to making a change so that our developer community is aware.
Again, thank you for working with this large API deprecation effort as our goal is to move forward together with better API support going forward. Please reach out to me and/or your CSM if youâd like to chat further.
Christine Whitlock
[email protected]
Sr. Manager, ISC Product Management
Hi @christine_whitlock ,
Thank you for chiming in. I have a few concerns/questions:
- The handling and communication regarding this particular deprecation
- Jul-9 is the last communication regarding POST /api/source/loadAccounts here stating that the endpoint will be deprecated on 15-Jul
- On Jul-11 it is announced here that the replacement API will be updated on Jul-24/31/Aug-6 for various batches of ISC production tenants. Note that this is 9 to 22 days past the date of deprecation for the original API
- What are customers expected to do in those 22 days?
- The use of /beta APIs for indeterminate amount of times is not acceptable. This is not how a service provider with mature processes operates. Some organizations have policies against using beta APIs in production environments. When a new API is introduced or functionality is being changed, the beta API should be published for a known amount of time with a communicated plan for when it will be migrated to /v3.
- How should we flag something to you? This isnât a bug. SailPoint deprecated a working API before providing a suitable replacement. It isnât an SR. Based on my experience with SailPoint support, they would tell us that we are trying to use a deprecated API, and that the product no longer supports running an unoptimized aggregation from a workflow.
SailPoint has lost quite a bit of trust with itâs handling of this situation.
-Mike
2 Likes
Hi All,
We have heard your frustrations and reviewed our options to continue supporting our customers for this endpoint late yesterday. After discussions and thought from the team, we have found a way to re-enable /api/source/loadAccounts for an additional two weeks to give our customers more time to make the necessary changes to switch to /beta/sources/:id/load-accounts. We will re-enable the endpoint in all production tenants on Monday (7/22) morning US time. This means that /api/source/loadAccounts will be finally deprecated the week of August 5.
Although a non-breaking change was introduced this past week to the beta endpoint, this change was specific to the use case where customers disabled optimization via workflow. If you do not need that, the replacement has been available since mid-April. Please also make sure that your File Upload Utility is up to date as well, which leverages the new beta endpoints.
We appreciate the feedback and your cooperation, and we hope this provides some relief.
Hi Mike,
I completely understand that this endpoint deprecation was challenging. On the SailPoint side, the team was trying to remain flexible and accommodate unforeseen engineering hurdles in developing the beta. This resulted in a bit of shifting timelines and coordination that made it difficult to track. The beta was published on our site and shared in this discussion topic in mid-April. The change to accommodate the unoptimized aggregation support for workflows was fully rolled out this past week, as that was something flagged to us after we released the beta. In hearing the latest feedback, we accelerated that production rollout and have now extended support for the legacy API for two more weeks. We hope this helps.
Regarding your feedback on our beta APIs and versioning, our Product Team has been hard at work on maturing our processes. This is feedback that weâve heard from our community in the past, and weâre looking forward to sharing some updates soon.
Please feel free to email me at my email address, and please include your CSM for awareness if youâd like to discuss further. Thank you for your feedback. We truly appreciate your engagement.
Christine Whitlock
[email protected]