TL;DR
- Put a durable ingress boundary before the CRM or workflow destination when incoming events can exceed its capacity or arrive during an outage.
- Hookdeck is a direct candidate for receiving, inspecting and controlling webhook delivery. Svix Ingest deserves evaluation for inbound webhooks, separate from Svix's outbound service. EventBridge fits an AWS event-bus architecture with archive/replay requirements.
- Price inbound requests, destination events, retries, retention and replay separately. One incoming message can create several billable deliveries.
- Replay must preserve a business event identity. A queue that delivers reliably can still create duplicate sales tasks if the consumer treats every delivery as a new event.
Ingress protects the destination
A revenue event might be a completed call, changed contact, accepted lead or signed order. The producer sends a webhook, but the CRM may be unavailable, rate-limited or undergoing a deployment. A managed ingress service can receive the message independently and control later delivery.
This is a narrower purchase than a full integration platform. Our CRM activity synchronisation guide covers what should move between systems. Ingress concerns whether the incoming event is retained, inspected and delivered under a defined recovery policy.
Separate receipt from business completion. An HTTP success returned to the producer should reflect durable receipt at the chosen boundary. It does not mean the CRM task exists. Record delivery and consumer processing states separately so that the team can find events accepted by ingress but not yet applied.
Verify signatures before trusting the event. Preserve the raw body where signature verification depends on it, then validate the schema. A malformed or unauthorised event should have a visible rejection reason rather than sitting indefinitely in the same retry queue as a temporary destination outage.
Compare the three infrastructure routes
| Route | Best fit | Useful evaluation focus | Cost dimensions |
|---|---|---|---|
| Hookdeck | Operational control of incoming webhooks | Queues, inspection, routing and replay | Requests, destination events, retention and plan features |
| Svix Ingest | Managed inbound webhook reception | Sources, verification and destination integration | Ingest entitlements plus applicable usage |
| EventBridge | AWS event-driven architecture | Event bus, filtering, archive and replay | Event ingestion, archive/storage, targets and replay |
Hookdeck: receiving and delivery control
Hookdeck's documentation describes its Event Gateway as webhook management and queueing infrastructure, including inspection and replay tools. Its pricing distinguishes inbound requests from events delivered to destinations and also identifies discarded requests. The published Team plan starts at $39 per month with seven-day retention; Growth starts at $499 with 30-day retention. Hookdeck explicitly includes retries in an event's price, so a retry attempt is an operating load rather than another separately billed Hookdeck event. That makes the input-to-output fan-out an economic design choice.
Choose it when operators need to investigate failures and manage delivery without building every queue and inspection screen. Test a destination rate cap, a disabled route and an event sent to multiple destinations. Preserve the ingress request ID and the business event ID, because they answer different questions.
The limitation is that operational tooling does not decide whether an old event should still change the CRM. Your consumer must handle duplicates and stale updates. Check the chosen plan's retention, throughput, team access, issue alerts and replay entitlements, then obtain the current unit rates for the measured workload.
Svix Ingest: evaluate the inbound product explicitly
Svix's pricing page identifies Svix Ingest for receiving webhooks separately from the broader sending service. Its March 2025 changelog records public Ingest API availability. Do not compare an outbound delivery tariff to another vendor's inbound gateway simply because both use the word webhook.
This route is relevant when the team wants a managed receiving layer and the documented integrations fit its producer/destination pattern. Evaluate source-specific verification, storage, forwarding and the operator's ability to diagnose an incomplete delivery. Check which capabilities belong to Ingest and which belong to the outbound product.
Choose it on a scoped proposal and fixture. Avoid assuming every feature on the wider platform is included in the inbound tier. Require the commercial schedule to state receiving usage, any destination charges, retention, users and support, so the offer can be compared with the same architecture elsewhere.
EventBridge: bus and archive in an AWS estate
AWS archive/replay documentation describes archiving selected events and replaying them to their source bus. It also notes archive-arrival and count reconciliation considerations. Recovery therefore needs a defined time window and a check that the intended events are available before replay.
This fits an engineering-owned AWS architecture where consumers already use the event bus. The pricing page separates several event and archive activities. Include targets, logs and any adapter that receives an arbitrary vendor's HTTP webhook; a bus tariff alone is not a complete ingress budget.
The non-fit is a small operations team expecting a turnkey webhook investigation console without additional integration work. A cloud-native route can be inexpensive in raw usage yet expensive to configure and maintain. Choose it when the estate and staff already justify that responsibility.
Size an outage and burst
Assume 100,000 incoming events daily, spread uniformly for this calculation. Average arrival is 1.16 events per second. A two-hour outage accumulates about 8,333 events. At a tenfold arrival rate during that same two-hour window, backlog becomes about 83,333. Real burst patterns should be measured; the uniform assumption is deliberately simplified.
Suppose the destination can process 20 events per second while arrivals remain at 11.57 per second. Spare recovery capacity is 8.43 per second. Clearing the 83,333-event backlog takes about 2.75 hours, before retries and per-account ordering restrictions. Dividing the backlog by the total 20-per-second capacity would understate recovery time because new traffic continues arriving.
At an assumed 5 KB per retained payload, the burst backlog is about 417 MB in decimal units. Metadata, indexes, logs and replicas add storage beyond that payload estimate. Choose retention longer than the expected outage plus discovery and recovery time; a queue that expires events before an operator arrives cannot deliver the promised recovery.
With two destinations and 5% additional delivery attempts, 3 million monthly inbound events can produce roughly 6.3 million destination attempts. Whether attempts, completed events or another unit is billed depends on the contract. Use that fan-out model rather than buying a plan against only the incoming count.
Make replay safe for revenue actions
Keep a stable source event identifier, account/tenant identity, event time, receipt time and schema version. The consumer should record the operation it applied. Replayed delivery of the same event should update its receipt history, not create a second “new lead” task.
Ordering needs explicit treatment. A delayed “contact active” event should not overwrite a later opt-out. Use source versions or sequence information where available, and reconcile current state where events are ambiguous. Arrival order is not always business order.
For a voice-to-CRM workflow, retain the call ID and distinguish transcript availability from call completion. For LinkedIn integrations, apply the same event identity and access rules. Reliability at ingress does not grant permission to perform every downstream action.
Use the ABM Account Scoring Template to define which incoming evidence may change account priority. Replay the accepted evidence under the intended policy version; do not let an old trigger silently activate a new campaign.
Purchase the recovery you need
Run a fixture with a signed event, an invalid signature, a duplicate, an outage, a rate-limited destination and a stale event. Inspect receipt, retry and consumer outcomes. Require a named incident owner and a way to identify the final unprocessed set.
Assume a managed platform costs $150 monthly and operation takes three hours at $60 per hour: total is $330 before destination and cloud bills. A self-built route with $40 usage and ten maintenance hours costs $640 under the same assumed labour rate. These are hypothetical comparisons, not vendor tariffs. Buy the route that supplies the needed retention and diagnosis with sustainable operating effort.
FAQ
Does accepting a webhook prove the CRM was updated?
No. Durable receipt, delivery and business processing are separate states. Retain the destination receipt or record ID so the operator can distinguish a queued event from an applied action.
Can we replay every event after an outage?
Only under a consumer policy that handles duplicates, stale updates and expired permissions. Select the affected window and verify current state where necessary. Blind replay can recreate completed work or undo a later valid change.
How much queue capacity is enough?
Model peak arrivals, maximum outage, continued traffic during recovery and consumer capacity. Include retention time and payload size. Average daily volume alone hides the burst that is most likely to expose a capacity problem.
Is an event bus always cheaper than a webhook platform?
Its raw usage can be low, but adapters, logging, support and operator work can dominate. Compare the same ingress, retention, replay and diagnosis requirement, including staff time. Choose the architecture your team can maintain through an incident.
