@Mark C this is pretty annoying, as it affects us directly. Of course, we knew that the 2021.2 update would stop HMAC-SHA1 from working, but a few observations on how NetSuite has managed to screw up the transition period which was supposed to start with 2021.1: Supposedly (at least according to the 20201.1 release notes) HMAC-SHA1 would be deprecated, meaning that it would still work for existing restlets and integrations, but would not work for a brand new Restlet created after the 2021.1 release. Unfortunately, that is not true as we created two test restlets specifically to test out that 1. our existing HMAC-SHA1 code could not connect to either of them and that 2. our new HMAC-SHA256 code could connect. Unfortunately, NetSuite apparently couldn’t figure out a way to actually achieve that separation, and HMAC-SHA1 is accepted on the new restlets, which means that, up until now, we don’t even have a way of knowing if our HMAC-SHA256 connections will actually work during the test window, since they are still accepting the older encryption for every endpoint. NetSuite acts as if this is just a simple configuration change, but that is not true, especially for many Java applications like ours. I cannot find a single OAuth 1.0 Java library that supports HMAC-SHA256 out of the box.

Haha. I enjoyed reading this. So painful...

Did you try creating a new integration record for testing?

yeah, I did that specifically. three times, actually, and all of them allow HMAC-SHA1. Even now.

When we updated to 2021.1, we had a new integration go in just prior to our date with SHA1. It failed and all the NS horses and all the NS men couldn't get it working. We finally got a retrograde on that integration until 2021.2, but it was a massive issue. So there are some cases where they do have that 256 requirement, but it sounds very haphazard.