425 - Too Early
HTTP 425 Too Early means the server is unwilling to process a request that could be replayed.
Last reviewed: February 6, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Too Early Mean?
The server rejected an early-data request to avoid replay risk, so the operation must be retried through a safer handshake path.
Common Causes
- -CDN sends 0-RTT early data to non-idempotent POST /payments endpoint protected by replay-risk policy.
- -Client library reuses TLS session and transmits Early-Data: 1 to route explicitly configured as anti-replay.
- -Edge rule permits early data only for GET and HEAD methods, rejecting mutating requests during resumption.
How to Fix Too Early
- 1Disable early data (0-RTT) for replay-sensitive requests, especially non-idempotent mutations.
- 2Retry the same request after full handshake completion without early-data transport.
- 3Add idempotency keys for mutation APIs that may still encounter network-level retries.
Step-by-Step Diagnosis for Too Early
- 1Capture TLS/session details to determine whether request arrived via early data path.
- 2Identify endpoints rejecting replay-prone requests and classify by idempotency safety.
- 3Inspect intermediary behavior that might add or preserve
Early-Datasignaling unexpectedly. - 4Retest with early data disabled and verify safe retry behavior for affected operations.
Early Data and Replay Risk Assessment
- -Detect 0-RTT usage on affected requests (example: resumed TLS session sends POST in early data and server returns 425).
- -Classify replay sensitivity by method and business action (example: payment capture endpoint must reject replayable early requests).
Retry Safety and Idempotency Controls
- -Verify idempotency-key enforcement for mutating operations (example: duplicate charge prevented when client retries after 425).
- -Audit client retry libraries for unsafe automatic replay (example: transport retries POST immediately without full handshake).
Implementation Examples
curl -i -X POST https://api.example.com/v1/resource -H "Early-Data: 1" -H "Content-Type: application/json" -d "{"sample":true}"
# Response:
# HTTP/1.1 425 Too Early
# {"error":"Too Early","code":"425"}const response = await fetch('https://api.example.com/v1/resource', {
method: 'POST',
headers: { 'Content-Type': 'application/json', 'Accept': 'application/json', 'Early-Data': '1' },
body: JSON.stringify({ sample: true })
});
if (response.status === 425) {
console.error('Handle 425 Too Early');
}import requests
response = requests.post(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json', 'Content-Type': 'application/json', 'Early-Data': '1'},
json={'sample': True}
)
if response.status_code == 425:
print('Handle 425 Too Early')Seen in Production
TLS resumption sends non-idempotent request in early data
Frequency: common
Example: Checkout POST arrives via 0-RTT and server rejects with 425 to prevent replay risk.
Fix: Disable early data for checkout path and require full handshake before mutation submission.
Client retries 425 without idempotency protection
Frequency: rare
Example: Mobile client auto-retries purchase request after 425 and risks duplicate side effects.
Fix: Add idempotency key on writes and enforce replay-safe retry policy tied to full handshake completion.
Debugging Tools
- -TLS session and early-data telemetry
- -Idempotency-key and duplicate-operation logs
- -Client retry trace instrumentation
- -Ingress handshake mode diagnostics
How to Verify the Fix
- -Repeat affected calls with early data disabled and confirm 425 no longer appears.
- -Validate replay-sensitive endpoints reject unsafe early-data requests while allowing safe retry path.
- -Monitor duplicate-operation and retry metrics to confirm idempotency protections hold.
How to Prevent Recurrence
- -Define explicit policy: allow early data only for idempotent/read operations.
- -Enforce idempotency keys and replay guards on all critical mutation endpoints.
- -Add transport-level integration tests for TLS resumption and early-data edge cases.
Pro Tip
- -surface an
early_data_rejectedmetric by endpoint so replay-risk hotspots are visible before incidents.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.