HTTP 406 — Not Acceptable
HTTP 406 fires during content negotiation: the client’s Accept headers demanded a representation the server cannot produce — a media type, language or charset it has no matching variant for.
When 406 shows up
- API clients requesting an unsupported content type.
- Strict negotiation gateways refusing requests without an acceptable Accept header.
Mocking a 406 response
A response with this status can be faked end to end with a local mock rule — no backend changes needed. The configuration below mirrors the rule fields the ApiSimul editor uses (method, path, status, delay in milliseconds, response body):
{
"method": "GET",
"path": "/api/data",
"status": 406,
"delay": 160,
"enabled": true,
"body": {
"error": "not_acceptable",
"supported": ["application/json", "text/csv"]
}
}Dynamic placeholders such as {{random.name}}, {{string.uuid}} or {{number.int 1 100}} can appear inside the body to vary each response, which keeps client-side list rendering and retry logic honest during development.
Frequently asked questions
What does HTTP 406 mean?
The server cannot serve any representation matching the request’s Accept headers. Loosening the header or asking for a supported type resolves it.
How can I test a 406 response without a real backend?
Define a mock rule with the method and path your client requests and set the status to 406. The example configuration above returns this response after the listed delay, so the client exercises its 406 handling exactly as it would against a live server.
Related status codes
Need the response in your own project? Spin up rules for any status with the ApiSimul mock server, or browse every status code page.