HTTP 409 — Conflict
HTTP 409 reports a collision with the current state of the resource: the request is well-formed but completing it would contradict something — a duplicate unique key, a stale version, an impossible state transition.
When 409 shows up
- Optimistic concurrency failures when two writers edit the same record.
- Registration endpoints where the chosen unique value already exists.
Mocking a 409 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/users",
"status": 409,
"delay": 210,
"enabled": true,
"body": {
"error": "email_taken",
"message": "An account with this email already exists."
}
}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 409 mean?
The request conflicts with the resource’s current state. Resolving it means fetching fresh state, reconciling, and submitting an updated request.
How can I test a 409 response without a real backend?
Define a mock rule with the method and path your client requests and set the status to 409. The example configuration above returns this response after the listed delay, so the client exercises its 409 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.