Signed webhook delivery

Use an enabled destination API to create a destination, save its signing secret once and complete its challenge. Outbound verification and delivery share the reviewed SSRF policy: public destinations only, validated pinned IP, TLS hostname verification, no redirects and bounded deadlines. A private address, VPN-only host or local metadata endpoint is not a valid callback target.

Verify before processing

Download /docs/downloads/verify.go for the maintained Go receiver implementation. It verifies the exact raw bytes, signature header identifiers and timestamp before parsing customer payloads. The deterministic signature/challenge vectors live in the canonical R10 specification and receiver tests. Do not reconstruct signed bytes by decoding and re-encoding JSON. Use a five-minute timestamp window with a reliable clock. Deduplicate the stable event_id before side effects, including across dead-letter replay. A replay has a new delivery_id; attempt IDs also change across retries. Delivery and attempt IDs are diagnostic identifiers, not logical-effect deduplication keys. Store deduplication durably in your application. Your HTTP success response should follow the durable commit of your receiver's intended work.

Rotation and uncertain delivery

New attempts use the new signing key immediately. Keep the previous receiver key for the documented bounded 24-hour overlap, then remove it. Already-started attempts retain their captured key ID. Never log signing keys, capability URLs, payload bodies or signatures indiscriminately. Cancellation after a network attempt starts does not prove that the receiver did nothing. Dead-letter replay is a new delivery series linked to the same logical event; deduplication still applies. Do not repeat a purchase or external operation merely because a delivery was replayed.

Read this guide as Markdown · Check enabled capabilities · Human dashboard