Zum Inhalt springen
Entwickler

Community-Webhooks

Mateflow sendet einen HTTP-POST an Ihre URL, wenn in einer Community etwas passiert. Diese Seite beschreibt, was Ihr Empfänger erhält, wie Sie es prüfen, was bei einem Fehler geschieht und welche Felder jedes Ereignis hat.

Schnellstart

Jede Zustellung ist ein POST mit JSON-Body. Wenn mehrere Webhooks ein Ereignis abonniert haben, erhält jeder seine eigene Kopie.

  1. Öffnen Sie in der Admin-Oberfläche Ihrer Community Einstellungen → Integrationen → Webhooks und legen Sie einen Webhook an: URL eingeben, Ereignisse auswählen, ein Secret erzeugen und den Webhook einschalten.
  2. Verarbeiten Sie jede Anfrage in dieser Reihenfolge:
    1. Lesen Sie den rohen Request-Body und prüfen Sie die Signatur.
    2. Ist test gleich true, antworten Sie mit 200 und beenden Sie die Verarbeitung.
    3. Entdoppeln Sie über event_id.
    4. Legen Sie die Arbeit in Ihre eigene Warteschlange und antworten Sie innerhalb von 10 Sekunden mit 2xx.
  3. Klicken Sie auf Webhook testen, um eine Testanfrage zu senden, und öffnen Sie dann Zustellprotokolle, um Anfrage und Antwort zu sehen.

Tarife und Einrichtung

Webhooks sind eine Tariffunktion, und nur Community-Admins können sie verwalten.

TarifWebhooks pro Community
FreeNicht verfügbar
StarterNicht verfügbar
Growth5
Business20
EnterpriseUnbegrenzt
  • Nach einem Downgrade auf einen Tarif ohne Webhooks bleiben Ihre Webhook-Einstellungen erhalten, aber es wird nichts zugestellt oder protokolliert. Mit einem Upgrade läuft die Zustellung wieder an.
  • Webhooks werden in der Admin-Oberfläche angelegt und verwaltet. Die Community Open API hat dafür keine Endpunkte.

Konfiguration

EinstellungAnforderung
URLDas Admin-Formular akzeptiert nur https://-URLs mit bis zu 1.024 Zeichen.
Nicht erreichbare AdressenAnfragen an Adressen, die in Loopback-, private oder Link-Local-Bereiche aufgelöst werden, werden beim Verbindungsaufbau blockiert und als Netzwerkfehler behandelt. Verwenden Sie für die lokale Entwicklung einen öffentlichen Tunnel.
NameBis zu 100 Zeichen.
EreignisseMindestens eines aus dem Katalog weiter unten. Ein Webhook, der früher mit leerer Ereignisliste gespeichert wurde, erhält alle Ereignisse.
SecretOptional, bis zu 128 Zeichen. Einmal gespeichert, kann es ersetzt, aber nicht mehr ausgelesen werden. Ohne Secret werden Anfragen nicht signiert; wir empfehlen deshalb dringend, eines zu setzen. Das Secret selbst erscheint nie in einer Anfrage.

Zustellformat

Jede Zustellung ist ein POST mit einem Timeout von 10 Sekunden pro Anfrage.

Header

HeaderWertHinweise
Content-Typeapplication/jsonImmer JSON.
User-AgentMateflow-Webhook/1.0Kennzeichnet Mateflow als Absender.
X-Mateflow-TimestampUnix-SekundenWann diese Anfrage gesendet wurde. Teil der Signatur.
X-Mateflow-Signaturesha256= gefolgt von einem Hex-DigestNur vorhanden, wenn der Webhook ein Secret hat.

Eigene Webhooks haben keinen Header X-Mateflow-Delivery-Id. Lesen Sie delivery_id aus dem Body.

Body

FeldTypBeschreibung
eventstringDer Ereigniscode.
event_idstringDie eindeutige Kennung des Ereignisses. Entdoppeln Sie darüber. Sie bleibt bei automatischen Wiederholungen und manuellem erneutem Senden gleich und ebenso über alle Webhooks hinweg, die das Ereignis abonniert haben. Behandeln Sie sie als undurchsichtigen String.
occurred_atRFC 3339Wann das Ereignis eintrat, sekundengenau. Sie bleibt bei Wiederholungen gleich.
delivery_idstring (dezimal)Kennzeichnet diese Zustellung. Sie ändert sich bei jeder automatischen Wiederholung; beim manuellen erneuten Senden bleibt der ursprüngliche Wert erhalten.
timestampRFC 3339Wann der Body erzeugt wurde. Beim manuellen erneuten Senden bleibt der ursprüngliche Wert erhalten; beurteilen Sie die Aktualität daher anhand des Headers.
webhook_idhashidDer Webhook, der diese Zustellung erhält.
site_idhashidDie Community.
dataobjectDie Daten des Ereignisses, beschrieben im Ereigniskatalog.

In seltenen Fällen, wenn die ID-Erzeugung fehlschlägt, können event_id und occurred_at fehlen. Akzeptieren Sie das und greifen Sie zur Erkennung von Duplikaten auf event plus die fachliche ID in data zurück.

JSON
{
  "event": "payment.received",
  "event_id": "86116692152877061",
  "occurred_at": "2026-11-03T00:00:00Z",
  "delivery_id": "86116692152877060",
  "timestamp": "2026-11-03T00:00:01Z",
  "webhook_id": "qP3aXm71Bd",
  "site_id": "Z5Kf08mFv8r",
  "data": {
    "member_id": "b7Lq2WxR9e",
    "username": "sample_member",
    "email": "sample.member@example.com",
    "invoice_id": "in_1Abc",
    "subscription_id": "sub_1Abc",
    "amount_cents": 2900,
    "currency": "usd",
    "period_start": "2026-11-03T00:00:00Z",
    "period_end": "2026-12-03T00:00:00Z"
  }
}

Signaturen prüfen

Hat ein Webhook ein Secret, wird jede Anfrage mit HMAC-SHA256 über den Timestamp-Header und den rohen Body signiert.

Signatur
X-Mateflow-Signature = "sha256=" + hex(
  HMAC-SHA256(secret, X-Mateflow-Timestamp + "." + raw_request_body)
)
  • Verwenden Sie die rohen Bytes. Im HTML-Kontext besondere Zeichen können im Body maskiert sein. Wenn Sie das JSON parsen und erneut serialisieren, entstehen daher andere Bytes, und die Signatur stimmt nicht überein.
  • Nehmen Sie den Timestamp aus dem Header, nicht aus dem Body. Beim manuellen erneuten Senden werden nur der Timestamp im Header und die Signatur aktualisiert.
  • Eine Timestamp-Prüfung stört die Wiederholungen nicht. Jede automatische Wiederholung und jedes manuelle erneute Senden wird neu signiert, ein Fenster von 5 Minuten genügt also.
Node.js
const crypto = require('crypto');

// rawBody must be the untouched bytes, e.g. from express.raw({ type: 'application/json' }).
function verifyMateflowSignature(rawBody, headers, secret, toleranceSeconds = 300) {
  const timestamp = headers['x-mateflow-timestamp'];
  const received = headers['x-mateflow-signature'] || '';
  if (!timestamp || Math.abs(Date.now() / 1000 - Number(timestamp)) > toleranceSeconds) {
    return false;
  }
  const expected = 'sha256=' + crypto
    .createHmac('sha256', secret)
    .update(`${timestamp}.`)
    .update(rawBody)
    .digest('hex');
  const a = Buffer.from(received);
  const b = Buffer.from(expected);
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
Python
import hashlib
import hmac
import time


def verify_mateflow_signature(raw_body: bytes, headers, secret: str, tolerance_seconds: int = 300) -> bool:
    timestamp = headers.get("X-Mateflow-Timestamp", "")
    received = headers.get("X-Mateflow-Signature", "")
    if not timestamp.isdigit() or abs(time.time() - int(timestamp)) > tolerance_seconds:
        return False
    signed = timestamp.encode() + b"." + raw_body
    expected = "sha256=" + hmac.new(secret.encode(), signed, hashlib.sha256).hexdigest()
    return hmac.compare_digest(received.encode(), expected.encode())

Testvektor

Prüfen Sie mit diesen Werten Ihre Signaturberechnung. Der Timestamp ist abgelaufen; lockern Sie beim Testen daher Ihr Zeitfenster.

Testvektor
secret                 my_signing_secret
X-Mateflow-Timestamp   1793664000
raw body (UTF-8)       {"event":"member.joined","data":{"username":"张三"}}
X-Mateflow-Signature   sha256=3f4c83828ce0086150c9bd48c1654899357b7c05265c1d1b6c172225ee04b4b4

Secret wechseln

Ein neues Secret gilt, sobald es gespeichert ist, und auch Wiederholungen in der Warteschlange werden damit signiert. Es gibt keine Phase, in der Mateflow mit beiden signiert; lassen Sie Ihren Empfänger daher während des Wechsels sowohl das alte als auch das neue Secret akzeptieren.

Antworten und Wiederholungen

Wie eine Zustellung bewertet wird, hängt allein von Ihrem Statuscode ab. Der Antwort-Body wird nicht ausgewertet.

Ihr EmpfängerErgebnisWiederholt
2xxErfolgNein
5xx, 408, 429FehlschlagJa
Timeout, Verbindungsfehler, blockierte AdresseFehlschlag, protokolliert mit Status 0Ja
Jedes andere 4xxFehlschlagNein
  • Wiederholungsplan: Nach einem Fehlschlag wartet Mateflow 1 Minute, 10 Minuten, 1 Stunde, dann 6 Stunden. Zusammen mit dem ersten Versuch sind das höchstens 5 Versuche über etwa 7 Stunden.
  • Wenn die Zustellung aufgibt: Sind die Wiederholungen aufgebraucht oder wurde ein Status zurückgegeben, der nicht wiederholt wird, erhalten der Community-Inhaber und die Admins eine E-Mail, höchstens eine pro Webhook alle 24 Stunden.
  • Zwischendurch gestoppt: Wird der Webhook gelöscht oder ausgeschaltet oder enthält der Tarif keine Webhooks mehr, werden spätere Versuche weder gesendet noch protokolliert.
  • Weiterleitungen: Zustellungen folgen Weiterleitungen, aber ein 301, 302 oder 303 macht aus dem POST ein GET ohne Body. Tragen Sie die endgültige URL ein und verlassen Sie sich nicht auf eine Weiterleitung von http auf https.

Manuelles erneutes Senden

Erneut senden in den Zustellprotokollen sendet eine Zustellung noch einmal an die aktuelle URL des Webhooks.

  • Der Body ist identisch, einschließlich event_id, delivery_id und timestamp. Der Timestamp-Header und die Signatur sind neu.
  • Es wird ein einziger Versuch unternommen und bei einem Fehlschlag nicht wiederholt. Das Ergebnis erscheint als neue Zeile im Protokoll.
  • Nur Zustellungen eigener Webhooks können erneut gesendet werden, und der Webhook muss noch existieren und eingeschaltet sein.

Zustellprotokolle

Protokolle werden 30 Tage aufbewahrt. Von jedem Antwort-Body werden nur die ersten 4 KB gespeichert.

Zuverlässigkeit

Was Ihr Empfänger annehmen darf und was nicht.

  • Mindestens einmal. Dasselbe Ereignis kann mehrfach eintreffen. Entdoppeln Sie über event_id.
  • Ergänzen Sie bei allem, was Geld betrifft, eine zweite Prüfung. Mateflow entdoppelt dieselbe Zahlung sowie denselben Start oder dasselbe Ende desselben Abonnements bereits selbst. Ist diese Prüfung jedoch nicht verfügbar, wird gesendet statt verworfen, und die beiden Ereignisse haben dann unterschiedliche event_id-Werte. Prüfen Sie zusätzlich invoice_id, subscription_id oder order_id.
  • Keine Reihenfolgegarantie. Zustellungen laufen parallel und werden wiederholt, daher können access_group_removed und access_group_added eines Mitglieds vertauscht eintreffen. Um zu klären, was zuerst war, verwenden Sie occurred_at, das sekundengenau ist.
  • Seltener Verlust ist möglich. Ereignisse werden eingereiht, nachdem die Daten festgeschrieben wurden; endet ein Prozess zwischen diesen beiden Schritten, geht das Ereignis verloren.
  • Gleichen Sie ab, wenn Sie Zustände synchronisieren. Behandeln Sie ein Ereignis als Signal, dass sich etwas geändert hat, lesen Sie den aktuellen Zustand aus der Open API (zum Beispiel /member/get mit dem Scope members.read) und führen Sie regelmäßig einen vollständigen Abgleich durch. Die Open API liefert keine E-Mail-Adressen; entnehmen Sie diese den Ereignissen.

Ereigniskatalog

Sie können 17 Ereignisse abonnieren.

Regeln für alle Felder

  • Mateflow-IDs sind hashid-Strings, dieselben Werte, die die API verwendet. Ein Wert von 0 wird nicht kodiert und erscheint als die Zahl 0.
  • member_id und user_id bezeichnen dieselbe Person. member.joined, Beitragsereignisse und Kommentarereignisse verwenden user_id; alle anderen verwenden member_id.
  • Stripe-IDs werden unverändert durchgereicht: invoice_id, subscription_id, charge_id und payment_intent_id.
  • Zeiten sind RFC 3339 in UTC.
  • Beträge sind ganze Zahlen in der kleinsten Einheit der Währung (Cent bei USD), und currency ist ein Währungscode in Kleinbuchstaben.
  • Ein optionales Feld, das nicht zutrifft, wird weggelassen. Es ist weder null noch ein leerer String.
  • Felder und Enum-Werte werden nur hinzugefügt, nie geändert. Ihr Empfänger sollte neue tolerieren.

Alle Ereignisse

EreignisBedeutungBenutzername und E-Mail
member.joinedEin neues Mitglied ist beigetretenJa
member.leftEin Mitglied hat die Community verlassenJa
member.role_changedDie Rolle eines Mitglieds hat sich geändertNein
member.suspendedEin Mitglied wurde gesperrt oder verbanntNein
member.reinstatedEine Sperre oder Verbannung wurde aufgehobenNein
member.access_group_addedEin Mitglied gehört nun einer Zugriffsgruppe anJa
member.access_group_removedEin Mitglied gehört einer Zugriffsgruppe nicht mehr anJa
post.createdEin Beitrag wurde veröffentlichtNein
post.deletedEin Beitrag wurde gelöschtNein
comment.createdEin Kommentar wurde veröffentlichtNein
comment.deletedEin Kommentar wurde gelöschtNein
payment.receivedEine Zahlung ist eingegangen, für eine Abonnementrechnung oder einen EinmalkaufJa
subscription.renewedEin Abonnement wurde erfolgreich verlängertJa
payment.failedDie Zahlung einer Rechnung ist fehlgeschlagenJa
subscription.createdEin Abonnement wurde in Stripe angelegtJa
subscription.canceledEin Abonnement ist beendetJa
refund.issuedEine Rückerstattung wurde veranlasstJa

Mitglieder

member.joined

Ein neues Mitglied ist beigetreten.

FeldTypImmer vorhandenBeschreibung
user_idhashidJaMitglieds-ID.
usernamestringJaBenutzername.
emailstringJaE-Mail-Adresse.

Gesendet, wenn

  • Eine Registrierung gelingt, einschließlich Social Login, einer ersten SSO-Anmeldung und der Registrierung über eine Einladung.
  • Eine kostenpflichtige Registrierung wird abgeschlossen.
  • Eine Beitrittsanfrage wird genehmigt.
  • Jemand registriert sich erneut mit derselben E-Mail-Adresse und das Konto wird wiederhergestellt. Das Ereignis wird erneut gesendet.

Nicht gesendet, wenn

  • Mitglieder werden aus einer CSV-Datei importiert.
  • Ein Mitglied wartet noch auf Freigabe in einer Community, die Beitrittsanfragen prüft.

member.left

Ein Mitglied hat die Community verlassen.

FeldTypImmer vorhandenBeschreibung
member_idhashidJaDerselbe Wert wie user_id des Mitglieds in member.joined.
usernamestringJaBenutzername vor dem Austritt, auch wenn der Austritt die persönlichen Daten löscht.
emailstringJaE-Mail-Adresse vor dem Austritt, unter denselben Bedingungen.
sourcestringJaWie das Mitglied ausgetreten ist. Siehe die Tabelle unten.
removed_byhashidNeinDer Admin, der gehandelt hat. Nur bei removed und anonymized.
reasonstringNeinNur bei removed, wenn der Admin einen Grund angegeben hat.
sourceBedeutungErneute Registrierung mit derselben E-Mail-Adresse
removedEin Admin hat das Mitglied entferntStellt dieselbe ID wieder her und sendet member.joined erneut
account_deletedDas Mitglied hat sein eigenes Konto gelöscht, sofort oder nach Ablauf der 30-tägigen BedenkzeitSofortige Löschung: wie oben. Nach der Bedenkzeit: eine neue ID
anonymizedEin Admin hat das Mitglied gemäß GDPR anonymisiertEine neue ID
inactivityBereinigung inaktiver Konten, die in nächtlichen Stapeln läuftEine neue ID

Nicht gesendet, wenn

  • Ein Konto wird deaktiviert.
  • Ein Mitglied befindet sich in der Bedenkzeit, nachdem es die Löschung seines Kontos beantragt hat. Das Ereignis wird gesendet, wenn die Frist endet, und gar nicht, wenn das Mitglied abbricht.
  • Ein Mitglied wird verbannt oder gesperrt, was member.suspended sendet.
  • Jemand ist nie beigetreten, etwa bei einer abgelehnten oder noch offenen Beitrittsanfrage.
  • Ein Abonnement endet.
  • Die Community wird gelöscht.
  • Ein Mitglied verlässt einen einzelnen Space.
  • Zugriffsgruppen, die durch den Austritt geleert werden, werden nicht einzeln als member.access_group_removed gesendet. Verstehen Sie member.left so, dass das Mitglied keiner Zugriffsgruppe mehr angehört.

member.role_changed

Die Rolle eines Mitglieds hat sich geändert.

FeldTypImmer vorhandenBeschreibung
member_idhashidJaMitglieds-ID.
previous_rolestringJamember, moderator oder admin, immer in Kleinbuchstaben.
rolestringJaDieselben Werte.
changed_byhashidJaWer die Änderung vorgenommen hat.

Nicht gesendet, wenn

  • Die Rolle hat sich tatsächlich nicht geändert.
  • Nur Billing Admin oder eine benutzerdefinierte Rolle hat sich geändert.

member.suspended

Ein Mitglied wurde gesperrt oder verbannt. Beides verwendet dieses Ereignis und wird über ban_type unterschieden.

FeldTypImmer vorhandenBeschreibung
member_idhashidJaMitglieds-ID.
suspended_byhashidJaDer Admin, der gehandelt hat.
reasonstringJaDie interne Notiz des Admins. Kann ein leerer String sein. Zeigen Sie sie dem Mitglied nicht an.
ban_typestringJasuspend oder ban.
duration_daysnumberNeinNur bei suspend.
suspended_untilRFC 3339NeinNur bei suspend.
viastringNeinmoderation, wenn dies bei der Bearbeitung einer Meldung geschah. Wird weggelassen, wenn es über die Mitgliederverwaltung geschah.

Gesendet, wenn

  • Ein Mitglied wird über die Mitgliederverwaltung oder bei der Bearbeitung einer Meldung gesperrt oder verbannt, einzeln oder gesammelt.

Nicht gesendet, wenn

  • Ein Mitglied wird nur verwarnt.

member.reinstated

Eine Sperre oder Verbannung wurde aufgehoben.

FeldTypImmer vorhandenBeschreibung
member_idhashidJaMitglieds-ID.
reinstated_byhashidNeinDer Admin, der gehandelt hat. Wird weggelassen, wenn via gleich expired ist.
fromstringJaWas aufgehoben wurde: suspend oder ban.
viastringNeinmoderation (in der Moderation aufgehoben), appeal (Einspruch stattgegeben) oder expired (die Sperre ist abgelaufen). Wird weggelassen, wenn über die Mitgliederverwaltung aufgehoben.

Nicht gesendet, wenn

  • Eine Sperre ist abgelaufen, das Mitglied hat aber eine weitere aktive Verbannung und bleibt daher eingeschränkt.
  • Läuft eine Sperre ab, wird das Ereignis in der Regel innerhalb weniger Minuten gesendet, da Abläufe alle 5 Minuten geprüft werden. occurred_at ist der Zeitpunkt, zu dem der Ablauf festgestellt wurde.

member.access_group_added, member.access_group_removed

Ein Mitglied gehört einer Zugriffsgruppe nun an oder nicht mehr an. Jedes Ereignis betrifft ein Mitglied und eine Zugriffsgruppe; wird ein Abonnement von Silver auf Gold umgestellt, werden daher ein removed und ein added gesendet.

FeldTypImmer vorhandenBeschreibung
member_idhashidJaMitglieds-ID.
usernamestringJaBenutzername.
emailstringJaE-Mail-Adresse.
access_group_idhashidJaDerselbe Wert wie access_groups[].id in der Open API.
access_group_namestringJaDer Name der Gruppe zu diesem Zeitpunkt. Bei einer gelöschten Gruppe der Name vor dem Löschen.
sourcestringJaSiehe die Tabelle unten.
changed_byhashidNeinNur bei manual und invitation.
sourceEreignisseBedeutungchanged_by
manualadded, removedEin Admin hat sie in der Konsole vergeben oder entferntDer Admin
subscriptionadded, removedEin Abonnement wurde gestartet, beendet oder die Stufe gewechseltKeiner
invitationaddedDas Mitglied hat eine Einladung angenommenDie einladende Person
defaultaddedDas Mitglied ist in die Standardgruppe gekommenKeiner
group_deletedremovedDie Zugriffsgruppe wurde gelöschtKeiner

Nicht gesendet, wenn

  • Die Gruppen des Mitglieds haben sich tatsächlich nicht geändert.
  • Ein Mitglied kommt bei der Registrierung automatisch in die Standardgruppe.
  • Die Änderung betrifft ein Mitglied, das noch auf Freigabe wartet.
  • Gruppen werden geleert, weil das Konto gelöscht wurde.
  • Das Löschen einer Zugriffsgruppe oder das Festlegen einer Standardgruppe ist eine Sammeländerung. Die Ereignisse werden Mitglied für Mitglied gesendet und treffen Sekunden bis Minuten nach der Aktion ein, während occurred_at der Zeitpunkt der Aktion bleibt. Ihre event_id hat ein anderes Format, weshalb sie als undurchsichtig behandelt werden muss.

Inhalte

In allen vier Ereignissen ist post_id die ID des Inhalts selbst und user_id der Autor, nicht diejenige Person, die gehandelt hat. space_id wird weggelassen, wenn der Inhalt in keinem Space liegt. Inhalte in privaten Spaces werden ebenfalls gesendet; filtern Sie daher nach space_id, falls Ihr Empfänger das braucht.

post.created

Ein Beitrag oder Blogbeitrag wurde veröffentlicht.

FeldTypImmer vorhandenBeschreibung
post_idhashidJaBeitrags-ID.
user_idhashidJaDer Autor.
space_idhashidNeinDer Space, in dem er liegt.
titlestringJaTitel. Kann ein leerer String sein.
bodystringJaMarkdown-Quelltext, bis zu 500 Zeichen. Er kann an einem Wort oder Satzzeichen vorzeitig abgeschnitten sein, ohne Auslassungspunkte. Bei einem Blogbeitrag ist dies der Auszug.

Gesendet, wenn

  • Ein Beitrag oder Blogbeitrag wird öffentlich: Er wird direkt veröffentlicht, aus der Prüfwarteschlange freigegeben oder erreicht seinen geplanten Zeitpunkt.

Nicht gesendet, wenn

  • Ein Kommentar wird veröffentlicht, was comment.created sendet.
  • Ein Blogbeitrag sendet dies nur bei der ersten Veröffentlichung, aber ein Beitrag, dessen Veröffentlichung zurückgenommen und der dann erneut geplant wurde, kann es erneut senden. Machen Sie Ihre Verarbeitung über post_id idempotent.

post.deleted

Ein Beitrag oder Blogbeitrag wurde gelöscht.

FeldTypImmer vorhandenBeschreibung
post_idhashidJaBeitrags-ID.
user_idhashidJaDer Autor.
space_idhashidNeinDer Space, in dem er liegt.

Gesendet, wenn

  • Der Autor löscht ihn, ein Admin löscht ihn (einzeln oder gesammelt), er wird bei der Bearbeitung einer Meldung entfernt, oder eine Verbannung löscht die Inhalte des Mitglieds. Das Löschen der Inhalte eines Mitglieds kann einen Schwung von Ereignissen erzeugen.

Nicht gesendet, wenn

  • Ein Blogbeitrag wird zurück in den Entwurfsstatus gesetzt, was keine Löschung ist.
  • Auch das Löschen eines geplanten Beitrags, der nie veröffentlicht wurde, sendet dies; der Empfang bedeutet also nicht, dass Sie zuvor post.created erhalten haben.
  • Für das Wiederherstellen von Inhalten gibt es kein eigenes Ereignis.

comment.created

Ein Kommentar wurde veröffentlicht.

FeldTypImmer vorhandenBeschreibung
post_idhashidJaDie eigene ID des Kommentars.
parent_idhashidJaDer Beitrag oder Kommentar, auf den geantwortet wird.
user_idhashidJaDer Autor.
space_idhashidNeinDer Space, in dem er liegt.
bodystringJaDieselben Regeln wie für body in post.created.

comment.deleted

Ein Kommentar wurde gelöscht. Er wird unter denselben Bedingungen gesendet wie post.deleted.

FeldTypImmer vorhandenBeschreibung
post_idhashidJaDie eigene ID des Kommentars.
parent_idhashidJaDer Beitrag oder Kommentar, auf den geantwortet wird.
user_idhashidJaDer Autor.
space_idhashidNeinDer Space, in dem er liegt.

Zahlungen und Abonnements

Diese Ereignisse betreffen Stripe-Abonnements, Einmalkäufe von Spaces und Rückerstattungen. Sie enthalten username und email, es sei denn, das Mitglied existiert nicht mehr.

In-App-Käufe und Abonnements, die als Geschenk oder über einen Einlösecode vergeben wurden, senden weder payment.* noch subscription.*. Ist der Tarif an eine Zugriffsgruppe gebunden, senden sie member.access_group_added mit source gleich subscription und, wenn der Zugriff endet, member.access_group_removed; damit können Sie Änderungen der Berechtigung nachverfolgen.

Bei einer kostenpflichtigen Registrierung kommt die Zahlung vor dem Konto. Die Ereignisse der ersten Zahlung werden daher gesendet, sobald das Konto existiert: member.joined, subscription.created und payment.received, wenn die erste Rechnung bezahlt ist. Sie können in beliebiger Reihenfolge eintreffen.

payment.received

Eine Zahlung ist eingegangen. Es gibt zwei Payload-Formen, die Sie daran unterscheiden, ob invoice_id vorhanden ist.

FeldTypAbonnementrechnungEinmalkaufBeschreibung
member_idhashidJaJaMitglieds-ID.
usernamestringNormalerweiseNormalerweiseWird weggelassen, wenn das Mitglied nicht mehr existiert.
emailstringNormalerweiseNormalerweiseWird weggelassen, wenn das Mitglied nicht mehr existiert.
amount_centsnumberJaJaDer gezahlte Betrag. 0 bei der Rechnung über null, wenn eine Testphase beginnt.
currencystringJaJaWährung.
invoice_idstringJaNeinStripe-Rechnungs-ID.
subscription_idstringJaNeinStripe-Abonnement-ID.
period_startRFC 3339JaNeinBeginn des Zeitraums, den diese Zahlung abdeckt.
period_endRFC 3339JaNeinEnde des Zeitraums, den diese Zahlung abdeckt. Sie können es als Ablauf des Zugriffs verwenden.
order_idhashidNeinJaBestell-ID.
space_idhashidNeinJaDer gekaufte Space.
payment_intent_idstringNeinJaStripe-PaymentIntent-ID.
  • Das Ereignis hat kein plan_id.
  • Ein Einmalkauf sendet dies, nachdem der Zugriff gewährt wurde, einmal pro Bestellung.

subscription.renewed

Ein Abonnement wurde erfolgreich verlängert. Die Felder sind dieselben wie in der Form von payment.received für Abonnementrechnungen.

  • Eine Verlängerung sendet beide Ereignisse, mit unterschiedlichen event_id-Werten. Wenn Sie beide abonnieren, verbuchen Sie den Umsatz nicht doppelt.

payment.failed

Die Zahlung einer Rechnung ist fehlgeschlagen. Es wird bei jedem Fehlschlag gesendet, auch jedes Mal, wenn Stripe die Abbuchung wiederholt.

FeldTypImmer vorhandenBeschreibung
member_idhashidJaMitglieds-ID.
usernamestringNeinWird weggelassen, wenn das Mitglied nicht mehr existiert.
emailstringNeinWird weggelassen, wenn das Mitglied nicht mehr existiert.
invoice_idstringJaStripe-Rechnungs-ID.
subscription_idstringJaStripe-Abonnement-ID.
amount_due_centsnumberJaDer fällige Betrag.
currencystringJaWährung.
attempt_countnumberJaDer wievielte Versuch dies für die Rechnung ist.

subscription.created

Ein Abonnement wurde in Stripe angelegt. Das bedeutet nicht, dass es bezahlt wurde; verwenden Sie dafür payment.received.

FeldTypImmer vorhandenBeschreibung
member_idhashidJaMitglieds-ID.
usernamestringNeinWird weggelassen, wenn das Mitglied nicht mehr existiert.
emailstringNeinWird weggelassen, wenn das Mitglied nicht mehr existiert.
subscription_idstringJaStripe-Abonnement-ID.
plan_idhashidJaDie ID des Mitglieder-Abonnementtarifs.
statusstringJaÜbliche Werte: active, trialing und incomplete (erste Rechnung nicht beglichen).
price_centsnumberJaDer Einzelpreis des Tarifs, vor Rabatten.
currencystringJaWährung.
billing_periodstringJamonthly oder annual.
period_startRFC 3339JaBeginn des laufenden Zeitraums.
period_endRFC 3339JaEnde des laufenden Zeitraums.

subscription.canceled

Ein Abonnement ist tatsächlich beendet. Wenn ein Mitglied die Kündigung zum Periodenende vormerkt, wird es nicht gesendet; das Periodenende löst es aus.

FeldTypImmer vorhandenBeschreibung
member_idhashidJaMitglieds-ID.
usernamestringNeinWird weggelassen, wenn das Mitglied nicht mehr existiert.
emailstringNeinWird weggelassen, wenn das Mitglied nicht mehr existiert.
subscription_idstringJaStripe-Abonnement-ID.
plan_idhashidJaDie ID des Mitglieder-Abonnementtarifs.
previous_statusstringJaDer Status vor dem Ende, zum Beispiel active, trialing oder past_due.
cancelled_atRFC 3339JaWann es endete.
  • Auch ein Abonnement, das abläuft, ohne je bezahlt worden zu sein, sendet dies, mit previous_status gleich incomplete. Dieses Mitglied hatte nie Zugriff; zählen Sie es daher nicht als Abwanderung.
  • Die Schreibweise ist uneinheitlich: Das Ereignis heißt canceled, das Feld cancelled_at, und der Statuswert des Abonnements ist cancelled.

refund.issued

Eine Rückerstattung wurde veranlasst. Rückerstattungen von Abonnementrechnungen und von Einmalkäufen teilen sich dieses Ereignis, mit unterschiedlichen Feldern. Sie unterscheiden sie daran, ob invoice_id vorhanden ist.

FeldTypAbonnementrechnungEinmalkaufBeschreibung
member_idhashidJaJaMitglieds-ID.
usernamestringNormalerweiseNormalerweiseWird weggelassen, wenn das Mitglied nicht mehr existiert.
emailstringNormalerweiseNormalerweiseWird weggelassen, wenn das Mitglied nicht mehr existiert.
amount_refunded_centsnumberJaJaDie bisher insgesamt erstattete Summe, nicht der Betrag dieser Rückerstattung.
currencystringJaJaWährung.
refund_statusstringrefunded oder partially_refundedrefundedDer Status nach der Rückerstattung.
is_partialbooleanJaImmer falseOb es sich um eine Teilrückerstattung handelt.
previous_statusstringZum Beispiel paid oder partially_refundedcompletedDer Status vor der Rückerstattung.
invoice_idstringJaNeinStripe-Rechnungs-ID.
charge_idstringJa, kann ein leerer String seinNur bei in Stripe veranlassten RückerstattungenStripe-Charge-ID.
order_idhashidNeinJaBestell-ID.
space_idhashidNeinJaDer gekaufte Space.
payment_intent_idstringNeinJaStripe-PaymentIntent-ID.
  • Eine in Stripe vorgenommene Teilrückerstattung eines Einmalkaufs sendet kein Ereignis, und Bestellung und Zugriff bleiben unverändert.

Testzustellungen

Webhook testen in der Admin-Oberfläche sendet sofort eine Anfrage und schreibt das Ergebnis ins Zustellprotokoll. Auch ein ausgeschalteter Webhook lässt sich testen, und der Test wird nicht wiederholt. Das Format ist dasselbe wie bei einer echten Zustellung, einschließlich der Signatur, bis auf Folgendes.

PunktTestzustellungEchte Zustellung
testtrueNicht vorhanden
eventImmer member.joined, unabhängig davon, welche Ereignisse der Webhook abonniert hatDas abonnierte Ereignis
dataBeispieldatenEchte Daten
event_id, occurred_atNicht vorhandenVorhanden

Prüfen Sie zuerst test und antworten Sie mit 200, wenn es true ist. Sonst könnte ein Test von member.joined in Ihrem System tatsächlich ein Mitglied anlegen.

Weitere Kanäle

Die Zustellprotokolle zeigen auch diese Quellen. Sie verwenden dieselben Ereignisse wie eigene Webhooks, in anderen Formaten.

KanalBodySignaturWeitere Unterschiede
ZapierDieselben data. Der Umschlag ergänzt ein boolesches test und hat kein webhook_id.Nur, wenn beim Verbinden ein Signatur-Secret gesetzt wurde. Derselbe Algorithmus.Ergänzt einen Header X-Mateflow-Delivery-Id.
Slack, DiscordNur lesbarer Text, als text bei Slack und content bei Discord.Wie bei Zapier.Ergänzt einen Header X-Mateflow-Delivery-Id. Keine strukturierten Felder.
Automatisierungsregel: Webhook auslösenDie in der Regel hinterlegte Vorlage.Nur, wenn die Regel ein Secret hat. Derselbe Algorithmus.Verwendet diesen Umschlag nicht. Die Regel entscheidet, wann gesendet wird.
Mit der Open API in Ihre Community zurückrufen

Jetzt loslegen

Legen Sie in der Admin-Oberfläche Ihrer Community einen Webhook an, senden Sie eine Testzustellung und prüfen Sie sie in den Protokollen.

14 Tage kostenlos testen · Danach Free für bis zu 100 Mitglieder · Ohne Kreditkarte