Why does FusionAuth API return 406 Not Acceptable with gzip encoding?

FASupportBot

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?

FASupportBot

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:

Override the default Accept-Encoding header to use identity
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.