That is the email you get when a customer's CRM cannot absorb what you are sending it. You spend the afternoon proving the events left your side — and you are right, and it does not help. Nobody can tell you what rate that CRM actually survives, and the number is different next month.
Slussen sits between you and them. It measures what each destination can take, holds traffic under it, and backs off the moment latency climbs or 429s appear — before the ticket gets written.
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 at a rate chosen to sit under its cliff rather than on it. These are the figures from that run, not a projection.
events rejected with 5xx
events rejected, and none lost
Same 1,000 events, same destination. The dashed line is where it starts returning 500s.
Both panels share the same axes. The left spike reaches 1,000/s and is cut off at the top of the scale — drawn to size it would be fifty times the height of this card.
The sender saw all 1,000 accepted in 0.49 seconds. The CRM saw them over the following 199. That gap is what any rate limit buys you — and it only works because the rate was the right one. The next section is about what happens when it stops being.
A fixed limit cannot help with that. It is a number someone typed once, and it stays typed while the system behind it has a bad afternoon. So the interesting question is not whether traffic can be shaped — everything shapes traffic — but what happens when the destination gets worse and nobody is watching.
So we tested exactly that: two hours and forty-seven minutes against a destination deliberately made to misbehave — rate limiting, timeouts and a hard outage, seven times over.
delivery rate, down from a configured 5/s — without anyone touching it
back to the configured ceiling, and never above it
Nobody was at a keyboard for any of it. The rate you set is a ceiling, never a target — Slussen will go under it whenever the destination says it should, and will not go above it when things look good.
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. Setting a fixed delivery rate helps, right up until the number you picked is wrong, which is most afternoons.
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.
Ask a platform team what their CRM survives and you get a shrug or a guess. It is rarely documented, it differs per customer, and it is lower during month-end close than it was when anyone last measured it.
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.
One command steps traffic up against your endpoint, watches latency and error rate, and recommends a policy that sits under the cliff rather than on it — including the part everyone gets wrong, that a bucket's worst second is burst plus rate, not rate.
429s, timeouts and rising latency pull the rate down within seconds, and it climbs back slowly once the destination is steady. A system that stops answering is cut off and its backlog held rather than burned through. Your configured rate is a ceiling that is never exceeded, not a target.
It sits next to your automation platform rather than competing with it.
Building webhook delivery for your own customers — endpoints they register, signatures, a portal they manage? That is Svix, and it is a mature product. Want a durable HTTP queue you can put a fixed rate on? Hookdeck and QStash both do that, with more integrations and a larger surface than this.
What none of them will do is decide the rate. They give you a field; you supply the number, and it stays whatever you typed through every bad afternoon that follows. QStash's own documentation is explicit that its rate “does not adapt to destination responses.” That is the part Slussen is built to do, and it is the reason to put it in front of a system you cannot afford to knock over.
Slussen is built by Fredrik Romehed, through Romehed Consulting AB in Sweden. It exists because I spent enough time watching telephony webhooks flatten customers' CRMs to know the problem is real, that it is nobody's fault, and that the people who own the receiving end almost never know what rate it survives.
There is no team, no funding round and no other customers yet. You would be among the first, and you should price that in.
Production webhook traffic through software from someone you have not worked with. That is a real risk and I am not going to talk you out of feeling it. What I can do is make it reversible.
Getting in is pointing your sender at a new URL. Getting out is pointing it back. Nothing is rewritten, no library is embedded in your code, and the events we hold can be replayed to your destination before you go.
If that is not enough assurance — and for some companies it should not be — the honest answer is to wait until there are references to check. I would rather tell you that than find out during procurement.
We are looking for a handful of teams — most likely a B2B platform whose customers own the receiving end — who can point production traffic at it and tell us honestly where it falls short. We will measure your destinations with you and set the policies. Reduced pricing for six months in exchange for that traffic and that feedback.
hello@slussen.devEasiest reply: tell me what you send events to and roughly how many, and I will come back with what that destination looks like it can take. No call needed, and no obligation after it.