Webhook guide

Treat every callback as
untrusted and repeatable.

Reliable webhook processing assumes duplicates, delays and provider retries are normal.

TH / DOCS
Principle→Boundary→Verification
implementation guidance · not a public API guarantee
01 / VERIFY

Authenticate before side effects

Validate the provider signature or equivalent authenticity mechanism before changing payment, order or fulfillment state. Reject malformed or unverifiable payloads.

02 / IDEMPOTENCY

Make duplicate delivery harmless

Persist a provider event or transaction identifier before applying irreversible side effects. A repeated callback should converge on the same domain state.

receive → authenticate → deduplicate → validate transition → commit → acknowledge
03 / RETRIES

Retry work, not unsafe side effects

Acknowledge only after the durable handoff required by that integration succeeds. Long-running downstream work should move to a queue with bounded retries and a dead-letter path.

Project-specific contracts win.

These pages describe Thonem implementation patterns. Exact endpoints, payloads, credentials, retry rules and provider capabilities must be taken from the deployed project and its provider documentation.