SailPoint plans to enable HTTP2 in Cloudflare on Jul 27, 2026 at 10am CDT. This provides better security and performance than HTTP1.1 but we are not deprecating HTTP1.1 at this time. All environments will be affected simultaneously.
How long is the maintenance and why?
The change is immediate. The reason we are communicating this change is that you could be affected if you are making API calls to ISC that expect case-sensitive header keys to be returned. Example header key X-Total-Count will become x-total-count once HTTP2 is enabled. There is a scenario, though unlikely, that customers API calls or scripts could fail to expect this change and handle it gracefully.
Action Required
Customers should review their API calls and scripts, especially those they deem critical, to ensure they will not be impacted by this change. If customers suspect they have been impacted by this change after it has been made, they should know to put in a ticket with SailPoint Support who will assist them in troubleshooting any API calls/scripts they suspect are affected.
@collin_cornelius where do I raise that the API documentation is now needing updated, There are references to Response headers but they are now incorrectly cased, such as Retry-After, X-Total-Count, etc.
This seems like a pretty big deal to roll to all environments at the same time. We have noted issues with paging templates using things like $responseHeaders.Link changing to $responseHeaders.link and not resolving. It may need a little more due diligence before mass rollout as it could trigger attempted mass deletions on sources.
One of our sandbox sources started collecting the first page, considered that complete, and then attempted to deleted everyone that wasn’t on that first page. Thankfully the delete threshold prevented that, but that seems to be a bad idea to subject people to all at once.
Hi Kyle, we haven’t enabled HTTP2 for customers yet, so the issue you saw with $responseHeaders.Link changing to $responseHeaders.link was a separate issue (speculating but maybe that was a similar change made by a 3rd party you’ve integrated with).
In terms of due diligence, we’ve had HTTP2 enabled internally in our Dev environment for about 8 months now so it has been tested extensively, however there is still the possibility that customers could have custom scripts that will be affected. If you are concerned this may be the case, please submit a support ticket with config details so SailPoint can review. Thanks.
I am only seeing this message just now, and I can imagine many customers haven’t seen this yet. Have they been informed by their CSMs on this potential breaking change?
There is a scenario, though unlikely, that customers API calls or scripts could fail to expect this change and handle it gracefully.
But you also mention:
you could be affected if you are making API calls to ISC that expect case-sensitive header keys to be returned.
Many scripts would view the response as hash objects and hashes are often case sensitive. Since the string “Test” is not the same as string “test”, headers["Test"] will also return different results as headers["test"]
In addition, based on the screenshot from @akhurana where, if I understand correctly, SailPoint Support is saying that ISC workflows are fully compatible.
To test this I ran a simple two step workflow.
Call HTTP operation to list an ISC API (limit=1, count=true)
Define variable to grab the count, one using X-Total-Count and one using x-total-count.
Output: the HTTPS action still returns X-Total-Count (which is different when calling the API from Bruno), and only one of the two define variables was able to catch it:
So based on this it seems that ISC workflows is case sensitive as well, but in the way that calling it with x-total-count is failing. Shouldn’t workflows work nowadays when we call it with x-total-count? It seems that workflows is not case insensitive, but that it rather compensates for this change by making these headers uppercase again.
@collin_cornelius We’re observing similar patterns in our tests as described here by Angelo. Please provide more insights on deprecation timeline, backwards compatibility and best practices for new, upcoming solutions.
Hi Angelo, this was tested internally and we’ve had no reports of issues with Workflows since enabling HTTP2 for customers back on July 27th. However, we’re taking a look at your specific question and will get back to you.
Update, our Workflows team is modifying the Workflow service with “a format change with the data handling in the workflow to be consistent with the lower-case header conventions of HTTP2.” This change has not yet been rolled out but is expected to be GA by end of next week.
Then this of course makes the following question relevant again: "Is this not going to break all existing workflows where the customers are currently using something like $hTTPRequest.headers[“X-Total-Count”] in their workflow definition?
Same, but we also have other teams that have built some custom integrations we need to reach out to for them to also change some code. It was just a bummer and feel it wasn’t communicated well at all. I was literally looking at the API docs specifically on Standard Collection Parameters and its still wrong even though I reported this in my P1 (later moved to P2) ticket.
