HTTP 428 Precondition Required

Quick reference

What HTTP 428 means

RFC 6585 defines 428 as indicating that the origin server requires the request to be conditional. This prevents the "lost update" problem: two clients read a resource, both modify it, and the second write silently overwrites the first. By requiring a precondition header (If-Match with the current ETag, or If-Unmodified-Since with a timestamp), the server ensures the client is working with the current version before allowing the update.

428 is about optimistic concurrency control. Rather than locking resources, the server lets multiple clients read and process data simultaneously, then validates at write time that the data has not changed since the client read it. If the precondition fails — the resource was modified by another client — the server returns 412 Precondition Failed instead of silently overwriting.

428 itself means the request did not include any precondition at all. The server requires one for this operation but none was sent. 412 means a precondition was sent but failed (the resource changed).

How conditional requests work

The typical flow with precondition enforcement:

// Step 1: GET the resource, note the ETag
GET /api/documents/42
→ 200 OK
→ ETag: "abc123"

// Step 2: PUT with the ETag as precondition
PUT /api/documents/42
If-Match: "abc123"
Content-Type: application/json
{ "title": "Updated Title" }

// If resource unchanged:
→ 200 OK (update applied)

// If resource changed since read:
→ 412 Precondition Failed (update rejected)

The If-Match header contains the ETag received in Step 1. The server compares this to the current ETag. If they match, the resource has not been modified since the client read it, and the update proceeds. If they differ, another client modified the resource in the meantime, and the server returns 412.

How to fix a 428

1. GET the resource before updating. Make a GET request to the endpoint and capture the ETag or Last-Modified header from the response.
2. Include If-Match or If-Unmodified-Since in the update request. Add If-Match: "<etag-value>" to your PUT or PATCH request using the ETag from step 1. Alternatively, use If-Unmodified-Since: <date> with the Last-Modified value.
3. Handle 412 responses. If the resource was modified between your GET and PUT, you will receive a 412. Fetch the current resource again, reapply your changes, and retry with the new ETag.

428 vs 412 — the conditional request pair

FAQ

What does HTTP 428 Precondition Required mean?

HTTP 428 means the server requires a conditional request header (like If-Match) and the request did not include one. Add the precondition header based on the ETag or Last-Modified value from a prior GET request.

What is the difference between 428 and 412?

428 means no precondition was sent. 412 means a precondition was sent but failed. Both are related to optimistic concurrency control, but 428 means the precondition was missing entirely.

Why do servers require preconditions?

To prevent lost updates: when two clients read the same resource and both attempt to update it, without preconditions the second write silently overwrites the first. Preconditions force each client to verify it is working with the current version before updating.

Which endpoints typically return 428?

PUT and PATCH endpoints for resources that may be concurrently modified — user profiles, documents, settings, shopping carts. Any endpoint where a race condition would cause data loss benefits from precondition enforcement.

Related resources

On this site: HTTP 428 Precondition Required — full guide · HTTP 412 Precondition Failed · HTTP 304 Not Modified · All 4xx client errors

Standards: RFC 6585 §3 · IANA HTTP Status Code Registry · MDN Web Docs: 428