What is your event architecture? If I build against your webhooks, what guarantees do I actually get?

The full executive answer

Internally, every module publishes domain events — an assessment completed, a risk created — onto a typed event bus with a durable outbox. Durable outbox means each event is first written to a database table before any delivery is attempted, so an event is never lost to a process crash; delivery workers then fan out from that table. The catalogue of event types is a single source of truth in code: the internal bus validates against the same published catalogue your webhooks subscribe to, so internal and external views of the platform's events can never drift apart.

What you get as a consumer: every delivery is wrapped in a canonical envelope carrying a unique event ID, the event type, the API version, timestamp and payload — and it is signed with HMAC-SHA256, a keyed cryptographic signature over the exact bytes, sent in a signature header so your receiver can verify the payload came from us and was not altered. Secret rotation is zero-downtime: during rotation we sign with both the new and previous secret, Stripe-style, so a receiver holding either verifies successfully. Verification on our side is constant-time, closing the timing side-channel.

Delivery semantics, stated honestly: at-least-once with retries, exponential backoff, and a dead-letter state for endpoints that keep failing — which means your consumer must be idempotent, deduplicating on the event ID we give you for exactly that purpose. That is the standard contract of every serious eventing system; anyone promising exactly-once delivery over the public internet is selling you something.