Adoption paths
Path 1: run it as a dedicated outbound subsystem
Section titled “Path 1: run it as a dedicated outbound subsystem”Choose this when:
- integrations need isolated operational ownership
- support and platform teams need replay and attempt visibility
- endpoint governance should live outside one product codebase
You will mostly use:
@saazip/webhook-coreapps/apiapps/dispatcher
Path 2: SDK-first from another backend
Section titled “Path 2: SDK-first from another backend”Choose this when:
- you want typed endpoint and delivery APIs first
- you want to validate value before centralizing more runtime ownership
You will mostly use:
@saazip/webhook-corepackages/contractsexamples/outbound-integration
Path 3: compose it with the Saazip suite
Section titled “Path 3: compose it with the Saazip suite”Typical shape:
- EventFlow emits events that feed outbound deliveries
- QueueFlow orchestrates retries and replay jobs
- CacheCore accelerates endpoint and subscription read models
What not to do
Section titled “What not to do”- do not use WebhookCore as an inbound webhook gateway
- do not move product subscription semantics into the platform
- do not hide retry behavior inside unrelated services