<![CDATA[Why does FusionAuth API return 406 Not Acceptable with gzip encoding?]]>When making API requests to FusionAuth with Accept-Encoding: gzip or Accept-Encoding: gzip, deflate headers, the API returns a 406 Not Acceptable error instead of the expected response.

However, when sending the same request with Accept-Encoding: identity, the request succeeds and returns the expected data.

What causes this issue and how should API clients handle content encoding when communicating with FusionAuth?

]]>https://fusionauth.io/community/forum/topic/3243/why-does-fusionauth-api-return-406-not-acceptable-with-gzip-encodingRSS for NodeWed, 14 Oct 2026 01:50:08 GMTMon, 12 Oct 2026 13:37:39 GMT60<![CDATA[Reply to Why does FusionAuth API return 406 Not Acceptable with gzip encoding? on Mon, 12 Oct 2026 13:37:50 GMT]]>This behavior occurs when the client sends an Accept-Encoding header that includes compression algorithms, but FusionAuth's response handling doesn't support the requested encoding method in certain configurations.

The solution is to explicitly use Accept-Encoding: identity in your API requests. The identity value indicates that no encoding transformation should be applied, which FusionAuth handles correctly.

If you're using an HTTP client library that automatically adds Accept-Encoding: gzip or similar headers, you should:

  1. Override the default Accept-Encoding header to use identity
  2. Or configure your HTTP client to not send compression-related headers automatically

Example:

GET /api/user/search HTTP/1.1
Host: your-fusionauth-instance.com
Authorization: <your-api-key>
Accept-Encoding: identity

This ensures consistent API responses without encountering 406 errors related to content encoding negotiation.

]]>https://fusionauth.io/community/forum/post/8823https://fusionauth.io/community/forum/post/8823Mon, 12 Oct 2026 13:37:50 GMT