Stafett is a hosted delivery queue. Customers hand us a payload and an HTTPS destination, and we POST it there with retries. Delivery is at-least-once, so the same payload can arrive more than once. That means requests reach your server from our addresses, sent on behalf of an account that is not us. If those requests are unwanted, this page is the fastest way to end them.
Write to abuse [at] stafett.dev. Reports are read by a human, not a queue.
Every delivery we make carries these headers:
| Header | What it tells you |
|---|---|
| user-agent | Stafett/<version> (+https://stafett.dev/abuse): the traffic is ours to deal with |
| stafett-tenant | an opaque, stable token for the sending account. Same account, same token, across every job and retry. It identifies one customer to us without disclosing anything about them to you |
| webhook-id | the individual delivery, stable across its retries |
We never forward client-IP headers such as x-forwarded-for. A queue has no live client behind a delivery, so any address there would be invented. If you see one on a request claiming to be from us, the request is not from us.
A raw log excerpt with the headers intact is ideal. Send what you have. A report missing the token is still worth sending, it just takes us longer to trace.
Stafett is pre-alpha and small, so we do not yet publish a response-time commitment we would be able to keep under load. What we will say plainly: reports go to people, not a ticket queue, and stopping unwanted traffic takes priority over anything else we are doing.
You do not have to wait for us. Reject the request with a 4xx status (403 is the clearest) and we stop retrying that delivery at once and move it to the sender's dead-letter queue. The one exception is 429, which we read as "slow down" and retry with backoff; so are 5xx responses and timeouts, since those mean your side is temporarily unavailable rather than refusing.
Blocking by stafett-tenant stops one account while leaving other Stafett senders you may actually want unaffected.
Vulnerabilities in Stafett itself, preservation requests and law-enforcement enquiries, and data-protection questions (including about personal data that reached you through a delivery) all go to the same address for now: abuse [at] stafett.dev. For payload contents, our customer is the controller and we are their processor.