425 - Too Early
HTTP 425 Too Early means the server is unwilling to process a request that could be replayed.
Last reviewed: February 12, 2026|Editorial standard: source-backed technical guidance
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
- -Client sends replay-sensitive request in early data context.
- -Server anti-replay policy blocks request timing window.
- -Retry logic resubmits unsafe requests without replay protection.
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-Data` signaling 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')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_rejected` metric by endpoint so replay-risk hotspots are visible before incidents.
Decision Support
Compare Guide
401 Unauthorized vs 403 Forbidden: Auth vs Access Denied
Fix 401 Unauthorized vs 403 Forbidden by separating authentication failures from authorization denials, then apply the right login or permission fix fast.
Compare Guide
403 Forbidden vs 404 Not Found: When to Hide Resources
Use 403 for explicit access denial, or 404 to conceal resource existence when security policy requires reducing endpoint and object enumeration risk.
Playbook
Authorization Denial Playbook (403 / AccessDenied / PERMISSION_DENIED)
Use this playbook to triage policy-based access denials after authentication succeeds, isolate the deny layer, and apply least-privilege remediation safely.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.