ISC API responses for 400 errors include the header Content-Encoding: UTF-8. This is not a valid value for Content-Encoding: per RFC 9110 §8.4, that field carries content codings from the IANA HTTP Content Coding registry (gzip, br, deflate, zstd, identity, …). UTF-8 is a character set, not a content coding, and the charset is already correctly declared in Content-Type: application/json;charset=utf-8, so the header is both invalid and redundant.
Correct requests (at least for /identities) do not include Content-Encoding.
Most clients won’t notice this but this is impact us when proxying requests through Apigee which sees the response as invalid HTTP.
Steps to reproduce:
Any authenticated call that returns a 400 reproduces it — for example an invalid filter expression against the identities list endpoint:
curl -s -G “https://{tenant}.api.identitynow.com/identities/v1”
-H “Authorization: Bearer $TOKEN”
-H “Accept: application/json”
–data-urlencode ‘filters=name zz “bogus”’
-D -
Observed response headers (excerpt)
HTTP/1.1 400 Bad Request
Date: Mon, 06 Jul 2026 19:21:50 GMT
Content-Type: application/json;charset=utf-8
Content-Encoding: UTF-8 ← invalid: not a registered content coding
Options to fix:
Remove the Content-Encoding header or set a valid value