What it means

Your request's X-Request-Timestamp header is either missing, not a valid RFC 3339 timestamp, or too far from the current time. PreVOP enforces a replay window (default ±5 minutes) to make stolen-request replay attacks impractical.

When you'll see it

• The X-Request-Timestamp header is not present.
• The value is not a complete RFC 3339 timestamp — for example 2026-04-19 without a time, or missing the trailing Z / offset.
• The timestamp is in the wrong timezone format — PreVOP accepts both Z (UTC) and explicit offsets like +02:00.
• The clock on the sending host has drifted by more than the configured skew (default 300 seconds).
• Trailing zeros in milliseconds violate the EPC 267-24 rule — .100 must be written as .1, .000 dropped entirely.

Example response

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
X-Request-ID: 550e8400-e29b-41d4-a716-446655440000

{
  "type":    "https://errors.prod.prevop.alseda.eu/errors/timestamp-invalid",
  "code":    "TIMESTAMP_INVALID",
  "title":   "Timestamp outside replay window",
  "status":  400,
  "detail":  "X-Request-Timestamp is 412 s behind server time (max skew 300 s)"
}

How to fix

1. Make sure the request includes an X-Request-Timestamp header.
2. Format the value as strict RFC 3339 — for example 2026-04-19T14:36:25.465Z.
3. Synchronise your host's clock against NTP. Most modern OSes keep time within 100 ms of UTC automatically.
4. Send the timestamp at the moment of the request, not a cached value from earlier.
5. Retry with a fresh X-Request-ID; the rejected request has not consumed any quota.

Related

• Customer API Contract §3 — Required headers (X-Request-Timestamp format)
• EPC 267-24 §4.2.9 — Date/time representation rules (trailing-zero stripping)