Generate events as fast as your agents and integrations can produce them. Slussen accepts every one the moment it arrives, stores it durably, and releases it downstream at a rate the destination survives — the legacy CRM, the homegrown ERP, the internal API that breaks above five requests a second. Nothing dropped, nothing lost.
Bursty webhook traffic was always like this. AI pipelines just made it impossible to ignore.
The same burst, sent twice — once straight at the destination, once through Slussen. These are the figures from that run, not a projection.
The sender saw all 1,000 accepted in 0.49 seconds. The CRM saw them over the following 199. That gap is the entire product.
A contact-centre shift ends. Three hundred agents finish their last calls within a few minutes, and every call emits several webhooks — metadata, recording, transcript, summary, disposition. A CRM sized for a steady Tuesday takes a thousand writes in ninety seconds and starts returning 500s.
Nobody did anything wrong. The webhook model simply has no backpressure: the sender posts, and if the receiver cannot keep up there is no mechanism for it to say so. What you get instead is 429s, timeouts, and — if the sender's retry logic is thin — silence.
A backend can often handle 50,000 requests an hour and still fall over when 10,000 arrive in one minute. Total capacity was never the constraint. Peak was.
One human action used to mean roughly one write. Post-call transcription, summarisation and disposition turn it into five or twenty. The integration that just coped last year is the one breaking now.
One configuration change on the sender. Nothing else in your stack moves.
Every event is written to disk before we answer, then acknowledged with 202. The sender is done in milliseconds and never retries. The body arrives at your destination byte for byte, so a signature over it still verifies.
Requests per second, concurrency, burst allowance, ordering per key. If you do not know what your destination can take, one command measures it and recommends a policy that sits under the cliff rather than on it.
5xx and timeouts retry with backoff. A destination that keeps failing is cut off and its backlog held rather than burned through. Anything that exhausts its retries waits in a dead-letter queue you can inspect and replay.
It sits next to your automation platform rather than competing with it.
We want a handful of teams with a real system that struggles with real bursts, who can point production traffic at it and tell us honestly where it falls short. Reduced pricing for six months in exchange for that traffic and that feedback.