> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.6mm.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.6mm.com/_mcp/server.

# Webhook-Signaturverifizierung und Idempotenz

Webhooks benachrichtigen ein Partner-Backend über asynchrone Änderungen des Geschäftszustands. Da die Zustellung erneut versucht werden kann, muss jeder Empfänger die Signatur vor der Analyse vertrauenswürdiger Daten überprüfen und das Ereignis idempotent verarbeiten.

<h2 id="webhook-headers">
  Webhook-Header
</h2>

| Header              | Beschreibung                  |
| ------------------- | ----------------------------- |
| X-Agent-Zeitstempel | Unix-Zeitstempel in Sekunden. |
| X-Agent-Nonce       | Wiederholungsschutz-Nonce.    |
| X-Agent-Signatur    | HMAC–SHA256 Unterschrift.     |

```text
timestamp + nonce + rawBody
```

Verwenden Sie beim Rekonstruieren des signierten Werts genau den rohen Request-Body, der über HTTP erhalten wurde. Das Parsen und Neuserialisieren JSON zuerst kann den Leerraum oder die Feldreihenfolge verändern und eine andere Signatur erzeugen.

<h2 id="verification-flow">
  Verifikationsfluss
</h2>

1. Lesen Sie die Zeitstempel-, Nonce- und Signatur-Header.
2. Erfassen Sie den unveränderten rohen Request-Körper.
3. Baue `timestamp + nonce + rawBody`.
4. Berechnen Sie HMAC–SHA256 mit dem Partner API Geheimnis.
5. Vergleichen Sie die berechneten und empfangenen Signaturen mit einem konstanten Zeitvergleich.
6. Wenden Sie die genehmigten Zeitstempel-Frische- und Nonce-Wiederverwendungsprüfungen an.
7. Erst nach erfolgreicher Verifikation das Ereignis analysieren und verarbeiten.

Wenn ein offizieller Agent SDK -Verifizierer verfügbar ist, verwenden Sie ihn, anstatt einen unabhängigen Unterzeichnungscode zu führen.

<h2 id="order-idempotency">
  Orderidopotenz
</h2>

| Fall                      | Handhabung                                                                   |
| ------------------------- | ---------------------------------------------------------------------------- |
| Erster Übertragungsantrag | Schaffen Sie ein weltweit einzigartiges agentOrderNo.                        |
| HTTP Auszeit              | Fragen Sie die ursprüngliche agentOrderNo ab, bevor Sie eine neue erstellen. |
| PROCESSING Antwort        | Warte auf den Status der Webhook- oder Abfragereihenfolge.                   |
| Wiederholter Webhook      | Deduplizieren Sie nach Idempotenzschlüssel und Endstatus.                    |

<h2 id="recommended-idempotency-record">
  Empfohlene Idempotenzaufzeichnung
</h2>

Speichern Sie genügend Informationen, um eine wiederholte Lieferung zu erkennen und sicher zurückzugewinnen:

| Spielfeld                         | Zweck                                                                              |
| --------------------------------- | ---------------------------------------------------------------------------------- |
| Ereignis- oder Geschäftsschlüssel | Identifiziert eindeutig die Benachrichtigung oder Operation.                       |
| PartnerOrdersnummer               | Verbindet das Ereignis mit der ursprünglichen Anfrage.                             |
| Payload-Hash                      | Hilft, widersprüchliche wiederholte Nutzlasten zu identifizieren.                  |
| Aktueller Verarbeitungszustand    | Unterscheidet empfangene, verarbeitete, erfolgreiche und fehlgeschlagene Arbeiten. |
| Endgültiger Geschäftsstatus       | Verhindert, dass eine terminale Aktion zweimal angewendet wird.                    |
| Bearbeitungszeitstempel           | Unterstützt Richtlinien zur Untersuchung und Verwertung.                           |

Beziehen Sie die Geschäftsänderung und die Impotenzdatensatz, wo möglich, in derselben Transaktion ein. Ein wiederholtes Ereignis sollte das bereits bekannte Ergebnis zurückgeben, anstatt die Bilanz, Reihenfolge oder Benutzeränderung erneut anzuwenden.

<h2 id="timeout-and-retry-rule">
  Auszeit- und Wiederholungsregel
</h2>

Ein HTTP Timeout beweist nicht, dass die ursprüngliche Anfrage fehlgeschlagen ist. Abfrage der Operation mit dem ursprünglichen `agentOrderNo`oder warten Sie auf den Webhook, bevor Sie entscheiden, ob eine weitere Aktion erforderlich ist. Das Erstellen einer neuen GeschäftsOrdersnummer nach jedem Timeout kann zu doppelten Kapitalbewegungen führen.

<h2 id="production-checklist">
  Produktionscheckliste
</h2>

* Verifizieren Sie die Signatur vor JSON Parsing oder Geschäftsverarbeitung.
* Erhalte den rohen Körper unabhängig von der geanalysten Nutzlast.
* Veraltete oder wiederholte Anfragen gemäß der genehmigten Integrationsrichtlinie ablehnen.
* Ereignisverarbeitung für wiederholte und nicht in der Reihenfolge zugeteilte Zustellung sicher zu machen.
* Protokolliere Ereignis-IDs, Partnerbefehlsnummern, Verarbeitungsergebnis und Anforderungszeit.
* Geheimnisse und Signaturwerte aus Protokollen und Support-Anhängen zu schwärzen.

<h2 id="related-docs">
  Verwandte Dokumente
</h2>

#### [Geheimnisse & HMAC Signieren](/de/sdk/security/secrets-signing)

Schützen Sie das API Geheimnis, das für Anfragen und Webhook-Verifizierung verwendet wird.

#### [Agent SDK Überblick](/de/sdk/agent-sdk/overview)

Überprüfen Sie den vollständigen Backend-Integrationsworkflow.

#### [SDK Fehlerbehebung](/de/sdk/security/troubleshooting)

Untersuchen Sie abgelehnte Unterschriften, wiederholte Ereignisse und ausstehende Operationen.