This API’s shutoff date has been extended to November 1st.
The replacement API is
For a full mapping of /api/app replacements, please see this doc
IDN-V2024 Public Preview Apps API mapping from legacy CC endpoints-090924-215538.pdf (595.0 KB)
v2024 experimental endpoints will be available by end of this week. Both beta and v2024 experimental may change with little to no notice. Please see our API versioning strategy for more information.
Hi @colin_mckibben ,
Any update on replacement for this API cc/api/app/list?
Hi Krity,
Once the replacement API is available, I will update this post with the replacement. We are extending the shutoff date to make sure that users have enough time to migrate to the new API.
Hi @colin_mckibben,
The latest edit of the top post says that the replacement API will be available by the end of July, 2024, which is in two days from now. Is this time still correct?
If so, great! We will look forward to seeing the replacement in the next two days.
If not, can you please update it with the postponed date, or if there is no such date, update the post to mention this, such that we can prepare for this API not getting replaced for a long time.
We have important new use cases involving applications and if it still takes a long time before the replacement API becomes available, we would need to build the use case using the current available API, but if they are indeed available by the end of this month, it makes sense to wait for that.
Kind regards,
Angelo
The replacement for this API will be available by September 3rd. To give users enough time to migrate to the public replacement, this API’s shutoff date has been extended to November 1st.
The replacement APIs are now available. Please see the first post for more details.
@colin_mckibben I have a few questions on the /apps APIs:
Thanks!
@colin_mckibben It appears that the created/modified timestamp format being returned by the new Apps API is inconsistent as shown below:
{
(full response omitted for brevity)
"id": "47a52fb846364c89afe86257973d080a",
"name": "IAM Appetizer SAML Demo App",
"created": "2024-05-02T15:01:54.809Z",
"modified": "2024-05-02T15:05Z" <-- missing seconds and millis
}
This is causing errors in the Go SDK which we can’t workaround without making HTTP calls directly → parsing time "2024-05-02T15:05Z" as "2006-01-02T15:04:05Z07:00": cannot parse "Z" as ":"
I’ll cross-post this as an issue in the Go SDK repo
The beta APIs will not go away anytime soon. The versioning document explains this in more detail: API Versioning Strategy | SailPoint Developer Community
The Postman API has been plaguing us for quite some time. It is not trivial to release a new API version into our Postman space because of this. We are going to change how we distribute our Postman collection to use a github link instead of a Postman collection. Stay tuned for an announcement about this change.
Unless there is a critical bug or feature gap with the new Apps API, there will be no more extensions to the CC Apps API.
@colin_mckibben I think I may have found a BUG with the new GET /source-apps/{id} API. It appears that if the app has appCenterEnabled = false, GET /source-apps/{id} will return an HTTP 404 Not Found. If appCenterEnabled is set back to true the GET /source-apps/{id} call will successfully return the app JSON.
Steps to reproduce:
POST /source-apps)GET /source-apps/{id}) → app is returnedappCenterEnabled = false (PATCH /source-apps/{id})GET /source-apps/{id}) → FAILS. HTTP 404 app not foundappCenterEnabled = true (PATCH /source-apps/{id})GET /source-apps/{id}) → app is returnedReminder, this API will be turned off on November 1st, 2024. Please make sure you migrate to the replacement API ASAP.
Hey, there’s a pretty major shortcoming with this endpoint list-access-profiles-for-source-app | SailPoint Developer Community
It has a limit of 250 objects returned in response but doesn’t respond to count=true parameter and does not return ‘X-Total-Count’ header so we can’t implement pagination
Although X-Total-Count isn’t implemented, you can still paginate. Just keep paginating until you receive a page that has less than 250 items. At that point, you have reached the end of pagination.
According to the documentation, offset is also not implemented. But even if it is implemented, this is another example where ISC APIs are not adhering to its own set standards meaning the clients would need to spend additional time to overwrite the code they use to paginate over objects for this specific type.
I think that instead of (or at least in addition to) suggesting workarounds to functionality incompleteness it would be nice if you could tell the engineering team that they have missed adding some important parts of the list objects API (count, offset, or even showing the list of access profile ids in the get and list source-apps APIs, just like it it shown in the patch source-app API regardless of which patch operations you use)
Or is this related to my question (gentle reminder here: A Smoother Development Experience: Introducing Our New API Versioning Strategy! - #38 by angelo_mekenkamp) where you said in mid September 2024 that the engineering team related to application APIs is not going to make anymore changes to these APIs, just because it was almost 2025 already?
Kind regards,
Angelo
This reminds me of the case when I was doing just that instead of relying on X-Total-Count, until I have used an API endpoint that threw errors when you went after the last page.
And most of us want to have one generic function that makes the API call for multiple endpoints, and not handle pagination for each endpoint in a different method.