Define the event boundary

Record the provider, event type, event ID, receiving endpoint, signing procedure, safe fixture, and operator. Treat the event ID as an identity for a delivery attempt or business event according to the provider's documented meaning; do not replace it with a browser timestamp.

Stripe's webhook guidance is one provider-specific example: it says consumers should not rely on delivery order and explains that retry behavior can continue after a manual resend. That does not establish how another provider signs, retries, or identifies events.

Exercise one harmless path

Use a synthetic, non-production record whose effect can be discarded. Verify the request against the provider's documented signing procedure in the real environment before treating it as accepted. Then record the handler's response, the event ID, the resulting application record if one exists, and who inspected it.

If the handler outcome is unknown, first reconcile through the provider or application record under the same event identity. Do not blindly replay the event. A request that returns success can still leave a later business action ambiguous, while a timeout does not prove the handler did nothing.

Keep a delivery receipt

The local receipt artifact checks for a declared non-production boundary, event ID, documented signing procedure, synthetic fixture, replay rule, owner, and reconciliation path:

npm test --prefix sites/howtox.com/evidence/P115

It validates a record shape only. It does not receive a request, verify a signature, reach a provider, or demonstrate an application's business effect.

Verification checklist

  • One named synthetic event and non-production endpoint are approved.
  • The signature-verification procedure comes from the provider's current documentation.
  • Event identity and replay behavior are recorded before processing work.
  • A named operator can reconcile an unknown result before replaying it.
  • The exercise stays isolated from customer or consequential data.

Does a 2xx response prove the webhook worked?

No. It is one observation at one boundary. Retain the response separately from signature verification, deduplication, and any application-level result the team is actually able to inspect.