Inbound: events arriving from other systems
Lead forms, ad platforms, payment processors and telephony providers all push events to you. Each one is an entry point into your data, which makes each one a security boundary. The three obligations are verifying the sender, resolving which organisation the event belongs to from trusted server-side data, and responding quickly so the sender does not consider the delivery failed.
Never derive tenancy from the body of an inbound request. The mapping from a provider's identifier to your organisation must come from configuration you control.
Outbound: pushing your events elsewhere
Outbound webhooks let another tool react to what happens in your operation. The sender's responsibilities are a stable payload shape, a signature the receiver can verify, sensible retry behaviour, and a delivery log the customer can inspect when their endpoint was down.
Signing matters because the receiving endpoint is usually reachable by anyone. A shared secret and a hash of the payload let the receiver prove the message came from you and was not modified in transit.
What goes wrong in practice
- The receiver is slow, times out, and the event is retried into duplicates.
- The endpoint returns a rejection and the sender keeps retrying anyway.
- Payload shape changes on one side and the other silently drops fields.
- Nobody monitors delivery failures, so weeks of events are missing before anyone notices.
- Sensitive data is included in a payload that ends up in someone's logs.
Integrations are not transactions
Two systems updated by a webhook are not a single transaction. If your record updates and the remote one does not, nothing rolls back automatically — you have two systems disagreeing until something reconciles them.
So design for reconciliation rather than atomicity. Know which system is authoritative for each fact, and have a way to compare and repair rather than assuming they can never diverge.