Skip to main content
Diese Seite listet alle in storekit verfügbaren Webhook-Events auf, gruppiert nach Kategorie.

Order-Events

Events rund um den Bestell-Lebenszyklus und die Bestellverwaltung.
storekit sendet kein order.accepted- oder order.rejected-Event. Nach order.created.v2 ist das nächste Event, das Sie für eine Bestellung erhalten, ihre erste Statusänderung (order.preparing, order.ready_for_pickup, order.out_for_delivery, order.completed oder order.canceled).

order.created.v2

Wird ausgelöst, wenn ein Kunde eine neue Bestellung aufgibt. Dies ist das Event, das Sie für neue Bestellungen abonnieren sollten.

order.created

Das Legacy-Event für neue Bestellungen. Es enthält dieselben Order-Felder wie order.created.v2, sendet sie aber als Top-Level-Body ohne event- oder data-Hülle:
Beide Events werden für jede neue Bestellung gesendet. Abonnieren Sie order.created.v2, damit Ihr Handler die Standard-Payload-Struktur empfängt, die von jedem anderen Event verwendet wird. order.created bleibt für bestehende Integrationen verfügbar.

order.canceled

Wird ausgelöst, wenn eine Bestellung storniert wird.

order.preparing

Wird ausgelöst, wenn eine Bestellung in den Status „preparing” wechselt.

order.ready_for_pickup

Wird ausgelöst, wenn eine Bestellung als bereit zur Kundenabholung markiert wird.

order.out_for_delivery

Wird ausgelöst, wenn eine Lieferbestellung versendet wird.

order.completed

Wird ausgelöst, wenn eine Bestellung als abgeschlossen markiert wird. Dies wird sowohl für einzelne Bestellabschlüsse (über das Dashboard, Deliverect, iKentoo oder Auto-Update) als auch für Massenabschlüsse ausgelöst.

order.pos.dispatch.failed

Wird ausgelöst, wenn die Übermittlung einer Bestellung an ein POS-System fehlschlägt.

order.rating.updated

Wird ausgelöst, wenn ein Kunde eine Bewertung für seine Bestellung abgibt oder aktualisiert.

order.refund.created, order.refund.succeeded, order.refund.failed

order.refund.created wird ausgelöst, wenn eine Rückerstattung aus dem Dashboard veranlasst wird; order.refund.succeeded oder order.refund.failed folgt, sobald das Payment-Gateway sie verarbeitet. Alle drei teilen sich eine Struktur, und anders als bei anderen Events liegen die Felder neben event statt innerhalb von data:
customer.id und refund.reason sind null, wenn nicht verfügbar.

Store-Events

Events rund um Store-Status und -Konfiguration.

store.opened

Wird ausgelöst, wenn ein Store geöffnet wird, wenn ein Snooze vorzeitig beendet wird oder wenn ein zeitlich begrenzter Snooze automatisch abläuft.

store.closed

Wird ausgelöst, wenn ein Store geschlossen oder pausiert wird.
closedReason und closedUntil sind leere Strings, wenn der Store ohne Grund oder ohne Endzeitpunkt geschlossen wurde.

store.opening_hours.updated

Wird ausgelöst, wenn die Öffnungszeiten für einen Store geändert werden – aus dem Dashboard oder durch einen POS-Sync.

Item-Events

Events rund um die Verfügbarkeit von Menüartikeln.

item.out_of_stock

Wird ausgelöst, wenn ein Menüartikel nicht mehr verfügbar wird. Das kann auf mehreren Wegen passieren:
  • Manuelles Snoozen – ein Admin pausiert den Artikel im Dashboard
  • Manuelles Deaktivieren – ein Admin setzt die Verfügbarkeit des Artikels auf „aus”
  • Bestandserschöpfung – der Bestand des Artikels erreicht nach einer Bestellung null
  • Integrations-Sync – ein POS oder eine Integration (Deliverect, Lightspeed, Zonal) markiert den Artikel als nicht verfügbar
Das Feld reason gibt an, warum der Artikel ausverkauft ist, und source zeigt, was es ausgelöst hat.
Das details-Objekt variiert je nach Grund:
  • snoozed – enthält snoozeEnd (ISO-8601-Zeitstempel oder null bei unbefristeten Pausen)
  • inventory_depleted – leer {}
  • disabled – leer {}

Payments-Events

Events rund um Zahlungen und Auszahlungen.

payments.payout.created

Wird ausgelöst, wenn storekit eine Auszahlung an Ihr Bankkonto sendet.
estimatedArrivalDate ist ein month/year-String oder ein leerer String, wenn der Auszahlungsanbieter keinen geliefert hat. Wird ausgelöst, wenn ein neuer Payment-Link erstellt wird. Wird nur für Konten mit aktivierten Webhooks ausgelöst.
Wird ausgelöst, wenn über einen Payment-Link erfolgreich eine Zahlung eingezogen wird. Wird nur für Konten mit aktivierten Webhooks ausgelöst.
Wird ausgelöst, wenn eine Rückerstattung für eine Payment-Link-Zahlung veranlasst wird. Die Rückerstattung ist zu diesem Zeitpunkt ausstehend – die Bestätigung folgt über payment_link.refund.succeeded oder payment_link.refund.failed, sobald das Payment-Gateway sie asynchron verarbeitet.
Wird ausgelöst, wenn das Payment-Gateway bestätigt, dass eine Rückerstattung erfolgreich verarbeitet wurde. Dies wird asynchron nach payment_link.refund.created ausgelöst.
Wird ausgelöst, wenn das Payment-Gateway eine Rückerstattung ablehnt. Dies wird asynchron nach payment_link.refund.created ausgelöst.

Printer-Events

Events rund um den Cloud-Drucker-Status.

printer.status.offline

Wird ausgelöst, wenn sich ein verbundener Cloud-Drucker 5 Minuten lang nicht beim storekit-Server meldet. Zusätzlich wird eine E-Mail-Benachrichtigung an die konfigurierte E-Mail-Adresse des Venues gesendet.
Ein von mehreren Stores geteilter Drucker sendet ein Event pro Store.

printer.status.online

Wird ausgelöst, wenn sich ein Cloud-Drucker nach mindestens 5 Minuten Offline-Zeit wieder mit unseren Servern verbindet. Zusätzlich wird eine E-Mail-Benachrichtigung gesendet, die bestätigt, dass der Drucker wieder online ist.