Update: I used an Authorization header from another post as an example and crafted mine like this:

{"$type":"SourceCode.SmartObjects.Services.Endpoints.Common.HttpHeader[], SourceCode.SmartObjects.Services.Endpoints.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null","$values":[{"$type":"SourceCode.SmartObjects.Services.Endpoints.Common.HttpHeader, SourceCode.SmartObjects.Services.Endpoints.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null","Name":"Product-Subscription-Key","Value":"PRODUCT KEY WOULD BE HERE=="}]}

This stopped throwing the httpheader error, but now is throwing a 401 Access Denied error (see attached).

Does anyone know if that's still an issue with the httpheader product key being wrong or something else entirely?

Thanks!

I don't believe that should be necessary, but it's a great thought.  The following is info about the Product Catalog API's security models:

There are currently two different security models:

On-Premises Applications running within the bounds of the internal lcompany] network, which will have a acompany] public IP, do not require the Authorization header. A valid subscription key header (Product-Subscription-Key) is still required for On-Premises applications in order to make requests to these APIs.

Off-Premises Applications outside of the internal lcompany] network--those with a non-ncompany] public IP--are required to authenticate via OAuth 2 with a JWT token using the Authorization header in addition to providing a valid subscription key header (Product-Subscription-Key).

My assumption is that because we have  K2 Five installed on an on-prem server, this means we don't need an Authorization token. This is new to me, so let me know whether or not that makes sense.

Thanks for your time!

Thanks again for the response, Tin. It turned out I had missed a character at the end of our Product-Subscription-Key, so that was the issue.