Below is a destination that starts failing above a number you are not shown — because in production you are never shown it. Send a burst at it and watch the delivery rate walk down onto that number and sit there. Then look at the console a customer gets.
Slussen sits in front of a destination you do not control. Your code keeps sending the same request with the same body and the same headers — it just sends it to us, and we forward it at a rate the far end can take.
Before anything is switched over we run a capacity test against the endpoint and agree a rate that sits under its cliff rather than on it. You get an ingestion URL and an API key out of it. This part is a call, not a signup form — the number is the whole product and guessing it is how people get hurt.
Same body, same headers. The key can go in Authorization or X-API-Key.
curl -X POST https://hooks.slussen.dev/wh/<your-endpoint> \ -H "Authorization: Bearer $SLUSSEN_KEY" \ -H "content-type: application/json" \ -d '{"event":"call.completed","callId":"call_1","contactId":"c_42"}'
// Whatever you use today. No SDK, no client library. await fetch("https://hooks.slussen.dev/wh/<your-endpoint>", { method: "POST", headers: { "authorization": `Bearer ${process.env.SLUSSEN_KEY}`, "content-type": "application/json", }, body: JSON.stringify({ event: "call.completed", callId: "call_1" }), });
import os, httpx httpx.post( "https://hooks.slussen.dev/wh/<your-endpoint>", headers={"authorization": f"Bearer {os.environ['SLUSSEN_KEY']}"}, json={"event": "call.completed", "callId": "call_1"}, )
Do not put the key in the URL — query strings reach access logs, proxy logs
and Referer headers.
{ "receivedId": "evt_kzesq2cnmbyx", "status": "queued" }
202 means we have it durably. It does not mean the destination has processed it. That distinction is the design: we answer in milliseconds so your sender is never blocked by a slow receiver, and we take on responsibility for getting it there. Retry only on 5xx and 429 — a retried 202 is a duplicate you created yourself.
Optional, and most senders never need it. If your stream is mixed, say so on the request:
-H "x-sq-priority: 9" # 0–9, higher goes first. Absent is 0.
It decides which events are served next — it never reorders events that share an ordering key, because that would break the guarantee ordering exists for. Use two lanes, not nine.
acme-crm below starts refusing above some number of requests per second. In production that number is invisible: it is not in anyone's documentation, it changes over the day, and you discover it by exceeding it. Here it is drawn in rust so you can watch the delivery rate hunt for it — halving on every burst of 429s, creeping back up while things are quiet, and settling just underneath.
The configured ceiling is a hard cap, not a target. Slussen never goes above it even when the destination looks happy.
Nothing is dropped while it backs off. Everything above the line is still held, which is what the Waiting number is, and it drains when the destination recovers.
This is the customer console, reproduced as it is rather than as it might look one day. Click a destination to see its events; a dead-lettered event can be replayed from here. What is deliberately absent: payload bodies, any other tenant's data, and the delivery rate — changing that is the capacity conversation, not a slider.
The console runs on the ingestion process, not the operator one. A token that opens it cannot mint credentials, read a payload or see another tenant — not because these views hide those things, but because no such session can be created on that port at all.
Tell us what you send events to and roughly how many, and we will come back with what that destination looks like it can take. No call needed, and no obligation after it.
hello@slussen.dev Back to the overview