HTTP Status Codes
HTTP 428 Precondition Required
Precondition Required — origin server requires the request to be conditional
The 428 Precondition Required status code indicates that the origin server requires the request to be conditional. It is designed to prevent the 'lost update' problem, where a client retrieves a resource, modifies it, and puts it back to the server while a third party has modified the resource state on the server in the interim.
Visual summary
A quick reference view of how HTTP 428 requires a validator or timestamp condition before the server will allow a state-changing request.
What 428 Means
The shortest useful reading of this status code.
Precondition Required means origin server requires the request to be conditional.
For write safety, the key distinction is that 428 requires the client to supply a condition before the server will even evaluate the state change.
Quick read
Condition required before write
A 428 means the server requires a conditional request before it will allow this state-changing action.
Technical Context
How this status behaves without turning the page into a repair guide.
Condition required
Defined in RFC 6585, the 428 status informs clients that an endpoint enforces precondition safety. When multiple clients work on the same resource concurrently, an unconditional write can silently overwrite changes made by another user.
State protection
By demanding conditional headers (such as 'If-Match: etag-value' or 'If-Unmodified-Since'), the server guarantees that updates are applied only if the client is working from the latest known state.
Related HTTP Codes
Nearby HTTP status codes help clarify how 428 differs inside the same response family.
428
Precondition Required
origin server requires the request to be conditional
304
Not Modified
cached copy on client remains valid and fresh
409
Conflict
the request clashes with the current state of the target resource
412
Precondition Failed
a conditional header did not match current resource state
Common Causes
Preventing 'lost update' conflicts where concurrent clients modify the same resource
A common condition that triggers a 428 response when the web server evaluates the transaction.
API endpoint enforcing optimistic concurrency control with ETag headers
A common condition that triggers a 428 response when the web server evaluates the transaction.
Server requiring an If-Match or If-Unmodified-Since header before accepting PUT or PATCH
A common condition that triggers a 428 response when the web server evaluates the transaction.
Typical Scenarios
A REST API rejects an unconditional PUT update to a shared document until the client supplies an If-Match header
A database management service requires an ETag precondition before applying partial JSON PATCH updates
An e-commerce inventory system requires conditional headers to prevent race conditions during checkout
What To Know
Receiving a 428 status indicates that the request was rejected due to missing conditional headers. Including the appropriate 'If-Match' or 'If-Unmodified-Since' header with the current resource ETag satisfies the server's concurrency requirement.
Frequently Asked Questions
Common interpretation questions about HTTP 428.
It usually returns 428 when the server requires a conditional request before allowing a write, delete, or other state-changing action on a resource that could be updated concurrently.
A 428 means the needed condition was missing or not supplied in an acceptable way. A 412 means the condition was supplied, but it evaluated false against the current resource state.