Événements de commande
Événements liés au cycle de vie et à la gestion des commandes.storekit n’envoie pas d’événement
order.accepted ni order.rejected. Après order.created.v2, le prochain événement que vous recevez pour une commande est son premier changement de statut (order.preparing, order.ready_for_pickup, order.out_for_delivery, order.completed ou order.canceled).order.created.v2
Déclenché lorsqu’un client passe une nouvelle commande. C’est l’événement auquel s’abonner pour les nouvelles commandes.order.created
L’événement historique de nouvelle commande. Il transporte les mêmes champs de commande queorder.created.v2, mais les envoie comme corps racine sans wrapper event ou data :
Les deux événements sont envoyés pour chaque nouvelle commande. Abonnez-vous à
order.created.v2 pour que votre handler reçoive la structure de payload standard utilisée par tous les autres événements. order.created reste disponible pour les intégrations existantes.order.canceled
Déclenché lorsqu’une commande est annulée.order.preparing
Déclenché lorsqu’une commande passe au statut « en préparation ».order.ready_for_pickup
Déclenché lorsqu’une commande est marquée comme prête pour le retrait par le client.order.out_for_delivery
Déclenché lorsqu’une commande en livraison est expédiée.order.completed
Déclenché lorsqu’une commande est marquée comme terminée. Cet événement se déclenche aussi bien pour les complétions individuelles (via le tableau de bord, Deliverect, iKentoo ou la mise à jour automatique) que pour les complétions groupées.order.pos.dispatch.failed
Déclenché lorsqu’une commande n’a pas pu être transmise à un système POS.order.rating.updated
Déclenché lorsqu’un client soumet ou met à jour une note pour sa commande.order.refund.created, order.refund.succeeded, order.refund.failed
order.refund.created se déclenche lorsqu’un remboursement est émis depuis le tableau de bord ; order.refund.succeeded ou order.refund.failed suit une fois que la passerelle de paiement l’a traité. Les trois partagent la même structure, et contrairement aux autres événements, les champs se trouvent à côté de event plutôt qu’à l’intérieur de data :
customer.id et refund.reason sont null lorsqu’ils ne sont pas disponibles.
Événements de magasin
Événements liés au statut et à la configuration du magasin.store.opened
Déclenché lorsqu’un magasin est ouvert, lorsqu’une pause est terminée plus tôt, ou lorsqu’une pause programmée expire automatiquement.store.closed
Déclenché lorsqu’un magasin est fermé ou mis en pause.closedReason et closedUntil sont des chaînes vides lorsque le magasin a été fermé sans motif ou sans heure de fin.
store.opening_hours.updated
Déclenché lorsque les horaires d’ouverture d’un magasin sont modifiés, depuis le tableau de bord ou par une synchronisation POS.Événements d’article
Événements liés à la disponibilité des articles du menu.item.out_of_stock
Déclenché lorsqu’un article du menu devient indisponible. Cela peut se produire par plusieurs biais :- Mise en pause manuelle — un administrateur met l’article en pause depuis le tableau de bord
- Désactivation manuelle — un administrateur bascule la disponibilité de l’article sur off
- Épuisement de l’inventaire — l’inventaire de l’article atteint zéro après une commande
- Synchronisation d’intégration — un POS ou une intégration (Deliverect, Lightspeed, Zonal) marque l’article comme indisponible
reason indique pourquoi l’article est en rupture de stock, et source indique ce qui l’a déclenché.
details varie selon le motif :
snoozed— inclutsnoozeEnd(horodatage ISO 8601, ounullpour les pauses indéfinies)inventory_depleted—{}videdisabled—{}vide
Événements de paiement
Événements liés aux paiements et aux virements.payments.payout.created
Déclenché lorsque storekit envoie un virement sur votre compte bancaire.estimatedArrivalDate est une chaîne au format mois/année, ou une chaîne vide lorsque le fournisseur de paiement n’en a pas fourni.
payment_link.created
Déclenché lorsqu’un nouveau payment link est créé. Envoyé uniquement pour les comptes dont les webhooks sont activés.payment_link.paid
Déclenché lorsqu’un paiement est encaissé avec succès via un payment link. Envoyé uniquement pour les comptes dont les webhooks sont activés.payment_link.refund.created
Déclenché lorsqu’un remboursement est initié pour un paiement effectué via un payment link. Le remboursement est à ce stade en attente — la confirmation arrive viapayment_link.refund.succeeded ou payment_link.refund.failed une fois que la passerelle de paiement l’a traité de manière asynchrone.
payment_link.refund.succeeded
Déclenché lorsque la passerelle de paiement confirme qu’un remboursement a été traité avec succès. Cet événement se déclenche de manière asynchrone aprèspayment_link.refund.created.
payment_link.refund.failed
Déclenché lorsque la passerelle de paiement rejette un remboursement. Cet événement se déclenche de manière asynchrone aprèspayment_link.refund.created.