HTTP 412 Precondition Failed

A condition in the request headers was not met — almost always an If-Match ETag that no longer reflects the current state of the resource.

Defined in RFC 9110 §15.5.13 — 412 Precondition Failed · MDN reference

Where you meet HTTP 412 in production

Optimistic concurrency — two people editing the same record, and the second write arriving with a version the server has already moved past.

Why you would test it

The core of optimistic concurrency. If you never see a 412 in testing, your client is probably not sending If-Match at all, and lost updates are going unnoticed.

What your client should do about a 412

This is the code that stops a lost update, so treat it as a real outcome rather than an error. Re-fetch the resource, decide whether the change still applies to the new version, merge or prompt, and retry with the fresh ETag. Retrying with the same stale validator will produce the same 412 forever.

412 versus the codes it gets confused with

Endpoints that return 412

31 endpoints in this playground answer with 412. Every one is free, needs no signup, and can be called from the browser or with curl.

…and 6 more endpoints across the catalog.

Questions about HTTP 412

How do I get the ETag to send?
From the ETag response header of a prior GET. Send it back verbatim in If-Match.
What is If-Match: * for?
It requires that the resource exists at all, without pinning a specific version.

Other client error codes

All HTTP status codes · All 39 mock REST APIs · Getting started guide

Last updated