406 Not Acceptable
The server cannot produce a response matching the Accept headers on the request.
Status
HTTP/1.1 406 Not Acceptable
Details
- Category: 4xx
- Status: Standard. Registered with IANA and defined by a current standards-track RFC.
- Specification: RFC 9110 §15.5.7
- Cacheable: Cacheable by default
- Response body: Allowed
- Retry: Retry only after changing the request
406 is the result of failed server-driven content negotiation. The client asked for a media type, language, character set, or encoding that the server cannot supply, and the server chose to fail rather than send something the client did not ask for.
Most servers prefer to ignore an unsatisfiable Accept header and serve their default representation, so genuine 406s are rare. When one appears, the usual culprit is an over-specific Accept header generated by a client library or copied from documentation.
Common causes
- Accept names a media type the endpoint does not produce, for example application/xml against a JSON-only API.
- Accept-Language requests a locale the site does not publish and the server refuses to fall back.
- A vendor media type with a version parameter that no longer exists.
How to fix it
As the client
- Relax the Accept header, or send Accept: */* to see what the server produces.
- Check for a versioned vendor media type in the API documentation and use the current one.
As the server
- Prefer serving a sensible default over failing, and describe the available types in the error body when you do fail.
- Set Vary correctly so caches do not serve a negotiated variant to the wrong client.
Examples
Asking for a media type the API does not produce
HTTP request
GET /api/v2/order/40213 HTTP/1.1 Host: api.example.com Accept: application/xml
HTTP response
HTTP/1.1 406 Not Acceptable
Content-Type: application/json; charset=utf-8
{"error":"not_acceptable","supported":["application/json"]}