Workspace Webhooks: Isolierte Ereignisübermittlung für jeden Kunden auf Ihrer Plattform

Wenn Sie ein mandantenfähiges SaaS auf Firma.dev betreiben, sind Sie wahrscheinlich schon einmal an diese Grenze gestoßen. Ein Webhook auf Unternehmensebene empfängt Ereignisse für jede Signaturanforderung in allen Workspaces, und Ihr Backend muss diese an den richtigen Kunden verteilen. Das funktioniert gut, wenn Sie beide Seiten kontrollieren. Es bricht in dem Moment zusammen, in dem Ihre Kunden ihre eigenen Webhook-Endpunkte auf ihre eigenen Systeme richten möchten.

Workspace-Webhooks lösen dieses Problem. Jeder Workspace kann nun seine eigenen Webhook-Endpunkte mit unabhängigen Signaturgeheimnissen definieren, die völlig von den Webhooks auf Unternehmensebene getrennt sind. Dies ist das Puzzleteil, das das mandantenfähige Modell von Firma.dev erst durchgehend funktionsfähig macht.

Das mandantenfähige Problem, das hierdurch gelöst wird

Kunden-Workspaces haben Ihnen schon immer partitionierte Bereiche für jeden Kunden auf Ihrer Plattform geboten. Jeder Workspace hat seine eigenen Vorlagen, seine eigene Umschlagnutzung und seinen eigenen API-Schlüssel. Saubere Trennung. Aber bis jetzt war die Webhook-Zustellung die Ausnahme. Jedes Ereignis wurde über einen einzigen Webhook auf Unternehmensebene geleitet, was bedeutete, dass Ihre Plattform immer der Vermittler für Benachrichtigungen war.

Für einige Architekturen ist das in Ordnung. Für andere ist es ein K.-o.-Kriterium. Nehmen wir eine Plattform, auf der Kunden ihre eigenen CRMs, ERPs oder Ticketsysteme anbinden können. Jeder Kunde möchte, dass Signaturereignisse direkt in seinen eigenen Stack übertragen werden. Oder denken Sie an einen Reseller, der seinen Endkunden eine echte Isolation über deren Integrationen hinweg bietet. Oder an ein Dev-Team, das möchte, dass Staging-Workspaces Ereignisse an einen Test-Endpunkt senden, während die Produktion an den echten gesendet wird.

In all diesen Fällen muss der Webhook auf Workspace-Ebene angesiedelt sein, da sonst das gesamte Modell lückenhaft wird.

Was pro Workspace verfügbar ist

Jeder Workspace erhält nun das vollständige Webhook-Toolkit, das auf ihn selbst beschränkt ist:

• Vollständiges CRUD für Webhook-Endpunkte

• Ein eigenes Signaturgeheimnis mit einer 7-tägigen Übergangsfrist für die Rotation, wenn Sie es neu generieren

• Testzustellung, damit Sie die Einrichtung überprüfen können, ohne echte Ereignisse auszulösen

• Ein Ereignisprotokoll pro Workspace

• Eine Option "Unternehmens-Webhooks ignorieren", wenn Sie möchten, dass Workspace-Webhooks die Zustellung auf Unternehmensebene vollständig ersetzen, anstatt parallel dazu zu laufen

Diese letzte Option ist wichtiger, als es den Anschein hat. Einige Teams möchten, dass sowohl Unternehmens- als auch Workspace-Webhooks ausgelöst werden, da ihre Plattform weiterhin eine globale Sicht auf die Ereignisse benötigt, während die Kunden ihre eigenen Feeds erhalten. Andere Teams wünschen sich eine saubere Isolation, bei der Workspace-Webhooks die einzige Quelle der Wahrheit sind. Sie können dies pro Workspace frei wählen.

Sicherheit: SSRF-Schutz für alle Webhook-URLs

Ein wichtiger Punkt für Entwickler, die dies evaluieren: Jede Webhook-URL-Validierung beinhaltet jetzt einen SSRF-Schutz, der private IP-Bereiche, Cloud-Metadaten-Endpunkte und DNS-Rebinding-Versuche blockiert. Wenn Sie Ihren Kunden erlauben, ihre eigenen Webhook-Endpunkte in den von ihnen kontrollierten Workspaces zu konfigurieren, ist dies unverzichtbar. Ein Kunde könnte versehentlich (oder absichtlich) einen Webhook auf 169.254.169.254 oder eine interne IP richten. Ohne SSRF-Schutz würden Sie Anfragen von der Infrastruktur von Firma in Bereiche weiterleiten, die niemand erreichen sollte.

Dies wird auf der Plattformebene gehandhabt, sodass Sie keine eigenen Schutzmechanismen entwickeln müssen.

API-Oberfläche

Einige Ergänzungen auf der API-Seite:

• Parameter workspace_id bei POST /webhooks und GET /webhooks, damit Sie Webhook-Operationen auf einen bestimmten Workspace beschränken können

• Neue Endpunkte zur Verwaltung von Workspace-Webhook-Geheimnissen: POST /workspaces/{id}/webhooks/rotate-secret und GET /workspaces/{id}/webhooks/secret-status

• Fünf neue Felder in der Workspace-GET-Antwort, die den Status der Webhook-Konfiguration abdecken

Vollständige Details finden Sie im API-Changelog für v1.15.0.

Wann man Workspace-Webhooks im Vergleich zu Unternehmens-Webhooks verwendet

Ein schnelles mentales Modell:

Unternehmens-Webhooks sind für Ihre Plattform gedacht. Alles, worüber Ihre Kernanwendung über alle Kunden hinweg informiert sein muss, sollte über die Zustellung auf Unternehmensebene laufen. Abrechnungsereignisse, Compliance-Protokollierung, Analysen, interne Workflows.

Workspace-Webhooks sind für Ihre Kunden gedacht. Alles, worauf die Systeme eines bestimmten Kunden reagieren müssen, sollte über die Zustellung auf Workspace-Ebene laufen. CRM-Updates, kundenspezifische Benachrichtigungen, Drittanbieter-Integrationen, die sie selbst eingerichtet haben.

Beide können im selben Workspace nebeneinander existieren, oder Sie können einen Workspace vollständig von Unternehmens-Webhooks ausschließen. Für die meisten mandantenfähigen Plattformen ist das richtige Muster die Verwendung von Unternehmens-Webhooks für plattformkritische Ereignisse in Kombination mit Workspace-Webhooks, die Ihre Kunden über Ihre Benutzeroberfläche konfigurieren.

Erste Schritte

Wenn Sie bereits Kunden-Workspaces nutzen, können Sie noch heute damit beginnen, Workspace-Webhooks hinzuzufügen. Bestehende Webhook-Integrationen auf Unternehmensebene funktionieren weiterhin genau wie zuvor. Dies ist eine rein ergänzende Funktion.

Starten Sie kostenlos mit Firma.dev, keine Kreditkarte erforderlich. Keine Verträge, keine Mindestlaufzeiten und das vollständige mandantenfähige Toolkit einschließlich Kunden-Workspaces und Workspace-Webhooks vom ersten Tag an.