HTTP 425 — Too Early
HTTP 425 guards against replays: the server believes the request might be a duplicate of one still in flight — a real hazard for TLS 1.3 early data — and refuses rather than risk applying it twice.
When 425 shows up
- Fintech endpoints rejecting 0-RTT replayed payments.
- Any API where duplicate execution costs money or state.
Mocking a 425 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/payments",
"status": 425,
"delay": 250,
"enabled": true,
"body": {
"error": "too_early",
"retryable": true
}
}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 425 mean?
The server will not risk processing a possibly-replayed request. Clients retry after the early-data window closes, when the response is authoritative.
How can I test a 425 response without a real backend?
Define a mock rule with the method and path your client requests and set the status to 425. The example configuration above returns this response after the listed delay, so the client exercises its 425 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.