Svix
Quelloffener Webhook-Dienst — Ereignisse an Ihre Kunden senden, mit Wiederholungen, Signatur und Zustellhistorie
Svix ist ein quelloffener, selbst hostbarer Dienst, um Webhooks an die eigenen Kunden zu senden: Sie machen einen API-Aufruf, und Svix übernimmt Zustellung, Wiederholungen, Signatur des Payloads und die Historie je Endpunkt. Er steht unter MIT-Lizenz, ist in Rust geschrieben und hatte im August 2026 3.376 GitHub-Sterne. Für ein kleines Team wird aus "wir sollten Webhooks unterstützen" statt zwei Wochen Queue-Klempnerei ein Nachmittag — und das zählt mehr, als es klingt, denn ausgehende Webhooks sind die billigste Integrationsfläche, die Sie anbieten können, und Integrationen sind Distribution.
Was Svix ist
Svix (github.com/svix/svix-webhooks) ist der quelloffene Dispatcher hinter dem gehosteten Svix-Dienst. Ihre Anwendung macht einen einzigen API-Aufruf, um eine Nachricht an die Endpunkte einer Anwendung zu schicken; alles danach gehört Svix. Er startet aus der Docker-Compose-Datei des Repositories, die auch die beiden benötigten Abhängigkeiten hochfährt: PostgreSQL für die Speicherung und Redis — optional, Version 6.2.0 oder höher — für Task-Queue und Cache. Offizielle Client-Bibliotheken decken Go, Python, TypeScript, Java, Kotlin, Ruby, C#, Rust und PHP ab, dazu ein Terraform-Provider und eine CLI, die Sie direkt über npm ausführen können.
- Signierte Payloads. Standardmäßig symmetrische, vorab geteilte Schlüssel; laut README ist das symmetrische Signieren rund 50-mal schneller beim Signieren und 160-mal schneller beim Verifizieren als die asymmetrische ed25519-Variante, die ebenfalls unterstützt wird, wenn Sie lieber einen öffentlichen Schlüssel als ein Geheimnis herausgeben.
- Wiederholungen und eine Dead-Letter-Queue. Wiederholte interne Fehler landen als Task in einer DLQ, und das README weist an, deren Tiefe über eine eigene Metrik zu beobachten und sie nach Behebung der Ursache über einen Admin-Endpunkt erneut einzusteuern.
- SSRF-Schutz. Zustellungen an interne IP-Adressen sind standardmäßig blockiert, mit einer Subnetz-Freigabeliste für den Fall, dass der Empfänger wirklich intern ist.
- Betriebs-Webhooks. Der Server kann Ihnen Webhooks über sich selbst schicken, sodass Sie ohne Polling mitbekommen, dass ein Kunde einen Endpunkt deaktiviert oder geändert hat.
Das README ist ungewöhnlich offen über die eigenen Grenzen: Der gehostete Dienst hat Funktionen, Optimierungen und Verhaltensweisen, die noch nicht im Repository sind, und beide werden als weitgehend, aber nicht vollständig kompatibel beschrieben. Das lohnt sich zu lesen, bevor Sie Gleichstand mit der Open-Source-Variante annehmen.
Warum Webhooks eine Wachstumsfläche sind und nicht bloß Klempnerei
Webhooks werden unter Technik abgeheftet, und deshalb sind sie immer erst nächstes Quartal dran. Diese Ablage ist ein Fehler. Ein ausgehender Webhook ist die eine Integration, die Sie einmal bauen und nie wieder: Sobald es sie gibt, verdrahten Ihre Kunden Sie selbst mit Zapier, n8n, ihren internen Skripten und allem, was sie ohnehin betreiben — und jedes davon ist eine Partnerschaft, die Sie nicht verhandeln mussten. Unsere Seite dazu, ob sich Integrationen lohnen, führt das Argument vollständig aus; Webhooks sind die billigste Zeile in dieser Tabelle.
- Distribution ohne Partnerschaften Ein Endpunkt setzt Sie in jedes Automatisierungstool, für das Ihre Kunden bereits zahlen, ohne dass Sie für eines davon einen Konnektor ausliefern.
- Bindung, für die Sie nicht argumentieren mussten Ein Kunde, dessen internes System auf Ihre Ereignisse reagiert, hat Wechselkosten, die keine Feature-Tabelle erzeugt.
- Eine billigere Supportfläche "Warum ist nichts ausgelöst worden" beantwortet eine Zustellhistorie, die der Kunde selbst sehen kann — nicht Ihre eigenen Logs um 23 Uhr.
- Ein Grund, Dokumentation zu schreiben, die gelesen wird Event-Payloads gehören zu den wenigen Doku-Seiten, die man sich als Lesezeichen speichert, und sind damit wirklich gute Kandidaten für Rankings.
Was uns die Empfängerseite beigebracht hat
Wir versenden Webhooks nicht in großem Stil; wir konsumieren viele davon, für Zahlungen, für Chat und für jede Integration, die unsere Agenten anfassen. Daraus sind zwei Gewohnheiten entstanden, und beide sind Entscheidungen, die Sie auf der Senderseite ebenfalls treffen. Erstens: Ein Empfänger sollte mit 200 antworten und das Ereignis protokollieren, selbst wenn die Funktion, die es verarbeitet, abgeschaltet ist — denn alles andere lässt den Sender erneut zustellen, und ein Retry-Sturm ist schlimmer als ein Ereignis, das Sie ignorieren. Zweitens: Jeder Handler muss zweimal laufen können, denn dasselbe Ereignis wird zweimal ankommen. Das ist kein Fehler des Senders, sondern genau das, was Mindestens-einmal-Zustellung bedeutet.
Das Spiegelbild auf der Senderseite ist das, was wir anderswo falsch gemacht haben und nicht wiederholen würden: Ein Transporterfolg ist kein Aktionserfolg. Wir haben einmal einen Post als veröffentlicht verbucht, weil der HTTP-Aufruf 200 zurückgab, während der Body darunter sagte, er sei abgelehnt worden. Wenn Sie derjenige sind, der Webhooks sendet, lassen Sie den Zustellungseintrag abbilden, was der Body des Empfängers gesagt hat, und nicht, was in der Statuszeile stand — und geben Sie Kunden die Historie, damit sie Sie überprüfen können. Webhooks auszuliefern bringt für sich genommen niemanden; sie den Kunden anzukündigen, die danach gefragt haben, die Payloads zu dokumentieren und dort gelistet zu sein, wo Automatisierungsnutzer suchen, bringt etwas. Diese Hälfte ist dieselbe Wachstumsarbeit wie alles andere, und dafür gibt es AgentCeres — the AI Growth Officer, unter agentceres.com: Die Agenten entwerfen die Ankündigung, die Doku-Seite und die Ansprache, und ein Mensch gibt frei, was rausgeht.
FAQ
- Ist Svix kostenlos selbst hostbar?
- Ja. Das Repository steht unter MIT-Lizenz, und der Server läuft aus seiner eigenen Docker-Compose-Datei mit PostgreSQL, plus Redis, wenn Sie die Redis-gestützte Queue und den Cache wollen. Dieselbe Firma verkauft eine gehostete Variante, und das README sagt ausdrücklich, dass der quelloffene Dispatcher nicht jede Funktion und Optimierung des gehosteten Dienstes hat. Prüfen Sie das gegen Ihre Anforderungen, statt anzunehmen, es sei dasselbe Produkt.
- Brauche ich Redis wirklich?
- Nicht zwingend — das README führt PostgreSQL als erforderlich und Redis als optional, für Task-Queue und Cache. Wenn Sie es einsetzen, sind zwei Konfigurationshinweise aus dem README leicht zu übersehen und teuer zu lernen: Persistenz aktivieren, damit Tasks in der Queue einen Neustart überstehen, und die Eviction-Policy so setzen, dass Schlüssel ohne ausdrückliches Ablaufdatum nie verdrängt werden.
- Symmetrische oder asymmetrische Signaturen?
- Symmetrisch ist der Standard und die Empfehlung. Es ist auf beiden Seiten deutlich schneller und für Ihre Kunden viel einfacher zu verifizieren, zum Preis eines geteilten Geheimnisses je Endpunkt. Asymmetrisches ed25519-Signieren gibt es für den Fall, dass Sie lieber einen öffentlichen Schlüssel veröffentlichen als Geheimnisse zu verteilen — relevant vor allem, wenn Ihre Empfänger Dritte sind, zu denen Sie keine Supportbeziehung haben.
- Sollte ich Webhook-Versand nicht einfach selbst bauen?
- Sie können, und die erste Version ist klein. Was wächst, ist alles drumherum: exponentielles Backoff, Endpunkte nach wiederholten Fehlern deaktivieren, Replay-Schutz, Rotation von Secrets, eine Zustellhistorie, die Ihre Kunden lesen können, und eine Queue, die beim Neustart des Prozesses keine Ereignisse verliert. Das ist dieselbe Make-or-buy-Form, über die wir in soll ich meinen eigenen KI-Marketing-Agenten bauen geschrieben haben: Der Prototyp ist ein Wochenende, die Betriebshälfte nicht.
You built it. Now grow it.
AgentCeres is a managed AI marketing team — specialists draft the SEO, social, and outreach that fill your links, you approve what ships. 14-day free trial, from $39/month.