Was es bedeutet

Der Header X-Request-Timestamp Ihres Requests fehlt entweder, ist kein gültiger RFC-3339-Zeitstempel oder liegt zu weit von der aktuellen Uhrzeit entfernt. PreVOP erzwingt ein Replay-Fenster (standardmäßig ±5 Minuten), damit gestohlene Requests nicht erneut abgespielt werden können.

Wann Sie diesen Fehler sehen

• Der Header X-Request-Timestamp ist nicht vorhanden.
• Der Wert ist kein vollständiger RFC-3339-Zeitstempel — z. B. 2026-04-19 ohne Uhrzeit oder ohne abschließendes Z / Offset.
• Das Zeitzonenformat ist falsch — PreVOP akzeptiert sowohl Z (UTC) als auch explizite Offsets wie +02:00.
• Die Uhr auf dem sendenden Host ist mehr als das konfigurierte Skew (Standard 300 Sekunden) abgedriftet.
• Endende Nullen in den Millisekunden verletzen die EPC-267-24-Regel — .100 muss als .1 geschrieben werden, .000 ist komplett wegzulassen.

Beispiel-Antwort

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)"
}

So beheben Sie das Problem

1. Stellen Sie sicher, dass der Request den Header X-Request-Timestamp enthält.
2. Formatieren Sie den Wert als striktes RFC 3339 — z. B. 2026-04-19T14:36:25.465Z.
3. Synchronisieren Sie die Uhr Ihres Hosts via NTP. Moderne Betriebssysteme halten die Zeit automatisch innerhalb von 100 ms zu UTC.
4. Senden Sie den Zeitstempel zum Request-Zeitpunkt, nicht aus einem früheren Cache.
5. Senden Sie erneut mit einer neuen X-Request-ID; der abgelehnte Request hat kein Kontingent verbraucht.

Verwandte Themen

• Customer API Contract §3 — Pflicht-Header (Format von X-Request-Timestamp)
• EPC 267-24 §4.2.9 — Regeln zur Zeitdarstellung (Entfernen nachgestellter Nullen)