Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.digifist.com/llms.txt

Use this file to discover all available pages before exploring further.

When a product variant is restocked in Shopify, a specific chain of events fires in Galantis — from webhook receipt through restock detection, trigger evaluation, and message dispatch to every qualifying subscriber. Understanding this pipeline helps diagnose timing expectations, troubleshoot missed notifications, and configure the automation correctly.

​
What this covers

  • The full notification pipeline step by step
  • What Galantis detects as a restock event
  • How the BACK_IN_STOCK automation trigger fires
  • Which subscribers receive notifications and which are excluded
  • Credit consumption
  • Timing expectations

​
The notification pipeline

1. Variant inventory updated in Shopify (inventory_quantity 0 → > 0)
2. Shopify sends products/update webhook to Galantis
3. ProcessShopifyProductUpdatedJob detects inventory_quantity change
4. Change confirmed as 0 → > 0 (restock event identified)
5. BACK_IN_STOCK automation trigger fires
6. Galantis queries all ACTIVE subscriptions for this variant
7. Per subscriber: consent check (marketing_state = SUBSCRIBED?)
8. Per subscriber: frequency cap check (within cap window?)
9. Qualifying subscribers enrolled into the Back-in-Stock automation flow
10. Action Node sends the approved restock notification template
11. Subscription status moves to NOTIFIED
12. Credits consumed per notification successfully sent

​
Step-by-step breakdown

​
Step 1–2: Shopify webhook

The pipeline starts in Shopify. When a merchant updates inventory — manually in the Shopify admin, through a warehouse or fulfillment integration, or via the Shopify API — Shopify saves the change and fires a products/update webhook to all registered apps, including Galantis. The webhook fires for any product update, not only inventory changes. Galantis must identify whether the update contains a relevant inventory change.

​
Step 3–4: Restock detection

ProcessShopifyProductUpdatedJob receives the webhook payload and scans the variant data for inventory changes. It specifically looks for the pattern: a variant whose inventory_quantity has changed from 0 to any positive value. This is the definition of a restock event in Galantis. Updates that do not match this pattern — a variant going from 5 to 10, a price change on an in-stock variant, or a title update — do not trigger the Back-in-Stock pipeline, even though they arrive via the same webhook.
A variant that goes from 0 to 0 — for example, a product update where inventory remains zero — does not trigger the pipeline. The detection requires a positive inventory value, not just a change event.

​
Step 5: Trigger fires

Once a restock event is identified for a specific variant, the BACK_IN_STOCK automation trigger fires. This trigger is scoped to the variant — it fires independently for each variant that restocks, even if multiple variants of the same product restock simultaneously.

​
Step 6: Subscriber query

Galantis queries all subscription records for the restocked variant and filters to those with ACTIVE status. Subscriptions in PENDING, NOTIFIED, or CANCELLED status are excluded at this step.

​
Step 7–8: Per-subscriber eligibility checks

For each ACTIVE subscriber, Galantis applies two eligibility checks before enrollment: Consent check — The subscriber’s marketing_state must be SUBSCRIBED. Subscribers with UNSUBSCRIBED, REDACTED, PENDING, or any other non-subscribed state are excluded. See Consent & Opt-outs. Frequency cap check — The subscriber must not be within the automation’s frequency cap window. A 24 hours cap on the Back-in-Stock automation prevents a subscriber from receiving multiple notifications within a 24-hour period — relevant if the same variant restocks and sells out multiple times in quick succession. See Automations — Frequency Caps.

​
Step 9–10: Enrollment and dispatch

Subscribers who pass both checks are enrolled in the Back-in-Stock automation flow. The Action Node sends the approved restock notification template immediately — no delay node is used in the standard Back-in-Stock recipe, because the customer explicitly requested to be notified as soon as the product is available. Template variable mapping at the Action Node should include the customer’s name and the product name. See Automations — Recipes — Back-in-Stock Notification for the recommended template configuration.

​
Step 11: Status update

After the notification is dispatched, each enrolled subscriber’s subscription status moves from ACTIVE to NOTIFIED. This transition happens regardless of whether the message was successfully delivered — it is a dispatch record, not a delivery confirmation. A subscriber whose message failed (due to a phone number error, a missing calling code, or insufficient credits) will have NOTIFIED status even though they did not receive the message. Check the automation activity log for the specific failure reason per subscriber.

​
Step 12: Credit consumption

Credits are consumed per notification successfully sent — not per subscriber enrolled. A notification that fails before reaching the WhatsApp API does not consume a credit. See Back-in-Stock Add-on Billing.

​
Timing expectations

The notification pipeline is designed for near-real-time delivery. The time between a merchant updating inventory in Shopify and a subscriber receiving a WhatsApp message is typically a matter of seconds to a low number of minutes, depending on:
  • Shopify webhook delivery latency (typically seconds)
  • Galantis queue depth at the time of processing
  • WhatsApp API delivery to the subscriber’s device
There is no intentional delay in the standard pipeline — unlike abandoned checkout recovery, which uses a delay node to give the customer time to return on their own, Back-in-Stock notifications are designed to be immediate. Speed is a competitive advantage: a subscriber who receives a restock notification first is more likely to convert before the stock sells out again.

​
What can prevent a notification from sending

CauseResultHow to identify
Subscriber in PENDING, NOTIFIED, or CANCELLED statusNot enrolledSubscription status in Back-in-Stock → Subscriptions
Subscriber’s marketing_state ≠ SUBSCRIBEDSkipped — consent check failedContact profile in Audience → Contacts
Subscriber within frequency cap windowSkipped — cap activeAutomation activity log
Notification template not APPROVEDFlow fails for all subscribersTemplate status in Templates
Insufficient creditsFails after partial dispatchBilling balance in Billing → Overview
Phone number missing calling codeFAILED per subscriberAutomation activity log, error: CUSTOMER_IS_MISSING_CALLING_CODE