Eventi ordine
Eventi relativi al ciclo di vita e alla gestione degli ordini.storekit non invia un evento
order.accepted o order.rejected. Dopo order.created.v2, il successivo evento che ricevi per un ordine è il suo primo cambio di stato (order.preparing, order.ready_for_pickup, order.out_for_delivery, order.completed o order.canceled).order.created.v2
Attivato quando un cliente effettua un nuovo ordine. Questo è l’evento a cui iscriversi per i nuovi ordini.order.created
L’evento legacy per un nuovo ordine. Contiene gli stessi campi ordine diorder.created.v2, ma li invia come body di primo livello senza wrapper event o data:
Entrambi gli eventi vengono inviati per ogni nuovo ordine. Iscriviti a
order.created.v2 in modo che il tuo handler riceva la struttura standard del payload usata da ogni altro evento. order.created resta disponibile per le integrazioni esistenti.order.canceled
Attivato quando un ordine viene annullato.order.preparing
Attivato quando un ordine passa allo stato in preparazione.order.ready_for_pickup
Attivato quando un ordine viene contrassegnato come pronto per il ritiro da parte del cliente.order.out_for_delivery
Attivato quando un ordine in consegna viene affidato al corriere.order.completed
Attivato quando un ordine viene contrassegnato come completato. Si verifica per completamenti di singoli ordini (dalla dashboard, Deliverect, iKentoo o auto-update) così come per completamenti in blocco.order.pos.dispatch.failed
Attivato quando un ordine non riesce a essere inviato a un sistema POS.order.rating.updated
Attivato quando un cliente invia o aggiorna una valutazione per il proprio ordine.order.refund.created, order.refund.succeeded, order.refund.failed
order.refund.created si attiva quando viene emesso un rimborso dalla dashboard; a seguire order.refund.succeeded o order.refund.failed una volta che il gateway di pagamento lo elabora. Tutti e tre condividono la stessa forma e, a differenza di altri eventi, i campi si trovano accanto a event invece che dentro data:
customer.id e refund.reason sono null quando non disponibili.
Eventi negozio
Eventi relativi allo stato e alla configurazione del negozio.store.opened
Attivato quando un negozio viene aperto, quando uno snooze viene terminato in anticipo o quando uno snooze temporizzato scade automaticamente.store.closed
Attivato quando un negozio viene chiuso o messo in snooze.closedReason e closedUntil sono stringhe vuote quando il negozio è stato chiuso senza motivo o senza un orario di fine.
store.opening_hours.updated
Attivato quando gli orari di apertura vengono modificati per un negozio, dalla dashboard o da una sincronizzazione POS.Eventi articolo
Eventi relativi alla disponibilità degli articoli di menu.item.out_of_stock
Attivato quando un articolo del menu diventa non disponibile. Può accadere per diverse vie:- Snooze manuale — un amministratore mette in snooze l’articolo dalla dashboard
- Disabilitazione manuale — un amministratore imposta la disponibilità dell’articolo su off
- Esaurimento inventario — l’inventario dell’articolo raggiunge zero dopo un ordine
- Sincronizzazione integrazione — un POS o un’integrazione (Deliverect, Lightspeed, Zonal) contrassegna l’articolo come non disponibile
reason indica perché l’articolo è andato esaurito e source indica cosa lo ha attivato.
details varia in base al motivo:
snoozed— includesnoozeEnd(timestamp ISO 8601, oppurenullper snooze indefiniti)inventory_depleted—{}vuotodisabled—{}vuoto
Eventi pagamenti
Eventi relativi a pagamenti e payout.payments.payout.created
Attivato quando storekit invia un payout al tuo conto bancario.estimatedArrivalDate è una stringa mese/anno, oppure una stringa vuota quando il provider del payout non ne fornisce una.
payment_link.created
Attivato quando viene creato un nuovo payment link. Si attiva solo per gli account con i webhook abilitati.payment_link.paid
Attivato quando un pagamento viene incassato con successo tramite un payment link. Si attiva solo per gli account con i webhook abilitati.payment_link.refund.created
Attivato quando viene avviato un rimborso per un pagamento payment link. A questo punto il rimborso è in stato pending — la conferma arriva tramitepayment_link.refund.succeeded o payment_link.refund.failed una volta che il gateway di pagamento lo elabora in modo asincrono.
payment_link.refund.succeeded
Attivato quando il gateway di pagamento conferma che un rimborso è stato elaborato con successo. Si attiva in modo asincrono dopopayment_link.refund.created.
payment_link.refund.failed
Attivato quando il gateway di pagamento rifiuta un rimborso. Si attiva in modo asincrono dopopayment_link.refund.created.