# Billing & Pricing
Source: https://docs.digifist.com/galantis/connect/billing-pricing
How Galantis Connect pricing works: public plans, usage-based add-ons, marketplace commissions, and custom offers for closed ERP integrations.
All app subscription charges for Shopify stores appear on your Shopify invoice. Plan changes and spending-limit approvals are confirmed by the store owner in Shopify.
## Overview
Galantis Connect uses a simple approach:
* **Public plans** for self-serve merchants (great for feeds + marketplaces).
* **Add-ons and usage-based charges** when you enable more channels/modules or exceed plan allowances.
* **Custom plans (private offers)** for sales-assisted deals and closed/complex integrations (e.g. ERP systems).
* Optional **one-time integration setup fees** for non-existing integrations.
This structure helps merchants start small and scale automatically as their usage grows.
## Public plans
These are the default plans available for self-serve onboarding.
**\$39 / month**
* Best for: feeds-first onboarding
* Marketplace commissions at the highest tier (see below)
* Add-ons available (feeds, marketplace channels, shipping module)
**\$79 / month**
* Best for: multi-channel growth
* Better marketplace commission rate than Start
* Higher included allowances than Start
**\$129 / month**
* Best for: high-volume operations
* Lowest marketplace commission rate
* Highest included allowances
Your exact included allowances (orders/SKUs/feeds/shipping volume) are always shown in the **Billing Center** inside the app, and we'll proactively prompt upgrades when it becomes cheaper than paying overages.
## Add-ons and usage-based billing
Most expansions are billed as **usage-based add-ons**, so merchants can "pay as they grow" without needing a long price page.
### Additional feed destinations
* **€29 per additional feed destination / month**
* Charged when you exceed the number of included feeds in your plan
**Example:**
* Plan includes 2 feeds, you run 4 feeds → **2 × €29** billed as a monthly add-on.
## Marketplaces: channel fees + commission
Marketplaces are monetized in two layers:
1. **Marketplace channel add-on** (enabling a marketplace channel)
2. **Commission** based on the value/orders synced (tiered by plan)
### Commission rates (by plan)
| Plan | Commission rate |
| ----- | --------------- |
| Start | **0.60%** |
| Grow | **0.30%** |
| Scale | **0.15%** |
Marketplace commission is charged **on top of** any marketplace/channel costs and any other add-ons you use.
## Shipping module
The Shipping module is billed as a module add-on and includes:
* **3 carriers included**
* A plan-based volume allowance (caps increase on higher plans)
* Overages apply only when you exceed the included monthly volume
Shipping usage is measured by the number of orders/shipments processed through the Shipping module in the billing period.
Yes. Higher plans include higher allowances and typically lower effective costs at scale. Your Billing Center shows current allowance and estimated next invoice.
## ERP and closed integrations
ERP integrations are **niche and often custom**, so we treat them differently than feeds/marketplaces:
* They can be enabled as **integration modules/connections**
* They may require a **custom plan** or a **private offer**
* They may include a **one-time integration setup fee** for non-existing integrations
### One-time integration setup fee
If an integration does not exist yet, we may charge:
* **€1,500 one-time integration setup fee**
This typically applies when custom mapping, development, and validation are required.
The one-time integration setup fee is for building a new integration or connector scope. It is separate from monthly subscriptions and add-ons.
## Custom plans (private offers)
Custom plans give us the flexibility to handle:
* closed ERP integrations
* enterprise requirements (SLA, advanced routing, multi-store setups)
* bundles of modules (e.g. shipping included)
* negotiated pricing
* limited-time promos
### How custom plans work
Merchants will see:
* public plans (Start/Grow/Scale)
* **plus** any private offer they've been granted
Private offers appear in the Billing Center as an additional plan option, clearly labeled as a custom offer.
A custom plan can change any of the following:
* base monthly price
* included allowances (feeds, SKUs, orders, shipping volume)
* which modules are included
* add-on rates (where applicable)
* marketplace commission rate (where contractually agreed)
* duration-based discounts (e.g. 20% for 3 months)
**Example A — ERP deal (custom offer)**
* Base price: €599/month
* Includes: 2 integration connections
* Shipping module included (no monthly shipping base add-on)
**Example B — Promo**
* Grow plan with 25% discount for 3 billing cycles
Custom plans are designed to remain compatible with the same add-on/usage model (channels, modules, overages), so customers can still scale without renegotiating every time.
## Discounts, credits, and adjustments
We support discounts in two main ways:
* **Subscription discounts** (percentage or fixed discounts on the base plan)
* **Usage discounts** (discounts applied to specific add-ons or usage charges)
If something needs to be corrected (e.g. billing adjustment), we may apply a credit or a one-off adjustment depending on the situation.
Discount availability may depend on your plan type and the scope (public plan vs private offer). Contact support for custom discount structures.
## How billing works (end-to-end)
Start with a public plan (Start/Grow/Scale) or accept a private offer if provided.
Add feeds, marketplace channels, shipping, or integrations as needed.
If a new module could exceed your billing spend limit for the cycle, Shopify will request approval.
You are billed monthly for your base plan, plus any usage-based add-ons, commissions, and overages.
## FAQ
Most merchants want an easy entry point. We keep public plans minimal and let customers scale through add-ons and usage-based billing as they grow.
Yes. Many merchants start with feeds only and add marketplaces later.
The Billing Center shows your current plan, enabled add-ons, and an estimate based on current usage.
Yes. For closed ERP systems, enterprise requirements, or agency-led deals we can provide a private offer/custom plan.
No. Marketplace commissions are charged on top of marketplace/channel costs and any third-party fees.
# Managing Connections
Source: https://docs.digifist.com/galantis/connect/connections
Create data flows between integrations with field mapping.
A **Connection** links two integrations and defines the data flow between them.
## Creating a Connection
1. Navigate to the **Connections** section.
2. Click **Add Connection**.
3. Follow the setup wizard.
4. Select:
* Source integration (data origin)
* Target integration (data destination)
5. Map:
* Source integration fields → Project Fields
* Project Fields → Target integration fields
# Galantis Connect
Source: https://docs.digifist.com/galantis/connect/index
A powerful platform for synchronizing data between your business systems.
## Getting Started
Welcome to **Galantis Connect**, a powerful platform for synchronizing data between your various business systems. This document will guide you through the core concepts and features of the platform, helping you set up and manage your data flows effectively.
## Core Concepts
At its core, Galantis Connect is built around a few key concepts:
### Projects
A **Project** is a workspace that contains all your integrations, connections, and rules. It's the top-level container for a specific data synchronization setup.
### Integrations
An **Integration** is a connection to an external service, such as a Shopify store or an ERP system. You'll need to create an integration for each system you want to connect to Galantis Connect.
### Project Fields (Field Mapping)
**Project Fields** are custom fields you define within a project. They act as a central, canonical data model for your project.
Example: `product_sku`
You then map fields from your various integrations to these central Project Fields. This is the heart of the field-mapping process.
### Connections
A **Connection** defines the flow of data between two integrations. It specifies:
* A source integration
* A target integration
* The direction of the data flow
### Rules
The **Rule Engine** allows you to create powerful conditional logic to manipulate your data as it passes through Galantis Connect.
Rules can be used to:
* Clean data
* Transform data
* Validate data
This ensures the data is in the correct format before it reaches its destination.
## Next steps
Learn how to add and configure external service connections
Define your canonical data model with custom fields
Create data flows between your integrations
Build conditional logic to transform your data
# Managing Integrations
Source: https://docs.digifist.com/galantis/connect/integrations
Connect external services to your Galantis Connect project.
An integration represents a connection to an external service. Before you can sync any data, you need to add and configure your integrations.
## Adding an Integration
1. Navigate to the **Integrations** section in the Project Panel.
2. Click **Add Integration**.
3. Select the integration type (e.g., Shopify).
4. Fill in the required credentials and settings.
5. Save the integration.
## Verifying an Integration
After adding an integration, you need to verify it. This usually involves authorizing Galantis Connect to access your data on the external platform.
Once completed, the integration status will appear as **Verified**.
# Field Mapping (Project Fields)
Source: https://docs.digifist.com/galantis/connect/project-fields
Define your canonical data model with custom field mapping.
Field mapping in Galantis Connect is handled by **Project Fields**. These are the central, standardized fields for your project.
## Creating Project Fields
1. Navigate to the **Project Fields** section.
2. Click **Add Field**.
3. Enter a field name (e.g., `product_name`, `customer_email`).
* Use lowercase
* No spaces (use underscores)
4. Select the **Entity Type**:
* Product
* Customer
* Order
5. Add a description explaining the field's purpose.
6. Save the field.
Once defined, Project Fields can be mapped during **Connection** setup.
# The Rule Engine
Source: https://docs.digifist.com/galantis/connect/rule-engine
Build conditional logic to transform and validate data.
The **Rule Engine** is one of the most powerful features of Galantis Connect. It allows you to build complex logic to transform your data.
## Creating a Rule
1. Navigate to the **Master Rules** section.
2. Click **Add Rule**.
3. Enter a rule name and description.
4. Select the **Entity Type**:
* Product
* Order
* Customer
## Conditions
Conditions define **when** a rule should be applied.
A condition consists of:
* Project Field
* Operator (equals, contains, greater than, etc.)
* Value
Multiple conditions can be combined using:
* AND
* OR
## Actions
Actions define **what happens** when conditions are met.
An action consists of:
* Action Type (Set Field Value, Copy From Field, Replace Text, etc.)
Depending on the action, you may need:
* A Project Field
* A Value
* Additional parameters
## Example Rule
```text theme={null}
IF country equals "USA"
THEN set shipping_cost to "10"
```
# Analytics
Source: https://docs.digifist.com/galantis/discount/analytics/index
How Galantis Discount Flow measures campaign performance — every metric defined, how orders are attributed, how refunds are handled, and how to export your data.
Galantis Discount Flow tracks every campaign from storefront view to paid order, so you can see exactly what each discount costs and what it brings back. All numbers come from real Shopify order data — order created, order paid, refund created, and order cancelled webhooks — so what you see reflects actual orders, not estimates.
## Dashboard vs the Analytics page
The app gives you two views of the same underlying data:
* **Dashboard (Home)** — a quick daily health check: metric cards for **Active Campaigns**, **Total Usage** (applications, with a 7-day trend), **Total Revenue** (with the refunded amount shown alongside), and **Conversion Rate** (with total discounts given). Below the cards you get a **Revenue Trend** chart (Revenue + Refunds), a **Campaign Distribution** donut grouped by status, a **Needs Attention** list, **Top Performers** (your top 3 campaigns by revenue), **Recent Campaigns**, and a plan usage card. If your shop is on the Free plan and has hit its monthly cap, a usage-paused banner appears here.
* **Analytics page** — the deep-dive view with a longer time range, more charts, a per-campaign performance table, and CSV export.
## Analytics page controls
Three controls at the top of the Analytics page shape everything below them:
| Control | What it does |
| -------------------- | ---------------------------------------------------------------------------------------------- |
| **Period** | Switches the reporting window between **Last 7 days**, **Last 30 days**, and **Last 90 days**. |
| **Include archived** | When checked, archived campaigns are included in metrics, charts, and the performance table. |
| **Export CSV** | Downloads the current view as a CSV file for your own reporting or spreadsheets. |
The **Conversion Rate** card compares the selected period against the previous period of the same length, so switching **Period** also changes the comparison baseline.
## Every metric, defined
Galantis Discount Flow records a small set of events per campaign and derives everything else from them:
| Metric | Definition |
| -------------------- | ------------------------------------------------------------------------------------ |
| Impressions | Times the campaign was evaluated and shown on the storefront. |
| Applications (Usage) | Times the discount was applied in checkout. |
| Conversions | Paid orders attributed to the campaign. |
| Revenue | Total value of attributed paid orders. Refunds and cancellations reduce this figure. |
| Refunded | Refunded and cancelled amounts, shown separately so you can see gross vs net. |
| Discount | Total discount amount given by the campaign. |
| Conversion rate | Conversions ÷ applications. |
| Discount ROI | Revenue ÷ discount given — how much revenue each unit of discount generated. |
Free-shipping-only campaigns don't report revenue columns, since the discount applies to delivery rather than product prices.
All money metrics are reported in your **store currency**, converted by Shopify. This includes orders placed in other checkout currencies and campaigns that use [per-currency amounts](/galantis/discount/rule-builder/currency-markets) — there is no per-currency breakdown.
## Charts
The Analytics page includes five visualizations for the selected period:
* **Revenue Trend** — revenue and refunds over time, plotted together.
* **Usage Trend** — discount applications over time.
* **Conversion Funnel** — impressions → applications → conversions, showing where customers drop off.
* **Campaign Distribution** — campaigns grouped by status.
* **Top Performers** — your highest-revenue campaigns.
## Campaign Performance table
The table at the bottom breaks results down per campaign with columns for **Campaign**, **Usage**, **Conv. Rate**, **Revenue**, **Discount**, **Refunded**, and **ROI**. Use it together with **Include archived** to compare retired campaigns against active ones.
## How attribution and refunds work
Orders are attributed back to the campaign automatically — you don't have to tag anything:
Every published campaign embeds an invisible marker in its Shopify discount. For code-based campaigns, the discount code itself identifies the campaign.
When an order is created and paid, Shopify notifies Galantis Discount Flow, which matches the marker (or code) to the campaign and records a conversion, the revenue, and the discount amount given.
When a refund is created or an order is cancelled, the attributed revenue is reduced and the refunded amount is shown separately — on the **Total Revenue** card, in the **Revenue Trend** chart, and in the **Refunded** column of the performance table.
Because refunds reduce revenue after the fact, numbers for a recent period can decrease slightly over time as returns come in. This is expected — it means your ROI figures stay honest.
## Exporting data
Click **Export CSV** on the Analytics page to download the data for the currently selected **Period** (and archived campaigns, if **Include archived** is checked). The export mirrors what you see on screen, so set your filters first.
## Related guides
* [How discounts apply at checkout](/galantis/discount/storefront/how-discounts-apply) — where applications and conversions actually happen
* [Plans & limits](/galantis/discount/billing/plans-limits) — how Free-plan usage caps relate to the numbers you see here
* [Troubleshooting](/galantis/discount/support/troubleshooting) — what to check when numbers look off
# Plans & limits
Source: https://docs.digifist.com/galantis/discount/billing/plans-limits
Free vs Pro in Galantis Discount Flow — campaign and usage limits, what happens when a Free shop hits its monthly cap, and how to change plans through Shopify.
Galantis Discount Flow has two plans: **Free** and **Pro**. Every feature is available on both plans except one — [per-currency amounts](/galantis/discount/rule-builder/currency-markets) require Pro. Beyond that, the difference is capacity: how many campaigns can be active at once, and how much monthly discount usage your store can run. Billing is handled entirely by Shopify.
## Plan comparison
| | Free | Pro |
| ----------------------------- | :---: | :----------------------------: |
| Active campaigns | 3 max | Unlimited |
| Discounted orders / month | 25 | Unmetered |
| Discount applications / month | 1,000 | Unmetered |
| Per-currency amounts | — | Included |
| All other features | All | All |
| Billing | — | Monthly or annual, via Shopify |
Per-currency amounts are the only feature gated to Pro. Otherwise, Free and Pro shops use the same campaign builder, discount types, analytics, and storefront embed — Pro removes the caps. On the Free plan, the **Set a different amount per currency** checkbox in the Rule Builder is disabled with a **Pro** badge and an **Upgrade** button, and saving or activating a campaign with per-currency amounts is rejected: "Per-currency amounts require the Pro plan. Remove them or upgrade to Pro to save this campaign."
## Free plan limits
The Free plan has one structural limit and two monthly usage caps:
* **3 active campaigns** — you can create as many campaigns as you like, but at most 3 can be active at the same time. Trying to activate a fourth shows: "FREE plan allows a maximum of 3 active campaigns. Upgrade to activate more."
* **25 discounted orders per month** — orders where a Galantis Discount Flow discount was applied.
* **1,000 discount applications per month** — times a discount was applied in checkout.
### The monthly period
Usage caps reset on a monthly period **anchored to your install date**, not the calendar month. If you installed on the 14th, each usage period runs from the 14th to the 13th of the following month.
### What happens when you hit a cap
When either cap is reached, all of the store's discounts are paused — campaigns stop applying at checkout for the rest of the period.
A usage-paused banner is shown on the dashboard so you know why discounts stopped.
At the start of the next monthly period, discounts reactivate on their own — no action needed. Upgrading to Pro lifts the pause **immediately** instead.
While usage is paused, customers see no Galantis Discount Flow discounts at checkout. If your campaigns drive meaningful revenue, treat the usage-paused banner as a prompt to upgrade rather than wait out the period.
## Pro plan
Pro removes all caps: unlimited active campaigns and unmetered usage. Pro is available as a monthly or an **annual** subscription.
## Changing your plan
In Galantis Discount Flow, go to **Settings**. The **Plan** card shows your current plan badge and notes that billing is handled securely by Shopify.
You're taken to a Shopify-hosted page where the subscription is managed. Confirm the change there — no payment details are ever entered in Galantis Discount Flow.
### Upgrade behavior
Upgrading to Pro takes effect right away. If your store was usage-paused on Free, the pause is lifted **immediately** and discounts start applying again.
### Downgrade behavior
Downgrading from Pro to Free re-applies the 3-active-campaign limit. If more than 3 campaigns are active at the time, campaigns beyond the limit are **auto-paused** — the oldest 3 are kept active. You can choose which 3 stay active by pausing and activating campaigns yourself afterwards.
Downgrading also automatically **pauses any active campaigns that use per-currency amounts**, since those require Pro. Each pause is recorded in the **Activity Log**. To reactivate such a campaign on Free, open it in the Rule Builder, untick **Set a different amount per currency** (this clears the per-currency rows), set a single amount, and activate it again. See [Multi-currency & Markets](/galantis/discount/rule-builder/currency-markets).
## Related guides
* [Settings](/galantis/discount/settings) — the Plan card and the Activity Log, where plan changes and usage events are recorded
* [Multi-currency & Markets](/galantis/discount/rule-builder/currency-markets) — the one Pro-gated feature, in full
* [Troubleshooting](/galantis/discount/support/troubleshooting) — the usage-paused banner and activation limit errors explained
# Combinations
Source: https://docs.digifist.com/galantis/discount/campaigns/combinations
How campaigns in Galantis Discount Flow stack with other discounts — the three combination classes and the best-discount rule on shared cart lines.
By default, a Shopify cart applies one discount at a time. The **Combinations** card in Galantis Discount Flow lets a campaign opt in to stacking with other discounts, using the same combination system Shopify applies to its native discounts.
Getting combinations right matters twice over: too restrictive and a customer's free-shipping code silently cancels your sale price; too permissive and discounts pile up beyond what you budgeted.
## The Combinations card
The card appears in step 3 of the creation wizard and on the campaign detail page. Under the heading **"This discount can be combined with:"** are three checkboxes:
* **Order discounts** — discounts applied to the whole order total
* **Product discounts** — discounts applied to specific products or cart lines
* **Shipping discounts** — free or reduced shipping
Each checkbox corresponds to one of Shopify's discount classes. Ticking a class means your campaign is willing to apply alongside discounts of that class — leaving all three unticked means the campaign never stacks with anything.
Combination is mutual. Your campaign stacks with another discount only when both sides allow the other's class — your settings alone can't force stacking with a discount that doesn't permit it.
## The best-discount rule on shared lines
There is one rule that combination settings cannot override: on the same cart line, **only the best product discount applies** among competing product discounts. Two product discounts can coexist in one cart — each applying to different lines — but where they both target the same line, the customer gets the better of the two, not both.
## Scenarios
A 20% storewide campaign runs alongside a free-shipping campaign for carts over 150.
Tick **Shipping discounts** on the percentage campaign and **Product discounts** on the free-shipping campaign. A qualifying cart then gets both: 20% off the products and free delivery. If either side leaves the other's class unticked, only one of the two applies.
A 30% end-of-season campaign covers your whole catalog, and a Buy 1 Get 1 Free campaign covers one collection — both allowing **Product discounts**.
On lines only the seasonal sale targets, 30% applies. On lines where both compete, the best-discount rule picks whichever benefits the customer more on that line — they never stack on the same line.
A deep 50% clearance campaign shouldn't combine with anything.
Leave all three checkboxes unticked. The clearance discount then applies on its own, and no order, product, or shipping discount joins it in the same cart.
A fixed 25-off order campaign (an order discount) allows **Product discounts**, and a 10% product campaign allows **Order discounts**.
Both apply to a qualifying cart: the product discount reduces line prices, and the order discount reduces the total. Different classes never compete under the best-discount rule — that rule only arbitrates between product discounts on the same line.
Review combinations before every major sale. Stacked discounts multiply quickly — a 30% campaign combining with a 20% order discount gives away far more margin than either does alone.
## Quick reference
| Setting | Effect |
| ----------------------------- | ------------------------------------------------------------------------------- |
| **Order discounts** ticked | Can apply together with order-level discounts |
| **Product discounts** ticked | Can apply together with product-level discounts (best one wins per shared line) |
| **Shipping discounts** ticked | Can apply together with shipping discounts |
| Nothing ticked | The campaign never stacks with any other discount |
## Related guides
* [Creating campaigns](/galantis/discount/campaigns/creating-campaigns) — where the Combinations card appears in the wizard
* [Managing campaigns](/galantis/discount/campaigns/managing-campaigns) — changing combinations on a live campaign
* [Campaigns overview](/galantis/discount/campaigns/index) — how campaigns map to Shopify discounts
# Creating Campaigns
Source: https://docs.digifist.com/galantis/discount/campaigns/creating-campaigns
The 3-step campaign wizard in Galantis Discount Flow — choose a template, build the discount logic, then schedule and publish.
New campaigns are created through a 3-step wizard: **Choose Template**, **Details**, and **Publish**. The wizard takes you from a blank canvas (or a ready-made template) to a live Shopify discount in a few minutes, and validation at each step ensures you can't publish a flow that doesn't work.
To start, open **Campaigns** and click **Create Campaign**.
## The wizard, step by step
The first step shows the template gallery — six ready-made campaign types covering the most common discount patterns. Selecting one prefills the campaign name and the entire discount flow, and everything stays editable in the next step.
Prefer a blank canvas? Click **Start from scratch** below the gallery to begin with an empty flow.
See [Templates](/galantis/discount/campaigns/templates) for what each template contains.
This step combines the campaign's identity with its logic:
* **Campaign Name** — required. The field shows the placeholder "e.g. Summer Sale 20%". Names must be unique across your campaigns.
* **Rule Builder** — the visual canvas where you build the discount flow: the conditions a cart must meet and the discount action that applies when it does.
If you started from a template, a badge shows which template is in use, with a **Change template** option to go back and pick another.
You cannot advance past this step until the flow has a working action. Validation errors appear when you click **Next**, so a blank starter canvas won't show errors before you've built anything.
The final step holds two cards:
* **Active dates** — the start date and time (defaults to now, in your store's timezone) and an optional **Set end date** checkbox. See [Scheduling](/galantis/discount/campaigns/scheduling).
* **Combinations** — checkboxes controlling which other discount classes this campaign can stack with. See [Combinations](/galantis/discount/campaigns/combinations).
The footer offers two ways to finish:
* **Save as draft** — stores the campaign without publishing. No discount is created in Shopify.
* **Create Campaign** — publishes the campaign to Shopify as a live (or scheduled) discount.
## Draft or publish?
| | Save as draft | Create Campaign |
| ------------------------------------ | ------------- | ------------------------------------------------------ |
| Status after saving | **Draft** | **Active** (or **Scheduled** with a future start date) |
| Discount created in Shopify | No | Yes |
| Counts toward active-campaign limits | No | Yes |
| Flow must be valid | Yes | Yes |
Draft early, publish late. A draft lets you build and refine a flow over several sessions without touching your live store — then publish from the campaign detail page when the promotion is ready.
## Publish-time limit checks
Publishing runs two checks that drafting does not:
**Free plan limit** — on the Free plan, at most **3 campaigns** can be active at once. Publishing a fourth is blocked until you pause or archive another campaign, or upgrade your plan.
**Shopify's automatic discount limit** — Shopify allows at most 25 active automatic discounts per store, across all apps and native discounts. If publishing would exceed it, you'll see the message "A store can have at most 25 active automatic discounts." Campaigns with a **Discount code** condition publish as code-based discounts and do not count toward this limit.
If a limit blocks publishing, the campaign is not lost — save it as a draft and publish once there's room.
## Automatic or code-based?
The wizard decides this from your flow, not from a separate setting. A flow with a **Discount code** condition publishes as a code-based discount that customers redeem at checkout; any other flow publishes as an automatic discount that applies on its own.
## Related guides
* [Templates](/galantis/discount/campaigns/templates) — what each of the six templates prefills
* [Scheduling](/galantis/discount/campaigns/scheduling) — start dates, end dates, and timezone behavior
* [Combinations](/galantis/discount/campaigns/combinations) — stacking rules to set before you publish
* [Managing campaigns](/galantis/discount/campaigns/managing-campaigns) — editing and controlling campaigns after creation
# Campaigns
Source: https://docs.digifist.com/galantis/discount/campaigns/index
Discount flows built in the visual Rule Builder and published to Shopify as real discounts — with a full lifecycle from draft to archive.
A campaign is a discount flow you build in the visual Rule Builder of Galantis Discount Flow and publish to Shopify as a real, working discount. Every percentage deal, free-shipping threshold, BOGO offer, and loyalty reward runs through a campaign — one place to design the logic, schedule the window, and track the results.
Once published, a campaign is not a simulation. It is applied at checkout by a discount Function and appears on Shopify's own Discounts page alongside any discounts you created natively.
## How campaigns become Shopify discounts
When you publish a campaign, Galantis Discount Flow creates a matching discount in Shopify:
* **Automatic discounts** — the default. The discount applies on its own whenever a cart meets the flow's conditions; customers never enter a code.
* **Code-based discounts** — created when your flow contains a **Discount code** condition. Customers must enter the code at checkout for the flow to apply.
Published campaigns are visible on Shopify's native **Discounts** page. Clicking one there opens the campaign in Galantis Discount Flow, so the app stays the single place where the discount is edited.
## The campaign lifecycle
Every campaign carries a status that describes where it is in its lifecycle. The Campaigns list groups campaigns into tabs by these same statuses.
| Status | Meaning | How a campaign gets there |
| ------------- | ------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| **Active** | The discount is live and applying at checkout | Published with a start date of now or earlier, or activated from the list or detail page |
| **Scheduled** | Published, but the start date is in the future | Published with a future start date in the **Active dates** card |
| **Draft** | Saved but never published — no discount exists in Shopify yet | Created with **Save as draft** in the wizard |
| **Paused** | Temporarily stopped; the discount no longer applies | Paused manually, or paused automatically when a Free plan usage cap is reached |
| **Ended** | The campaign's end date has passed | The optional end date in **Active dates** is reached |
| **Archived** | Removed from Shopify, kept in the app with its analytics | Archived from the detail page or via a bulk action |
Archiving removes the live discount from Shopify but preserves all analytics. Restoring an archived campaign brings it back as **Paused**, so you can review it before reactivating.
## Where to go next
The 3-step wizard — templates, the Rule Builder, and publishing.
The Campaigns list, bulk actions, and the campaign detail page.
Start and end dates, timezones, and the Scheduled and Ended statuses.
How campaigns stack with order, product, and shipping discounts.
Six ready-made starting points, from Percentage Discount to Loyal Customer Reward.
## Limits to know about
Two limits apply when publishing campaigns:
* On the **Free plan**, a maximum of **3 campaigns** can be active at once. The Free plan also has monthly usage caps — when reached, all discounts pause until the next monthly period or an upgrade.
* Shopify allows at most **25 active automatic discounts** per store, across all apps and native discounts. Code-based campaigns do not count toward this limit.
Both limits are checked at publish time — see [Creating campaigns](/galantis/discount/campaigns/creating-campaigns) for the exact behavior.
## Related guides
* [Creating campaigns](/galantis/discount/campaigns/creating-campaigns) — the full 3-step wizard walkthrough
* [Managing campaigns](/galantis/discount/campaigns/managing-campaigns) — statuses in practice: pause, archive, restore
* [Templates](/galantis/discount/campaigns/templates) — the fastest way to a first campaign
# Managing Campaigns
Source: https://docs.digifist.com/galantis/discount/campaigns/managing-campaigns
The Campaigns list and detail page in Galantis Discount Flow — status tabs, performance columns, bulk actions, pause and archive semantics, and sync recovery.
The Campaigns page is the control room of Galantis Discount Flow: every campaign, its status, its schedule, and its performance in one sortable table. From here you can activate, pause, or archive campaigns in bulk, or open any campaign to edit its details.
Day-to-day management happens in two places — the list for overview and bulk work, and the campaign detail page for everything specific to one campaign.
## The Campaigns list
### Summary bar
Above the table, four tiles summarize your whole campaign portfolio:
* **Total campaigns** — with a breakdown of drafts and ended campaigns
* **Active** — with scheduled and paused counts alongside
* **Total usage** — the total number of discounts applied
* **Total revenue** — with the refunded amount alongside
### Tabs and search
Campaigns are grouped into status tabs, each showing its count: **All**, **Active**, **Scheduled**, **Draft**, **Paused**, **Ended**, and **Archived**. Use the search field to filter by campaign name within the current tab.
### Columns
| Column | What it shows |
| ---------------- | --------------------------------------------------- |
| **Name** | The campaign name; click a row to open the campaign |
| **Status** | The lifecycle status badge |
| **Schedule** | The active-dates window, in your store's timezone |
| **Impressions** | How often the campaign was seen |
| **Applications** | How often the discount was applied |
| **Conversions** | Orders that used the discount |
| **Revenue** | Revenue from converting orders |
| **Discount** | The total amount discounted |
| **Refunded** | Refunded revenue |
| **Refunds** | The refund rate on converting orders |
Metric columns are sortable. Campaigns that only give free shipping show "—" in the revenue-related columns, since there is no discounted product revenue to attribute.
### Bulk actions
Select one or more campaigns to reveal bulk actions, each confirmed in a modal before anything changes:
* **Activate** — the selected campaigns' discounts go live for eligible customers
* **Pause** — their discounts stop applying until re-activated
* **Archive** — their live discounts are removed from Shopify; analytics are kept
On the **Archived** tab, the bulk action is **Restore** instead. Restored campaigns return as **Paused**, and any campaign whose name has since been taken is automatically renamed to avoid a duplicate.
On the Free plan, when the monthly usage cap is reached (25 discounted orders or 1,000 applications), all discounts are paused until the next monthly period or an upgrade — and a banner appears on both the Dashboard and the Campaigns list.
## The campaign detail page
Clicking a campaign opens its detail page, titled with the campaign name and its status badge. The header offers:
* A **Pause** or **Activate** button, depending on whether the campaign is currently published
* A **More actions** menu containing **Archive**
For an archived campaign, the header instead shows a single **Restore** action, and an informational card notes when the campaign was archived and that its analytics are preserved.
Below the header, the page stacks:
* **Performance** — the campaign's **Usage** and **Revenue** at a glance
* **Campaign Details** — the **Campaign Name** field
* **Active dates** — the schedule (see [Scheduling](/galantis/discount/campaigns/scheduling))
* **Rule Builder** — the full discount flow, editable in place
* **Combinations** — stacking settings (see [Combinations](/galantis/discount/campaigns/combinations))
### Editing with the save bar
Any change to the name, dates, flow, or combinations activates a save bar with **Save** and **Cancel**. The page tracks unsaved changes, so you can't navigate away and silently lose an edit — save to apply everything at once, or cancel to revert to the last saved state.
### Archive and restore semantics
Archiving is the safe way to retire a campaign:
* The live discount is **removed from Shopify**, so it immediately stops applying
* All analytics are **preserved** — the campaign stays visible on the Archived tab
* **Restore** brings it back as **Paused**, ready to review and re-activate; if the name was reused in the meantime, the restored campaign is automatically renamed
Pause when a promotion might come back soon; archive when it's over. Both stop the discount, but archiving also removes it from Shopify's Discounts page and moves it out of your working tabs.
### Sync errors and Resync
If the last sync of a campaign to Shopify failed, a sync error banner appears at the top of the detail page explaining the failure. Click **Resync** to queue a fresh sync attempt. While a sync is running, the banner shows the in-progress state instead.
## Related guides
* [Creating campaigns](/galantis/discount/campaigns/creating-campaigns) — the 3-step wizard
* [Scheduling](/galantis/discount/campaigns/scheduling) — how Scheduled and Ended statuses work
* [Campaigns overview](/galantis/discount/campaigns/index) — the full status lifecycle reference
# Scheduling
Source: https://docs.digifist.com/galantis/discount/campaigns/scheduling
The Active dates card in Galantis Discount Flow — start and end times in your store's timezone, and how the Scheduled and Ended statuses work.
Every campaign in Galantis Discount Flow has an **Active dates** card that controls when its discount runs. Set a start in the future and the campaign publishes as **Scheduled**, going live on its own at the right moment; add an end date and it winds down automatically as **Ended** — no midnight logins required.
The card appears in step 3 of the creation wizard and on every campaign detail page, so schedules can be adjusted at any time.
## The Active dates card
* **Start date** and **Start time** — when the discount begins applying. Defaults to now, so a freshly published campaign is live immediately unless you change it.
* **Set end date** — an optional checkbox. Tick it to reveal **End date** and **End time** fields; leave it unticked and the campaign runs indefinitely until you pause, end, or archive it.
Two validation rules apply to the end:
* The end must be **after the start**
* The end cannot be **in the past**
If either rule is broken, an inline error appears on the end fields and the campaign can't be saved until it's fixed.
## Everything runs on store time
All dates and times are entered in your **store's timezone** — the one configured in your Shopify settings, not your laptop's clock or UTC. As a reminder, the store's UTC offset is shown right next to the time inputs (for example, **Start time (UTC+02:00)**).
If you manage a store from another timezone, trust the offset shown next to the field. A "9:00 PM launch" means 9:00 PM where your store lives.
## How schedules map to statuses
| Schedule | Status | What happens |
| -------------------------------- | ------------- | ------------------------------------------------------------------- |
| Start now (default), no end date | **Active** | Live immediately, runs until you stop it |
| Start in the future | **Scheduled** | Published to Shopify but dormant; flips to Active at the start time |
| End date reached | **Ended** | The discount stops applying; the campaign moves to the Ended tab |
A **Scheduled** campaign is a real published discount — it counts toward active-campaign limits and appears on Shopify's Discounts page — it simply hasn't started applying yet. An **Ended** campaign keeps all its analytics and can be relaunched by updating its dates and activating it again.
## Scheduling patterns
Set both a start and an end a few hours apart — for example, Friday 18:00 to Friday 23:59 store time. Publish in advance as **Scheduled**; the sale starts and stops on its own, with no one on call to flip switches.
For a multi-week promotion like an end-of-season sale, set the start to the season's first day and tick **Set end date** for its last. Pair with the [End of Season template](/galantis/discount/campaigns/templates) for a ready-made flow.
Leave **Set end date** unticked for offers that should always be on, such as a permanent free-shipping threshold. The campaign runs until you pause or archive it.
Build and publish a campaign days ahead with a future start date. It sits safely in **Scheduled** — visible, reviewable, and editable — until launch time.
Schedule big promotions as far ahead as you like. Scheduled campaigns can still be edited freely — name, flow, dates, and combinations — right up until they go live.
## Related guides
* [Creating campaigns](/galantis/discount/campaigns/creating-campaigns) — where Active dates fits in the wizard
* [Managing campaigns](/galantis/discount/campaigns/managing-campaigns) — pausing and archiving as manual alternatives to end dates
* [Campaigns overview](/galantis/discount/campaigns/index) — the full status lifecycle
# Templates
Source: https://docs.digifist.com/galantis/discount/campaigns/templates
The six ready-made campaign templates in Galantis Discount Flow — what each one prefills and how to customize it after selecting.
Templates are ready-made campaigns covering the six most common discount patterns in e-commerce. Selecting one in the first step of the wizard prefills the campaign name and the entire Rule Builder flow, so a working promotion is one click away — and every part of it remains editable.
Templates are starting points, not constraints. Swap the amounts, tighten the conditions, extend the flow — the result is an ordinary campaign like any built from scratch.
## The template gallery
The gallery is step 1 of the creation wizard (**Campaigns** → **Create Campaign**). Each template shows its name, a short description, and a category badge; below the grid, **Start from scratch** begins with an empty canvas instead.
## The six templates
**Popular** — "Apply a specific percentage discount to the entire cart." Prefills a flat 10% off the whole cart.
**Popular** — "Free shipping on orders above the minimum amount." Prefills free shipping when the cart total reaches 150.
**Popular** — "Deduct a fixed amount from the cart." Prefills 25 off when the cart total reaches 100.
**Growth** — "Buy one get one free on selected products." Prefills a BOGO flow for products you select.
**Seasonal** — "Big end-of-season discount campaign." Prefills a 30% discount for clearing out a season's stock.
**Retention** — "Special discount for customers who exceed a certain order count." Prefills 50 off for customers with more than 5 orders.
All template amounts are in your store's own currency — the "25 off" in Fixed Amount Discount means 25 of whatever your store sells in.
## At a glance
| Template | Category | Prefilled flow |
| --------------------- | --------- | ------------------------------------------------ |
| Percentage Discount | Popular | Flat 10% off the entire cart |
| Free Shipping | Popular | Free shipping when the cart total is 150 or more |
| Fixed Amount Discount | Popular | 25 off when the cart total is 100 or more |
| Buy 1 Get 1 Free | Growth | Buy one, get one free on selected products |
| End of Season | Seasonal | 30% off for a seasonal clearance |
| Loyal Customer Reward | Retention | 50 off after more than 5 orders |
## Customizing after selecting
Selecting a template jumps you to step 2 of the wizard with everything prefilled:
The **Campaign Name** field is prefilled with the template's name. Replace it with something specific — "Summer Sale 20%" tells you more in the Campaigns list than "Percentage Discount".
Change the discount value, raise or lower thresholds, pick different products, or add further conditions — such as a **Discount code** condition to make the campaign code-based. The template's flow is fully editable, and a badge above the canvas shows which template you started from, with a **Change template** option to pick another.
Continue to step 3 to set [Active dates](/galantis/discount/campaigns/scheduling) and [Combinations](/galantis/discount/campaigns/combinations), then **Create Campaign** to publish or **Save as draft** to keep working later.
Templates pair naturally with schedules: start End of Season with a seasonal end date, or run Loyal Customer Reward with no end date as an evergreen retention offer.
## Related guides
* [Creating campaigns](/galantis/discount/campaigns/creating-campaigns) — the full 3-step wizard walkthrough
* [Scheduling](/galantis/discount/campaigns/scheduling) — putting a time window around a templated campaign
* [Combinations](/galantis/discount/campaigns/combinations) — how a templated campaign stacks with your other discounts
# Create your first campaign
Source: https://docs.digifist.com/galantis/discount/getting-started/first-campaign
A full walkthrough of the 3-step campaign wizard using the Percentage Discount template — from template pick to a live discount at checkout.
Every campaign in Galantis Discount Flow is created in the same 3-step wizard: pick a starting point, shape the logic in the Rule Builder, then schedule and publish. This guide walks the whole wizard end to end using the **Percentage Discount** template — the simplest of the 6 starter templates and the fastest way to see a real discount at checkout.
The wizard's footer keeps you oriented throughout: **Next** moves you forward, **Back** returns to the previous step, and the final step offers **Save as draft** or **Create Campaign**.
## Before you start
Open **Campaigns** in the app navigation and click the button to create a new campaign. You'll land on step 1 of the wizard.
On the **Free plan** you can have up to **3 active campaigns** at a time. Drafts don't count against this limit, so you can prepare as many campaigns as you like and activate them as slots free up — or upgrade to Pro for unlimited campaigns via **Settings → Change plan**.
## The 3-step wizard
Step 1 shows the template gallery with 6 starter templates — **Percentage Discount**, **Free Shipping**, **Buy 1 Get 1 Free**, **Fixed Amount Discount**, **End of Season**, and **Loyal Customer Reward** — plus a **Start from scratch** tile for a blank canvas.
Select **Percentage Discount**. The wizard pre-fills the campaign name and loads a ready-made flow into the Rule Builder, then moves you to step 2. You can change your mind later with **Change template**.
Step 2 is where the campaign takes shape:
* **Campaign Name** — pre-filled from the template; rename it to something you'll recognize in lists and analytics, like "Summer 10% off".
* **Rule Builder** — the visual canvas. The Percentage Discount template gives you a minimal flow ending in a **Percentage off** action. Open the action node to set the **Discount title** (what customers see) and the **Percentage**.
Want the discount to be conditional? Add condition nodes such as **Cart total** or **Customer tag**, combine them with **AND**/**OR**/**NOT** gates, and wire them into the flow. For your first campaign, the template's defaults are enough — click **Next**.
Step 3 handles scheduling and stacking:
* **Active dates** — pick a **Start date**, and optionally toggle **Set end date** for a fixed end. Times use your store timezone. A campaign with no end date runs until you deactivate it.
* **Combinations** — choose which Shopify discount classes this campaign can combine with: order, product, and shipping discounts. This mirrors Shopify's native combination rules.
Finish with one of the two footer buttons:
* **Create Campaign** — publishes the flow to Shopify as a real discount. It becomes active according to its start date.
* **Save as draft** — stores the campaign without publishing, so you can come back and finish it later. Drafts don't count toward the Free plan's active-campaign limit.
## Where your campaign appears
After publishing, the campaign shows up in two places:
| Location | What you'll see |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| **Campaigns** list in Galantis Discount Flow | The campaign with its status, where you can edit, deactivate, or review it. |
| **Shopify's native Discounts page** | The published discount as a real Shopify discount — proof that nothing lives only inside the app. |
Because your Percentage Discount flow contains no **Discount code** condition, it publishes as an **automatic discount** — customers get it at checkout with no code to type. Add a **Discount code** condition and the campaign becomes a code-based discount instead.
Shopify allows a maximum of **25 active automatic discounts per store**. Code-based campaigns don't count toward this Shopify limit, so heavy users often mix both types.
## Related guides
* [Storefront setup](/galantis/discount/getting-started/storefront-setup)
* [Rule Builder overview](/galantis/discount/rule-builder/index)
* [Campaign templates](/galantis/discount/campaigns/templates)
* [Analytics](/galantis/discount/analytics/index)
# Getting Started
Source: https://docs.digifist.com/galantis/discount/getting-started/index
Go from a fresh Shopify store to a live discount campaign — install the app, pick a plan, build your first campaign, and enable the theme app embed.
Galantis Discount Flow lives inside your Shopify admin, so getting started is short: install from the Shopify App Store, select a plan, and build your first campaign in the 3-step wizard. Most merchants go from install to a published campaign in a single sitting.
There is one storefront step that's easy to miss: enabling the **Galantis Discount Flow** theme app embed. Price discounts are applied at checkout either way, but free-gift auto-add and storefront signals only work with the embed switched on.
Plan selection is part of the install flow — even the **\$0 Free plan** must be actively selected on Shopify's plan-selection page before you land on the Dashboard. Every feature is available on every plan; plans differ only by limits.
## The journey
Install Galantis Discount Flow from the Shopify App Store and approve the permissions Shopify shows. The app syncs your shop's currency, locale, and timezone automatically. See [Installation](/galantis/discount/getting-started/installation).
If you've never selected a plan, Shopify redirects you to its hosted plan-selection page. Choose **Free** (up to 3 active campaigns with monthly usage caps) or **Pro** (unlimited campaigns, unmetered usage), then land on the Dashboard.
Use the 3-step wizard: pick a template or **Start from scratch**, name the campaign and shape it in the Rule Builder, then set active dates and combinations. Finish with **Save as draft** or **Create Campaign**. See [Your first campaign](/galantis/discount/getting-started/first-campaign).
In the Shopify theme editor, switch on the **Galantis Discount Flow** app embed so free gifts are auto-added on the storefront and customers see discount signals. See [Storefront setup](/galantis/discount/getting-started/storefront-setup).
## The guides in this section
The install flow, what each permission is for, the plan-selection redirect, and what happens right after install.
A full walkthrough of the 3-step wizard using the Percentage Discount template, from template pick to published discount.
Enable the theme app embed and understand each embed setting — and when the embed is required versus optional.
## Where everything lives
After setup, you'll work from four areas in the app's navigation:
| Area | What it's for |
| ------------- | ------------------------------------------------------------------------------------------------------- |
| **Home** | The dashboard — your starting point after install, with an overview of campaign performance. |
| **Campaigns** | Create, edit, and manage campaigns; published campaigns also appear on Shopify's native Discounts page. |
| **Analytics** | Revenue, usage, conversion rate, ROI, refund tracking, and CSV export. |
| **Settings** | Plan management (**Change plan**) and app configuration. |
## Related guides
* [Installation](/galantis/discount/getting-started/installation)
* [Your first campaign](/galantis/discount/getting-started/first-campaign)
* [Storefront setup](/galantis/discount/getting-started/storefront-setup)
* [Campaigns overview](/galantis/discount/campaigns/index)
# Installation
Source: https://docs.digifist.com/galantis/discount/getting-started/installation
Install Galantis Discount Flow from the Shopify App Store, review the requested permissions, select a plan, and land on the Dashboard.
Galantis Discount Flow installs like any public Shopify app: open the listing, review permissions, approve, and you're redirected into the app inside your Shopify admin. The one extra step is plan selection — every merchant picks a plan (including the \$0 Free plan) before reaching the Dashboard.
The whole flow usually takes a couple of minutes. There is no separate account to create; the app runs entirely inside Shopify, and billing is handled by Shopify.
## The install flow
Find Galantis Discount Flow in the Shopify App Store and click install. Sign in to the Shopify account that owns the store you want to install on.
Shopify shows the access the app requests: read discounts, read locales, read orders, read products, and write discounts. Each scope powers a specific part of the app — see [What each permission is for](#what-each-permission-is-for) below.
If you've never selected a plan for this store, Shopify redirects you to its hosted plan-selection page. You must pick a plan to continue — **even the \$0 Free plan must be actively selected**. Free gives you up to 3 active campaigns with monthly usage caps; Pro is unlimited. You can switch later under **Settings → Change plan**.
Once a plan is selected, you land on the Galantis Discount Flow Dashboard inside your Shopify admin, ready to create your first campaign.
## What each permission is for
**Read and write discounts** — The core of the app. When you publish a campaign, Galantis Discount Flow creates a real automatic or code-based discount in Shopify; reading discounts keeps the app in sync with what's live on Shopify's native Discounts page.
**Read orders** — Powers Analytics (revenue, usage, conversion rate, ROI, refund tracking) and order-history conditions in the Rule Builder such as **Order count** and **First order**.
**Read products** — Lets you pick products and collections in Rule Builder conditions and actions, such as **Specific products**, **Free gift**, and **Bundle discount**.
**Read locales** — Used together with your shop settings to sync currency, locale, and timezone, so amounts and schedules display correctly for your store.
All five scopes are required for the app to work end to end. Shopify presents them together during install; there is no partial-install path.
## What happens right after install
As soon as the install completes, Galantis Discount Flow syncs your **shop currency, locale, and timezone**. This means:
* Discount amounts in the Rule Builder are shown in your store currency.
* Campaign **Active dates** are scheduled in your store timezone — a campaign that starts "at midnight" starts at midnight for your store, not UTC.
* Your Free-plan usage period (if applicable) is anchored to your install date and resets monthly from that anchor.
No further configuration is needed before creating a campaign. The one remaining setup task is the storefront: enabling the theme app embed, covered in [Storefront setup](/galantis/discount/getting-started/storefront-setup).
## Uninstalling and the 48-hour grace window
To uninstall, go to **Settings → Apps and sales channels** in your Shopify admin, find Galantis Discount Flow, and click **Uninstall**. Shopify revokes the granted permissions automatically.
Uninstalling starts a **48-hour grace window**. If you reinstall within 48 hours, your campaigns are restored automatically. After 48 hours, your data is deleted and cannot be recovered — you would start from a clean install.
***
Walk through the 3-step wizard with the Percentage Discount template — the natural next step after installing.
Enable the theme app embed so free-gift auto-add and storefront signals work on your store.
# Storefront setup
Source: https://docs.digifist.com/galantis/discount/getting-started/storefront-setup
Enable the Galantis Discount Flow theme app embed so free gifts are auto-added to the cart and customers see discount signals on your storefront.
Galantis Discount Flow does its pricing work at checkout through a Shopify discount Function — that part needs no theme changes at all. The storefront side is different: auto-adding free-gift items to the cart and showing customer-facing signals is handled by a theme app embed, and Shopify requires you to switch app embeds on yourself.
Enabling it takes under a minute in the theme editor, and there is no theme code to touch.
Without the embed enabled, **Free gift auto-add and storefront signals do not work** — a Free gift campaign can't place the gift in the cart, and customers get no on-page cues. Price discounts (percentage, fixed amount, shipping, and so on) are still applied at checkout by the discount Function regardless.
## Enable the theme app embed
In your Shopify admin, go to **Online Store → Themes** and click **Customize** on your live theme.
In the theme editor's left sidebar, select **App embeds**.
Find the **Galantis Discount Flow** embed in the list and toggle it on. Adjust its settings if needed — each one is explained below.
Click **Save** in the theme editor. The embed is now live on your storefront.
## Embed settings explained
**Default: on.** The master switch for all storefront behavior. Turn it off to pause everything the embed does — free-gift auto-add and storefront signals — without uninstalling the app. Checkout pricing is unaffected either way.
**Default: off.** Intended for troubleshooting during setup. Leave it off in normal operation; switch it on only when you're investigating storefront behavior with support.
**Default: on.** When a customer's cart qualifies for a **Free gift** campaign, the embed automatically adds the gift item to the cart. Turn this off if you don't want gifts added automatically — but note that Free gift campaigns rely on this behavior to deliver the gift.
**Default: on.** Displays a storefront notification the moment a free gift lands in the cart, so customers understand why a new item appeared. Turn it off for a silent auto-add.
**Default: "Your free gift has been added to your cart 🎁".** The message shown by the notification above. Edit it to match your brand voice or language.
## When the embed is required — and when it isn't
| Scenario | Embed required? |
| -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- |
| Percentage off, Fixed amount off, Free shipping, Buy X get Y, Tiered discount, Bundle discount, Volume pricing | No — applied at checkout by the discount Function |
| **Free gift** campaigns (auto-adding the gift to the cart) | **Yes** |
| Storefront signals and free-gift notifications | **Yes** |
Even if you only run price discounts today, enable the embed anyway. It costs nothing, and your first Free gift campaign will work on day one instead of failing quietly because the embed was never switched on.
## Related guides
* [Your first campaign](/galantis/discount/getting-started/first-campaign)
* [How discounts apply at checkout](/galantis/discount/storefront/how-discounts-apply)
* [Rule Builder actions](/galantis/discount/rule-builder/actions)
# Introduction
Source: https://docs.digifist.com/galantis/discount/index
Build, publish, and measure Shopify discount campaigns with a visual Rule Builder — 8 discount types, 11 conditions, scheduling, analytics, and storefront free-gift automation.
## What is Galantis Discount Flow?
Galantis Discount Flow is an embedded Shopify admin app for creating, managing, and measuring discount campaigns. Instead of wrestling with Shopify's fixed discount forms, you build each campaign in a visual node-graph **Rule Builder** — connect conditions, logic gates, and actions on a canvas — and the app publishes it to Shopify as a real automatic or code-based discount.
Under the hood, a Shopify discount Function applies your rules at checkout, so discounts work everywhere Shopify checkout works. A lightweight theme app embed handles storefront behavior, such as auto-adding free gifts to the cart and showing customer-facing signals. Every campaign you publish also appears on Shopify's native Discounts page, so nothing lives in a silo.
## What you can do with Galantis Discount Flow
Create discount campaigns in a 3-step wizard, save drafts, schedule active dates, and manage everything from a single Campaigns list.
Compose discount logic visually: 11 conditions, AND/OR/NOT logic gates, and actions connected on a node-graph canvas.
Percentage off, Fixed amount off, Free shipping, Buy X get Y, Tiered discount, Free gift, Bundle discount, and Volume pricing.
Track revenue, usage, conversion rate, and ROI per campaign, with refund tracking and CSV export for deeper analysis.
A Shopify discount Function applies pricing at checkout; the theme app embed powers free-gift auto-add and storefront signals.
Start from 6 ready-made templates — from a simple Percentage Discount to a Loyal Customer Reward — and customize from there.
## Who it's built for
Galantis Discount Flow is built for Shopify merchants whose promotions have outgrown the native discount forms.
**Merchants running layered promotions** who need conditions like cart total, customer tags, order history, or day of week combined with AND/OR/NOT logic. **Stores that use gifting and bundling** — free gifts auto-added to the cart, bundle pricing, and volume tiers that native discounts don't cover in one place. **Teams that measure everything**, who want revenue, conversion, and ROI per campaign instead of a bare usage count. **Merchants of any size** — every feature is available on every plan, including the Free plan, so you can start small and upgrade only when your volume demands it.
## How it works
You build a campaign in the admin's visual Rule Builder: conditions (such as **Cart total** or **Customer tag**) flow through logic gates into an action (such as **Percentage off** or **Free gift**). When you click **Create Campaign**, Galantis Discount Flow publishes the flow to Shopify as a real discount — automatic by default, or code-based if your flow includes a **Discount code** condition.
At checkout, a Shopify discount Function evaluates your rules against the live cart and applies the pricing. The app is Shopify Markets-aware: if your store sells in multiple currencies, money fields can hold a [different amount per currency](/galantis/discount/rule-builder/currency-markets), applied in the customer's checkout currency. On the storefront, the theme app embed takes care of behavior that happens before checkout: automatically adding free-gift items to the cart and showing UI signals to the customer. The dashboard and Analytics then close the loop with revenue, usage, conversion rate, ROI, and refund tracking, while the Activity Log keeps a record of what changed and when.
## Ready to get started?
Install the app from the Shopify App Store, pick a plan, create your first campaign, and enable the theme app embed.
# Actions & discount types
Source: https://docs.digifist.com/galantis/discount/rule-builder/actions
The eight action blocks in Galantis Discount Flow — percentage, fixed amount, free shipping, Buy X get Y, tiered, free gift, bundle, and volume discounts.
Actions are the payoff of a flow: whichever action blocks the cart reaches are the discounts that apply at checkout. Galantis Discount Flow offers eight action types, covering everything from a simple percentage off to quantity-based volume pricing. A flow needs at least one valid, reachable action before it can be saved or published.
Every action shares one field: **Discount title**. This is the text your customer sees next to the discount at checkout, so write it for shoppers ("Summer sale — 15% off"), not for your internal records.
## The Apply to setting
Four actions — **Percentage off**, **Fixed amount off**, **Tiered discount**, and **Volume pricing** — include an **Apply to** choice that controls what the discount targets:
* **Entire order** — the discount reduces the order subtotal.
* **Only matched products** — the discount only reduces the cart lines matched by the flow's conditions, such as the items picked in a **Specific products** or **Specific collections** condition.
Choose **Only matched products** whenever the offer is about particular items ("20% off the Sale collection") so full-price products in the same cart stay full price.
## Available actions
### Percentage off
Applies a percentage discount.
| Field | Details |
| ----------------------- | --------------------------------------------- |
| **Discount title** | Shown at checkout |
| **Percentage** | 0–100% |
| **Max discount amount** | Optional cap, in your store's currency |
| **Apply to** | **Entire order** or **Only matched products** |
When the percentage would exceed the **Max discount amount**, the discount converts to that fixed cap — "10% off, up to 50" never takes more than 50 off, no matter how large the cart.
The **Max discount amount** supports a different cap per currency via **Set a different amount per currency** (Pro) — checkout currencies without an amount are uncapped. See [Multi-currency & Markets](/galantis/discount/rule-builder/currency-markets).
***
### Fixed amount off
Applies a fixed amount discount.
| Field | Details |
| ------------------ | --------------------------------------------- |
| **Discount title** | Shown at checkout |
| **Amount** | In your store's currency |
| **Apply to** | **Entire order** or **Only matched products** |
The **Amount** supports per-currency values via **Set a different amount per currency** (Pro) — checkout currencies without an amount get no discount from this action. See [Multi-currency & Markets](/galantis/discount/rule-builder/currency-markets).
***
### Tiered discount
Unlocks a percentage discount once the cart reaches a spend threshold.
| Field | Details |
| ------------------- | --------------------------------------------- |
| **Discount title** | Shown at checkout |
| **Spend threshold** | In your store's currency |
| **Discount** | 0–100% |
| **Apply to** | **Entire order** or **Only matched products** |
The **Spend threshold** supports per-currency values via **Set a different amount per currency** (Pro) — checkout currencies without an amount never unlock the discount. See [Multi-currency & Markets](/galantis/discount/rule-builder/currency-markets).
***
### Volume pricing
Grants bigger discounts at higher quantities.
| Field | Details |
| ------------------ | ----------------------------------------------------------------- |
| **Discount title** | Shown at checkout |
| **Quantity tiers** | A list of quantity-to-percent tiers (defaults: 5 → 10%, 10 → 20%) |
| **Apply to** | **Entire order** or **Only matched products** |
Each tier applies from its minimum quantity upward, so the highest tier the cart qualifies for wins.
### Buy X get Y
Buy a quantity, get another quantity at a discount.
| Field | Details |
| ------------------ | ------------------------------------------------- |
| **Discount title** | Shown at checkout |
| **Buy quantity** | Units the customer must buy |
| **Get quantity** | Units that receive the discount |
| **Get discount** | 0–100% off the "get" units |
| **Apply** | **Best item only** or **Each qualifying product** |
Buy X get Y works on the **same product**, and the discounted units must already be in the cart — Shopify checkout cannot add items. For "buy 2, get 1 free", the customer needs all 3 units of that product in the cart; the third is then discounted.
***
### Free gift
Gives a free gift product — added in the cart, discounted at checkout.
| Field | Details |
| ------------------ | ----------------------- |
| **Discount title** | Shown at checkout |
| **Gift products** | Shopify resource picker |
| **Quantity** | Gift units |
The gift is auto-added to the cart on the storefront by the theme embed, then discounted 100% at checkout. Shopify cannot add cart items at checkout, so the storefront handles the add.
Free gift requires the theme app embed to be enabled in your theme. Without it, nothing adds the gift to the cart, so there is nothing for checkout to discount.
***
### Bundle discount
Discounts a set of products when they are bought together.
| Field | Details |
| ------------------- | ----------------------- |
| **Discount title** | Shown at checkout |
| **Bundle products** | Shopify resource picker |
| **Bundle discount** | 0–100% |
The discount only applies when **all** selected products are in the cart together — one missing bundle item means no discount.
### Free shipping
Offers free shipping on the order's delivery options.
| Field | Details |
| ----------------------- | ---------------------------------------------------------- |
| **Discount title** | Shown at checkout |
| **Max shipping amount** | Optional cap on covered shipping, in your store's currency |
With a cap set, shipping is free up to that amount and the customer pays any remainder — useful for covering standard delivery without subsidizing express rates.
The **Max shipping amount** supports a different cap per currency via **Set a different amount per currency** (Pro) — checkout currencies without an amount are uncapped, so shipping is fully free. See [Multi-currency & Markets](/galantis/discount/rule-builder/currency-markets).
## Action reference
| Action | Key fields | Targets |
| ---------------- | --------------------------------------------------------------- | ------------------------- |
| Percentage off | **Percentage**, **Max discount amount**, **Apply to** | Order or matched products |
| Fixed amount off | **Amount**, **Apply to** | Order or matched products |
| Free shipping | **Max shipping amount** | Delivery options |
| Buy X get Y | **Buy quantity**, **Get quantity**, **Get discount**, **Apply** | Same product in the cart |
| Tiered discount | **Spend threshold**, **Discount**, **Apply to** | Order or matched products |
| Free gift | **Gift products**, **Quantity** | Gift product (100% off) |
| Bundle discount | **Bundle products**, **Bundle discount** | Bundle products together |
| Volume pricing | **Quantity tiers**, **Apply to** | Order or matched products |
## Related guides
* [Conditions](/galantis/discount/rule-builder/conditions) — Deciding which carts reach an action
* [Logic gates](/galantis/discount/rule-builder/logic-gates) — Combining conditions before the action fires
* [Multi-currency & Markets](/galantis/discount/rule-builder/currency-markets) — Setting a different amount per currency on money fields
* [Testing flows](/galantis/discount/rule-builder/testing-flows) — Verifying which actions fire before you publish
# Conditions
Source: https://docs.digifist.com/galantis/discount/rule-builder/conditions
The eleven condition blocks in Galantis Discount Flow — cart, customer, product, and time-and-place checks that decide who gets the discount.
Condition blocks are the targeting layer of a Galantis Discount Flow campaign. Each condition checks one fact about the cart, the customer, or the moment of purchase, then routes the flow through its **Then** output when the check passes or its **Otherwise** output when it fails. Chaining conditions — and combining them with [logic gates](/galantis/discount/rule-builder/logic-gates) — is how a flow narrows from "everyone" down to exactly the carts that should be discounted.
Eleven conditions are available, grouped below by what they look at. Conditions that compare a number share the same set of six operators.
## Operators
Numeric conditions — **Cart total**, **Item quantity**, and **Order count** — pair an operator with a value:
| Operator | Passes when |
| --------------------------- | ---------------------------------------- |
| is greater than | The value is strictly above your number |
| is greater than or equal to | The value is at or above your number |
| is less than | The value is strictly below your number |
| is less than or equal to | The value is at or below your number |
| equals | The value matches your number exactly |
| does not equal | The value is anything except your number |
## Available conditions
### Cart total
Checks the cart subtotal against an amount in your store's currency.
**Fields:** an operator plus an **Amount** field, prefixed with your store's own currency symbol.
This is the workhorse condition for spend thresholds — "carts over 100 get free shipping" starts with a Cart total block set to **is greater than** 100.
The **Amount** supports per-currency values via **Set a different amount per currency** (Pro) — for checkout currencies without an amount, the condition evaluates false. See [Multi-currency & Markets](/galantis/discount/rule-builder/currency-markets).
***
### Item quantity
Checks the number of items in the cart.
**Fields:** an operator plus a **Quantity** field.
Use it to gate offers behind a minimum basket size, or to route small carts to a different incentive than large ones.
### Customer tag
Checks whether the logged-in customer has a specific Shopify tag.
**Fields:** a **Customer tag** text field (for example, `vip`).
The tag must already exist on the customer in Shopify — the Rule Builder does not create tags. Only logged-in customers carrying the tag will match.
***
### Customer segment
Checks which segment the customer belongs to.
**Fields:** a **Segment** select with four options — **New customers**, **Returning customers**, **VIP**, and **Wholesale**.
Shopify checkout cannot read Shopify's native customer segments directly, so **VIP** and **Wholesale** are derived from the customer's tags and order count. This keeps segment matching consistent across the storefront and checkout.
***
### Order count
Checks the customer's past order count.
**Fields:** an operator plus an **Orders** field.
Useful for loyalty-style offers — for example, a reward that unlocks once a customer has placed at least five orders.
***
### First order
Passes when the customer is placing their first order. It has no fields to configure — connect its **Then** output to your first-purchase offer, or use its **Otherwise** output to target everyone except first-time buyers.
***
### Discount code
Passes when the customer has entered a specific discount code.
**Fields:** a **Code** text field (for example, `WELCOME10`).
Adding a Discount code condition changes the nature of the whole campaign: it becomes a code-based discount. Customers must enter the code at checkout for any part of the flow to apply — it no longer applies automatically.
### Specific products
Passes when the cart contains specific products.
**Fields:** a **Products** field that opens Shopify's resource picker, so you select items directly from your catalog.
***
### Specific collections
Passes when the cart contains items from selected collections.
**Fields:** a **Collections** field that opens Shopify's resource picker.
Collections are usually the better choice for broad merchandising rules ("anything from the Sale collection"), while Specific products suits narrow, hand-picked offers.
### Day of week
Keeps the flow active only on selected weekdays.
**Fields:** a **Days** multiselect covering Monday through Sunday.
Use it for weekend-only promotions or weekday flash offers without editing the campaign twice a week.
***
### Customer country
Matches the customer's shipping country.
**Fields:** a **Countries** multiselect. Available countries: United States, Canada, United Kingdom, Germany, France, Netherlands, Australia, and Turkiye.
Use it to restrict a promotion to specific markets — for example, free shipping only for domestic orders.
Conditions that look at the customer — **Customer tag**, **Customer segment**, **Order count**, and **First order** — require a logged-in customer. Guest shoppers cannot match them on the storefront or at checkout, so their flow follows the **Otherwise** path.
## Condition reference
| Condition | Checks | Fields |
| -------------------- | ------------------------------------- | -------------------------------------- |
| Cart total | Cart subtotal | Operator + **Amount** (store currency) |
| Item quantity | Number of items in the cart | Operator + **Quantity** |
| Customer tag | Shopify tag on the logged-in customer | **Customer tag** |
| Customer segment | New / Returning / VIP / Wholesale | **Segment** |
| Specific products | Cart contains selected products | **Products** (resource picker) |
| Specific collections | Cart contains items from collections | **Collections** (resource picker) |
| Order count | Customer's past order count | Operator + **Orders** |
| First order | Customer's first-ever order | None |
| Discount code | Customer entered a specific code | **Code** |
| Day of week | Current weekday | **Days** (multiselect) |
| Customer country | Shipping country | **Countries** (multiselect) |
## Related guides
* [Logic gates](/galantis/discount/rule-builder/logic-gates) — Combining conditions with AND, OR, and NOT
* [Actions & discount types](/galantis/discount/rule-builder/actions) — What happens when conditions pass
* [Multi-currency & Markets](/galantis/discount/rule-builder/currency-markets) — Per-currency amounts on the Cart total condition
* [Testing flows](/galantis/discount/rule-builder/testing-flows) — Simulating carts and customers against your conditions
# Multi-currency & Markets
Source: https://docs.digifist.com/galantis/discount/rule-builder/currency-markets
Per-currency amounts in Galantis Discount Flow — how Shopify Markets currencies reach the Rule Builder, the five money fields that support them, missing-currency behavior, and the Pro requirement.
If your store sells in more than one currency through Shopify Markets, a single number in a money field can mean very different things — "10 off" is a modest discount in USD and a much bigger one in JPY. Galantis Discount Flow solves this with **per-currency amounts**: five money fields in the Rule Builder can hold a different amount for each currency your store sells in, and at checkout the app uses the exact amount you entered for the customer's checkout currency.
## How Markets and currencies reach the app
Galantis Discount Flow is **Markets-aware**: it reads the presentment currencies your store has enabled — the currencies defined by your Shopify Markets setup — and offers them in the Rule Builder's currency dropdowns. The list always includes at least your store currency.
The currency list is read-only in Galantis Discount Flow. To add or remove currencies, configure them in Shopify Admin → **Settings → Markets** — the app picks up the changes when you navigate within it. Beyond currencies, there is no deeper Markets integration: the Rule Builder has no market condition and no market targeting.
## Two ways to enter an amount
Every per-currency-capable field works in one of two modes. In neither mode does the app convert between currencies — **no currency conversion ever happens**.
The default, and unchanged behavior. The number is applied literally in whatever currency the customer checks out in — a "10" fixed discount means 10 USD for a USD checkout and 10 EUR for a EUR checkout.
A separate amount per currency. At checkout, the app uses the exact amount you entered for the cart's checkout currency — 100 for USD carts, 90 for EUR carts, and so on.
Because single amounts are applied literally, they scale with the currency's face value, not its worth. A single "100" spend threshold is easy to reach in JPY and hard to reach in GBP. If your currencies differ meaningfully in value, use per-currency amounts.
## The five per-currency fields
| Block | Field |
| ----------------------------- | ------------------------------------------ |
| **Cart total** (condition) | **Amount** |
| **Fixed amount off** (action) | **Amount** |
| **Percentage off** (action) | **Max discount amount** (the optional cap) |
| **Free shipping** (action) | **Max shipping amount** (the optional cap) |
| **Tiered discount** (action) | **Spend threshold** |
Everything else stays currency-neutral by nature: percentages themselves, **Buy X get Y** quantities, **Volume pricing** tiers (quantity-based), the **Bundle discount** percent, and **Free gift** have no per-currency variant because they contain no money amount to vary.
## Setting per-currency amounts
Each of the five fields has a checkbox beneath it labeled **Set a different amount per currency**.
Tick **Set a different amount per currency**. The single input is replaced with per-currency rows, seeded with one row: your store currency at the amount you had entered.
Click **Add currency** to add a row. Each row pairs a **Currency** dropdown — listing your enabled presentment currencies, with codes already used by another row disabled — with an amount field and a remove button. At least one row must remain.
Type the amount that makes sense in each currency. These are independent values, not conversions — you decide what the offer is worth in every currency.
Unticking **Set a different amount per currency** clears all rows and restores single-amount entry. Once the campaign is saved, the cleared rows cannot be recovered.
## When a checkout currency has no row
In per-currency mode, only the currencies you list get an amount — and each field fails in its own direction when the checkout currency is missing. The editor shows a caption under each field spelling this out:
| Field | If the checkout currency has no row | Editor caption |
| ---------------------------------------- | ----------------------------------- | ----------------------------------------------------------------------- |
| **Fixed amount off** — Amount | No discount applies at all | "Checkout currencies not listed here get no discount from this action." |
| **Cart total** — Amount | The condition evaluates false | "This condition is false for checkout currencies not listed here." |
| **Percentage off** — Max discount amount | The percentage applies uncapped | "Checkout currencies not listed here are uncapped." |
| **Free shipping** — Max shipping amount | Shipping is fully free, uncapped | "Checkout currencies not listed here are uncapped." |
| **Tiered discount** — Spend threshold | The tier never unlocks | "Checkout currencies not listed here never unlock this discount." |
Note the split: discounts and conditions **fail closed** (no discount, condition false), while caps **fail open** (the discount runs uncapped). A missing row on a cap can cost you more than you planned — list every currency you sell in.
## Coverage warnings
The Rule Builder warns you — in a banner titled **This flow may be incomplete** — when a per-currency field:
* has no amount set for one of your store's enabled currencies ("…has no amount set for XXX."),
* lists a currency twice, or
* has an amount that isn't greater than 0.
These warnings never block saving — they exist to catch coverage gaps before your customers do.
## Per-currency values in summaries
Flow summaries and the Test panel display per-currency values inline, like "100 USD / 90 EUR" — up to three currencies, then "+ 2 more" for the rest.
## Pro plan requirement
Per-currency amounts are a **Pro** feature — the only Pro-gated feature in Galantis Discount Flow.
* On the Free plan, the **Set a different amount per currency** checkbox is disabled with a **Pro** badge and an **Upgrade** button.
* Saving or activating a campaign with per-currency amounts on Free is rejected: "Per-currency amounts require the Pro plan. Remove them or upgrade to Pro to save this campaign."
### What happens on downgrade
Downgrading from Pro to Free automatically **pauses** any active campaigns that use per-currency amounts, and records the pause in the **Activity Log**. To reactivate such a campaign on the Free plan, open it, untick **Set a different amount per currency** (this clears the rows), set a single amount, and activate it again.
## Testing and analytics
The Test panel always simulates in your **store currency** — there is no currency selector. A per-currency setup with no row for your store currency will look like it doesn't fire in the Test panel, even though it works at a real checkout in a listed currency. See [Testing flows](/galantis/discount/rule-builder/testing-flows).
At checkout, the currency that matters is the cart's **presentment currency** — the currency the customer sees and pays in. The theme embed uses the same logic on the storefront when evaluating free gifts and cart totals.
In [Analytics](/galantis/discount/analytics/index), all revenue and discount figures remain reported in your store currency (converted by Shopify) — there is no per-currency breakdown.
## Related guides
* [Actions & discount types](/galantis/discount/rule-builder/actions) — the four actions with per-currency fields
* [Conditions](/galantis/discount/rule-builder/conditions) — the Cart total condition's per-currency Amount
* [Plans & limits](/galantis/discount/billing/plans-limits) — the Pro requirement and downgrade behavior
* [How discounts apply at checkout](/galantis/discount/storefront/how-discounts-apply) — checkout-currency resolution
# Rule Builder overview
Source: https://docs.digifist.com/galantis/discount/rule-builder/index
The visual node-graph canvas where Galantis Discount Flow campaigns are assembled from trigger, condition, logic gate, and action blocks.
The Rule Builder is the visual canvas at the heart of every Galantis Discount Flow campaign. Instead of filling in a rigid form, you drag blocks onto a node graph and connect them — a **Start** block feeds into conditions, conditions branch into logic gates or further conditions, and the flow ends in one or more discount actions. What you draw is exactly what runs on your store.
Every flow is built from four categories of blocks: one **Start** trigger, eleven conditions, three logic gates, and eight actions. The canvas reads left to right — cart evaluation begins at **Start**, each condition routes the flow through its **Then** or **Otherwise** output, and whichever actions are reached apply their discount.
## Block categories
Eleven checks against the cart, customer, products, time, and place — each with Then and Otherwise output paths.
AND, OR, and NOT blocks for combining and inverting conditions into more precise targeting.
Eight discount actions, from Percentage off to Volume pricing — the blocks that actually reduce the price.
The Test panel simulates a cart and customer and highlights which path fires — without touching your live store.
## The canvas and toolbar
The block palette on the left lists every available block, grouped by category: **Trigger**, **Conditions**, **Logic gates**, and **Actions**. Drag a block onto the canvas, then draw connections between output and input ports to define the flow.
The toolbar above the canvas gives you:
* **Undo** / **Redo** — step backward and forward through canvas edits
* **Fit view** — zoom the canvas so the whole flow is visible
* **Auto-layout** — automatically arrange blocks into a tidy left-to-right layout
* **Templates** — start from a pre-built flow instead of an empty canvas
* **Test** — open the Test panel to simulate a cart and customer
* An issues indicator — a **Valid** badge when the flow is healthy, or an issue count you can click to see every problem
* The current zoom level
A few field types behave in a store-aware way:
* Product, collection, and gift fields open Shopify's resource picker, so you select real items from your catalog rather than typing names.
* Money fields show your store's own currency symbol, so a threshold of 100 means 100 in the currency your customers actually pay in.
## Validation
The Rule Builder continuously validates the flow as you build. Blocks with a problem get a red outline, and every issue appears in the toolbar's issues list with a plain-language explanation — for example, a block that is not connected, an action that cannot be reached from **Start**, a condition with no **Then** connection, or a loop in the graph.
A flow cannot be saved or published until it contains at least one valid, reachable action. Fix everything in the issues list until the toolbar shows the **Valid** badge before publishing.
## One flow, three places
The logic you draw runs in three places, and all three produce identical results:
1. **In the builder** — the Test panel evaluates the flow live against a simulated cart and customer, so you can verify behavior before publishing.
2. **On the storefront** — the theme embed evaluates the flow as customers shop, powering storefront behavior such as auto-adding a free gift to the cart.
3. **At checkout** — a Shopify discount Function runs the same flow and actually applies the discount to the order.
Because all three surfaces execute the same logic, what you see in the Test panel is what your customer gets at checkout — there is no separate configuration to keep in sync.
Start from a template when you can. Templates load a complete, valid flow onto the canvas that you can then adjust, which is faster than wiring every connection by hand.
## Related guides
* [Conditions](/galantis/discount/rule-builder/conditions) — All eleven condition blocks and their fields
* [Logic gates](/galantis/discount/rule-builder/logic-gates) — Combining conditions with AND, OR, and NOT
* [Actions & discount types](/galantis/discount/rule-builder/actions) — The eight discount actions and their settings
* [Testing flows](/galantis/discount/rule-builder/testing-flows) — Dry-running a flow before you publish
# Logic gates
Source: https://docs.digifist.com/galantis/discount/rule-builder/logic-gates
AND, OR, and NOT blocks in Galantis Discount Flow, plus Then/Otherwise branching — how to combine conditions into precise discount targeting.
A single condition answers one question; real campaigns usually ask several. Galantis Discount Flow gives you two ways to combine them: chain conditions through their **Then** and **Otherwise** outputs, or route multiple conditions into a dedicated logic gate. Both approaches produce the same evaluation everywhere the flow runs — in the builder, on the storefront, and at checkout.
Three logic gates are available, each with a single output that continues the flow when the gate passes.
## The three gates
All connected conditions must be true for the flow to continue.
Any one of the connected conditions being true is enough.
Inverts the connected condition — true becomes false, false becomes true.
Connect the **Then** outputs of two or more conditions into a gate's input, then connect the gate's output onward to an action or further logic. **AND** and **OR** accept multiple inputs; **NOT** inverts a single input.
## Then / Otherwise branching
Every condition has two outputs:
* **Then** — followed when the condition passes
* **Otherwise** — followed when it fails
This makes each condition a branch point on its own. Chaining conditions through **Then** is an implicit AND: the flow only reaches the end of the chain when every condition along the way passed. The **Otherwise** output lets you do something different for carts that fail a check — route them to a smaller offer, a different action, or simply nowhere (no discount).
## Worked examples
Two equivalent builds:
* **Chained:** **Start** → **Customer segment** (VIP) → **Then** → **Cart total** (**is greater than** 100) → **Then** → **Percentage off**. The discount only fires when both checks pass.
* **With an AND gate:** connect the **Then** outputs of both conditions into an **AND** block, and connect the gate's output to the action.
For two conditions, chaining is usually simpler. The gate version becomes valuable when the same combined result needs to feed several places, or when you start mixing in OR logic.
To exclude first orders, use the **First order** condition's **Otherwise** output: **Start** → **First order** → **Otherwise** → your action. Customers on their first order follow **Then** (which you leave unconnected or route elsewhere), and everyone else gets the discount.
Do not build this as **First order** → **NOT** → action. An action that is only reachable through a NOT gate can never apply, and the builder flags it as an issue. Use the condition's **Otherwise** output instead, or route the NOT into an AND/OR gate alongside another input.
Connect the **Then** outputs of **Day of week** (Saturday and Sunday selected) and **Customer segment** (VIP) into an **OR** block, then connect the gate to a **Free shipping** action. Either being true — it is the weekend, or the customer is a VIP — unlocks the offer. This is the pattern chaining cannot express, since a **Then** chain always means "all of these".
## Chaining vs gates
| Situation | Use |
| ------------------------------------------------ | ------------------------------------------------------------------------------------------- |
| All conditions must pass (simple AND) | Chain conditions through **Then** |
| Different outcomes for pass and fail | The condition's **Then** and **Otherwise** outputs |
| Any one of several conditions is enough | An **OR** gate |
| Many conditions must all pass and feed one point | An **AND** gate — keeps the canvas readable |
| Invert a check | Prefer the condition's **Otherwise** output; use **NOT** only as an input into AND/OR logic |
If a chain of **Then** connections is getting long, run **Auto-layout** from the toolbar and consider replacing part of the chain with an **AND** gate. The evaluation is identical, but the graph becomes much easier to read — and easier to test.
## Related guides
* [Conditions](/galantis/discount/rule-builder/conditions) — The eleven checks that feed your gates
* [Actions & discount types](/galantis/discount/rule-builder/actions) — Where the combined logic ultimately leads
* [Testing flows](/galantis/discount/rule-builder/testing-flows) — Watching the active path light up through your gates
# Testing flows
Source: https://docs.digifist.com/galantis/discount/rule-builder/testing-flows
The Test panel in Galantis Discount Flow — simulating carts and customers, reading the highlighted path, and a pre-publish checklist.
The Test panel is a dry-run environment built into the Rule Builder. It feeds a simulated cart and customer into your flow and shows exactly which blocks activate and which discounts would apply — using the same evaluation logic that runs on the storefront and at checkout. Because all three surfaces execute the flow identically, a result in the Test panel is the result your customer will get.
Open it with the **Test** button in the canvas toolbar. The **Test this flow** panel appears alongside the canvas, and every change you make to the simulated inputs re-evaluates the flow instantly.
## What you can simulate
The panel covers every input a condition can check:
| Input | What it feeds |
| -------------------------------------- | ----------------------------------------------------------------------- |
| **Cart total** | The **Cart total** condition, spend thresholds in **Tiered discount** |
| **Item quantity** | The **Item quantity** condition, **Volume pricing** tiers |
| **Customer tags** | The **Customer tag** condition (comma-separated, e.g. `vip, wholesale`) |
| **Segment** | The **Customer segment** condition |
| **Past order count** | The **Order count** condition |
| **First order** | The **First order** condition |
| **Discount code** | The **Discount code** condition |
| **Country** | The **Customer country** condition |
| **Date** | The **Day of week** condition |
| **Cart contains selected products** | The **Specific products** condition |
| **Cart contains selected collections** | The **Specific collections** condition |
The Test panel always simulates in your **store currency** — there is no currency selector. If a flow uses [per-currency amounts](/galantis/discount/rule-builder/currency-markets) and has no amount for your store currency, it will look like it doesn't fire here, even though it works at a real checkout in one of its listed currencies.
## Reading the results
As you adjust inputs, two things update at once:
* **On the canvas** — the active path through the graph lights up, so you can see which conditions passed, which **Then** or **Otherwise** branches were taken, and which blocks the simulated cart never reached.
* **In the Result section** — every action that fires is listed with an **Applies** badge and a description of the discount. If nothing fires, the panel says so: "No discount applies for this cart and customer."
Watching the highlighted path is the fastest way to debug a flow. If a discount is not applying, follow the lit edges to the first condition that routed the flow to **Otherwise** — that is the check the simulated cart failed.
Testing is completely safe. The Test panel evaluates the flow in the builder only — it never publishes anything, never creates a discount, and never affects your live store or real customers.
## Pre-publish test checklist
Run through these simulations before publishing any campaign:
Set the inputs to a cart and customer that should clearly qualify. Confirm the intended action fires with an **Applies** badge and that the description matches the discount you meant to build.
Flip one input below the threshold — drop the **Cart total**, clear the **Customer tags**, or untick **Cart contains selected products**. Confirm the panel reports that no discount applies.
Test values right at your thresholds — a cart total exactly equal to the amount, the precise quantity of a volume tier. This catches "is greater than" where you meant "is greater than or equal to".
If your flow branches, simulate inputs that send the cart down each **Otherwise** path and confirm each branch does what you expect — including doing nothing where nothing is intended.
Conditions like **Customer tag**, **Customer segment**, **Order count**, and **First order** require a logged-in customer. Simulate both a qualifying customer and an empty guest-like profile so you know what anonymous shoppers get.
Check the toolbar shows the **Valid** badge rather than an issue count. A flow with errors cannot be saved or published until every issue is resolved.
If a flow uses a **Discount code** condition, type the exact code into the panel's **Discount code** field during testing — with the field empty, the condition fails and the whole campaign correctly reports no discount, which is easy to mistake for a broken flow.
## Related guides
* [Rule Builder overview](/galantis/discount/rule-builder/index) — The canvas, toolbar, and validation
* [Conditions](/galantis/discount/rule-builder/conditions) — What each simulated input is checked against
* [Actions & discount types](/galantis/discount/rule-builder/actions) — The discounts that appear in the Result section
* [Multi-currency & Markets](/galantis/discount/rule-builder/currency-markets) — Why per-currency flows can look inactive in the Test panel
# Settings
Source: https://docs.digifist.com/galantis/discount/settings
The Galantis Discount Flow Settings page — manage your plan through Shopify and audit everything that happened in your account with the Activity Log.
The Settings page in Galantis Discount Flow has two parts: a **Plan** card for managing your subscription, and an **Activity Log** that records every meaningful change made in the app. Together they answer "what plan am I on?" and "who changed what, and when?".
## Plan card
The Plan card at the top of Settings shows:
* Your current plan badge (**Free** or **Pro**)
* A note that billing is handled securely by Shopify
* A **Change plan** button
Clicking **Change plan** takes you to a Shopify-hosted page where the subscription is managed — payment details never pass through Galantis Discount Flow. For plan differences, caps, and upgrade/downgrade behavior, see [Plans & limits](/galantis/discount/billing/plans-limits).
## Activity Log
The Activity Log is a paginated, searchable audit trail of your account — useful when a campaign changed unexpectedly, when you're checking who paused something, or when you need to see when a usage limit was hit.
### Layout
* **Tabs** — **All**, **Campaigns**, and **Settings** filter entries by category.
* **Search** — filter entries by keyword.
* **Pagination** — 20 entries per page.
Each entry has four columns:
| Column | Contents |
| ------------ | ---------------------------------------------------- |
| Action | The type of event (for example, campaign activated). |
| Description | What specifically happened. |
| Performed by | Who (or what) triggered the event. |
| Date | When it happened. |
### What gets logged
| Category | Logged events |
| --------- | --------------------------------------------------------------------------------- |
| Campaigns | Created, updated, activated, paused, archived, restored — including bulk actions. |
| Plan | Plan changes (upgrades and downgrades). |
| Usage | Usage limit reached, usage limit reset. |
| Privacy | Privacy requests. |
If discounts stopped applying and you're not sure why, check the Activity Log for a **usage limit reached** entry — it pins down exactly when the store's Free-plan cap was hit. See [Plans & limits](/galantis/discount/billing/plans-limits) for how the pause works.
Bulk campaign actions are logged too, so a mass pause or archive shows up as auditable entries rather than silently changing many campaigns.
## Related guides
* [Plans & limits](/galantis/discount/billing/plans-limits) — what the Plan card controls, and what happens on upgrade or downgrade
* [Troubleshooting](/galantis/discount/support/troubleshooting) — using the Activity Log to diagnose paused or missing discounts
# How discounts apply at checkout
Source: https://docs.digifist.com/galantis/discount/storefront/how-discounts-apply
What happens between publishing a campaign and a customer seeing the discount — automatic vs code-based campaigns, condition evaluation, stacking rules, and Shopify integration.
Every published campaign in Galantis Discount Flow is a real Shopify discount. At checkout, the discount Function evaluates your campaign's conditions against the live cart and applies the result — so the discount a customer sees is always computed from what's actually in their cart at that moment.
## Automatic vs code-based campaigns
A campaign becomes one of two kinds of Shopify discount, depending on how the flow is built:
The default. The discount applies at checkout on its own whenever the cart meets the campaign's conditions — the customer doesn't enter anything.
Created when the flow contains a **Discount code** condition. The customer enters the code at checkout, and the campaign's remaining conditions are then evaluated as usual.
Automatic discounts are applied by Shopify **at checkout**, so it's expected that a customer doesn't see the discount in the cart drawer or cart page. It appears once they reach checkout.
## Condition evaluation at checkout
When a customer reaches checkout, the discount Function checks the campaign's conditions against the live cart — items, quantities, totals, and (where used) customer attributes. Conditions are re-evaluated as the cart changes, so a discount that applied a moment ago disappears if the cart stops qualifying.
Customer-based conditions — customer tags, segments, order count, and first order — require the customer to be **logged in** at checkout. A guest checkout can't match these conditions, so campaigns that use them won't apply for anonymous customers.
## The checkout currency
Money amounts are evaluated in the cart's **presentment currency** — the currency the customer sees and pays in. If a field uses [per-currency amounts](/galantis/discount/rule-builder/currency-markets), the app applies the exact amount you entered for that checkout currency; a single amount is applied literally in whatever currency the customer checks out in. No currency conversion ever happens. The theme embed uses the same logic on the storefront for free-gift and cart-total evaluation.
## What each discount type does at checkout
| Discount type | Behavior at checkout |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Order percentage / fixed | Reduces the order total by a percentage or fixed amount. |
| Product percentage / fixed | Reduces the price of matching cart lines. |
| Capped percentage | A percentage discount limited by a **Max discount amount** — the discount never exceeds the cap. |
| Free shipping | A delivery discount on shipping, optionally capped at a maximum amount. |
| BOGO (same product) | Discounts the "get" units of a product the customer is buying. The "get" units must already be in the cart — checkout cannot add items. |
| Bundle | A product discount applied when the bundle's products are in the cart together. |
| Free gift | The gift product's price is discounted at checkout. The [theme app embed](/galantis/discount/storefront/theme-embed) is what adds the gift product to the cart on the storefront. |
## Combination and stacking rules
Whether campaigns stack with each other and with other Shopify discounts follows each campaign's **Combinations** settings, using Shopify's standard discount classes — order, product, and shipping. A campaign only combines with discounts in the classes you've allowed.
When multiple product discounts compete on the **same cart line**, the best one for the customer wins — they don't stack on a single line.
If a discount seems to be "missing" when several campaigns are active, check the **Combinations** settings on each campaign first, then check whether a stronger product discount won on that cart line.
## Integration with Shopify's Discounts page
Published campaigns appear on Shopify's native **Discounts** page in your admin, alongside any discounts you've created directly in Shopify. Clicking a Galantis campaign there opens it in Galantis Discount Flow for editing — so your team can start from either place.
Shopify enforces a platform limit: a store can have at most **25 active automatic discounts**, across all apps and native discounts combined. Code-based campaigns don't count toward this limit. See [Troubleshooting](/galantis/discount/support/troubleshooting) if you hit it.
## Related guides
* [Theme app embed](/galantis/discount/storefront/theme-embed) — the storefront half: free gifts and notifications
* [Multi-currency & Markets](/galantis/discount/rule-builder/currency-markets) — per-currency amounts and missing-currency behavior
* [Analytics](/galantis/discount/analytics/index) — how applications and conversions at checkout become your metrics
# Theme app embed
Source: https://docs.digifist.com/galantis/discount/storefront/theme-embed
Enable the Galantis Discount Flow app embed in your theme to auto-add free gifts to the cart, show gift notifications, and debug storefront evaluation.
The **Galantis Discount Flow** theme app embed is a small script that runs on your storefront. It evaluates your active campaigns against the live cart, automatically adds free gift products when a flow qualifies, removes them when the cart no longer qualifies, and can show customers a notification when a gift lands in their cart.
The embed does **not** apply price discounts. Percentage, fixed-amount, BOGO, bundle, and shipping discounts are applied at checkout by the discount Function whether or not the embed is enabled. The embed only powers storefront behavior — most importantly, free gifts. See [How discounts apply at checkout](/galantis/discount/storefront/how-discounts-apply).
## What the embed does — and doesn't
| The embed does | The embed does not |
| --------------------------------------------------------------- | ------------------------------------------ |
| Evaluate active campaigns on the storefront | Apply percentage or fixed-amount discounts |
| Auto-add free gift products to the cart when the flow qualifies | Apply BOGO, bundle, or shipping discounts |
| Remove gifts when the cart stops qualifying | Change prices in the cart |
| Show a notification when a gift is added | Affect checkout in any way |
| Log evaluation details when Debug mode is on | |
## Enabling the embed
In your Shopify admin, go to **Online Store → Themes** and click **Customize** on your live theme.
In the theme editor sidebar, select **App embeds**.
Find **Galantis Discount Flow** in the list and toggle it on. **Enable Galantis Discount Flow** is on by default once the embed itself is activated.
Click **Save**. The embed starts evaluating campaigns on your storefront immediately.
## Embed settings
Default: **on**. The master switch for the embed. When off, no storefront evaluation happens — free gifts are not auto-added and no notifications are shown. Checkout discounts still apply normally.
Default: **off**. When on, the embed logs its campaign evaluation to the browser console — which campaigns were checked, whether the cart qualified, and what actions were taken. Useful when a free gift isn't behaving as expected. Turn it off again once you're done troubleshooting.
Default: **on**. When the cart qualifies for a free-gift flow, the gift product is added to the cart automatically. When the cart changes and no longer qualifies, the gift is removed again. Turn this off if you prefer gifts not to be added on the storefront.
Default: **on**. Displays a brief on-page notification the moment a gift is added, so customers understand why a new item appeared in their cart.
Default: "Your free gift has been added to your cart 🎁". Customize the message customers see when a gift is added — for example, to translate it or match your brand voice.
## How free-gift behavior works
When **Auto-add free gifts** is on, the embed watches the cart and reacts in both directions:
* **Cart qualifies** — the gift product is added automatically, and the notification appears (if enabled).
* **Cart stops qualifying** — for example, the customer removes the qualifying item — the gift is removed automatically, so customers can't keep gifts they no longer earned.
If a free gift isn't appearing, the two most common causes are the theme embed being disabled and **Auto-add free gifts** being turned off. Check both before digging deeper — see [Troubleshooting](/galantis/discount/support/troubleshooting).
## Debugging with Debug mode
Turn on **Debug mode**, open your storefront, and open your browser's developer console. The embed prints its evaluation of each active campaign against the current cart, which usually makes it obvious why a flow did or didn't qualify. Remember to turn Debug mode off afterwards so shoppers' consoles stay clean.
## Related guides
* [How discounts apply at checkout](/galantis/discount/storefront/how-discounts-apply) — the checkout side of the picture
* [Troubleshooting](/galantis/discount/support/troubleshooting) — free gift not appearing, and other common issues
# Troubleshooting
Source: https://docs.digifist.com/galantis/discount/support/troubleshooting
Common Galantis Discount Flow issues and how to fix them — discounts not applying, free gifts not appearing, activation limits, sync errors, and reinstall behavior.
Most issues with Galantis Discount Flow come down to a small set of causes: a plan or platform limit was reached, the theme embed isn't enabled, a condition requires a logged-in customer, or a push to Shopify failed. This page lists each common symptom with its cause and fix.
For anything involving free gifts or storefront behavior, turn on **Debug mode** in the [theme app embed](/galantis/discount/storefront/theme-embed) settings first — it logs the storefront evaluation to the browser console and usually reveals the cause immediately.
## Common issues
**Symptom:** A campaign's detail page shows a sync error banner, and the discount isn't behaving as expected at checkout.
**Cause:** Pushing the campaign to Shopify failed, so the Shopify discount is out of date (or missing).
**Fix:** Click the **Resync** button on the banner to push the campaign to Shopify again. If the error persists, check the other limits on this page — a resync can fail because a platform or plan limit blocks it.
**Symptom:** Activating a campaign fails with this message.
**Cause:** This is a Shopify platform limit, counted across **all** apps and native Shopify discounts — not a Galantis Discount Flow limit.
**Fix:** Deactivate automatic discounts you no longer need (in Galantis Discount Flow or on Shopify's native **Discounts** page), then activate the campaign again. Code-based campaigns don't count toward this limit, so converting a flow to use a **Discount code** condition is another way to stay under it.
**Symptom:** You can't activate a fourth campaign on the Free plan.
**Cause:** The Free plan allows at most 3 active campaigns at a time.
**Fix:** Pause one of your active campaigns, or upgrade to Pro via **Settings → Change plan** for unlimited active campaigns. See [Plans & limits](/galantis/discount/billing/plans-limits).
**Symptom:** Saving or activating a campaign fails with this message.
**Cause:** The campaign uses [per-currency amounts](/galantis/discount/rule-builder/currency-markets) — the only Pro-gated feature — and your store is on the Free plan.
**Fix:** Either upgrade to Pro via **Settings → Change plan**, or untick **Set a different amount per currency** on each field that uses it (this clears the per-currency rows) and enter a single amount instead.
**Symptom:** After moving from Pro to Free, some campaigns that were active are now paused.
**Cause:** Downgrading re-applies Free-plan rules in two ways: the 3-active-campaign limit auto-pauses campaigns beyond the oldest 3, and any active campaign using per-currency amounts is auto-paused because per-currency amounts require Pro. Both events are recorded in the **Activity Log** in [Settings](/galantis/discount/settings).
**Fix:** For the campaign-limit pause, choose which 3 campaigns stay active by pausing and activating campaigns yourself. For a per-currency pause, open the campaign, untick **Set a different amount per currency** (this clears the rows), set a single amount, and reactivate — or upgrade back to Pro. See [Plans & limits](/galantis/discount/billing/plans-limits).
**Symptom:** Discounts that worked yesterday no longer apply at checkout, and the dashboard shows a usage-paused banner.
**Cause:** Your store is on the Free plan and hit a monthly usage cap — 25 discounted orders or 1,000 discount applications. Hitting either cap pauses all of the store's discounts for the rest of the period.
**Fix:** Wait for the next monthly period (anchored to your install date), when discounts reactivate automatically — or upgrade to Pro, which lifts the pause immediately. The **Activity Log** in [Settings](/galantis/discount/settings) shows exactly when the limit was reached.
**Symptom:** The cart qualifies for a free-gift flow, but the gift product never appears.
**Cause:** The **Galantis Discount Flow** theme app embed is disabled, or its **Auto-add free gifts** setting is turned off. Gifts are added on the storefront by the embed — checkout cannot add items.
**Fix:** In the theme editor, open **App embeds**, enable **Galantis Discount Flow**, and confirm **Auto-add free gifts** is on. If it still doesn't appear, enable **Debug mode** and check the browser console to see how the campaign evaluated. See [Theme app embed](/galantis/discount/storefront/theme-embed).
**Symptom:** A campaign using customer tags, segments, order count, or first-order conditions doesn't apply, even for customers who should qualify.
**Cause:** Customer-based conditions require the customer to be **logged in**. Guest checkouts have no customer identity to evaluate against.
**Fix:** Test while logged in to a customer account that meets the conditions. If your store relies heavily on guest checkout, consider conditions based on the cart instead of the customer.
**Symptom:** A campaign works for most customers, but customers checking out in one particular currency never get the discount.
**Cause:** The campaign uses [per-currency amounts](/galantis/discount/rule-builder/currency-markets), and that checkout currency has no row. A **Fixed amount off** with no amount for the currency gives no discount from that action, a **Cart total** condition with no amount evaluates false, and a **Tiered discount** threshold with no amount never unlocks. The app never converts amounts between currencies.
**Fix:** Open the campaign and add a row with an amount for the missing currency on each per-currency field. The Rule Builder's **This flow may be incomplete** warning banner lists which of your enabled currencies have no amount set. Note that the Test panel always simulates in your store currency, so use it to check store-currency coverage and rely on the warnings for the rest.
**Symptom:** A **Max discount amount** or **Max shipping amount** cap works in some currencies but seems ignored in others — the percentage applies in full, or shipping is entirely free.
**Cause:** The cap uses per-currency amounts, and the checkout currency has no row. Unlike discounts and conditions, caps **fail open**: checkout currencies not listed are uncapped.
**Fix:** Add a cap row for every currency your store sells in. The **This flow may be incomplete** warning flags enabled currencies with no amount set — it doesn't block saving, so it's easy to miss. See [Multi-currency & Markets](/galantis/discount/rule-builder/currency-markets).
**Symptom:** Customers report the discount is "missing" on the cart page, yet it appears once they reach checkout.
**Cause:** This is expected behavior for automatic discounts — Shopify applies them at checkout, not in the cart.
**Fix:** Nothing to fix. If cart-page visibility matters to you, communicate the offer with your theme's promotional content instead.
**Symptom:** You uninstalled Galantis Discount Flow and want to know what happens to your data.
**Cause / behavior:** If you reinstall within **48 hours**, your campaigns are restored automatically. After 48 hours, data is permanently deleted in line with Shopify's privacy rules.
**Fix:** Reinstall within 48 hours to recover everything. After that window, campaigns must be rebuilt from scratch.
## Still stuck?
If none of the above matches your issue, gather what you can before reaching out: the campaign name, what you expected vs what happened, whether the store is on Free or Pro, and (for storefront issues) the **Debug mode** console output from the theme embed.
## Related guides
* [Theme app embed](/galantis/discount/storefront/theme-embed) — embed settings and Debug mode
* [How discounts apply at checkout](/galantis/discount/storefront/how-discounts-apply) — evaluation, stacking, and the automatic-vs-code distinction
* [Multi-currency & Markets](/galantis/discount/rule-builder/currency-markets) — per-currency amounts, missing-currency behavior, and the Pro requirement
* [Plans & limits](/galantis/discount/billing/plans-limits) — caps, the pause mechanic, and changing plans
# Welcome to Galantis
Source: https://docs.digifist.com/galantis/index
Get the documentation you need to succeed with Galantis services.
## Themes
Galantis Connect is a powerful integration tool that allows you to seamlessly connect your Shopify store with Galantis services. It enables you to manage your products, orders, and customer data efficiently while leveraging Galantis’s advanced features to enhance your store’s performance.
Galantis Discount Flow is a Shopify discount app that lets you build powerful discount campaigns with a visual Rule Builder. Combine conditions, logic gates, and eight discount types — from percentage and BOGO offers to free gifts and volume pricing — and measure real revenue impact with built-in analytics.
Galantis Whatsapp is an innovative marketing integration that allows you to connect your Shopify store with WhatsApp. It enables you to engage with your customers directly through WhatsApp, providing a seamless communication channel for promotions, order updates, and customer support.
# Consent & Opt-outs
Source: https://docs.digifist.com/galantis/whatsapp/audience/consent-optouts
How marketing consent is tracked per customer in Galantis, how opt-outs are processed, and what re-subscription requires.
Marketing consent is tracked individually for every customer in Galantis through the `marketing_state` field. This field controls whether a customer can receive campaign messages, automation messages, and Back-in-Stock notifications. It is updated automatically through Shopify webhooks and platform events — and it is enforced automatically before any message is dispatched.
This page covers consent from the audience management perspective — how it is set, how it changes, and how to manage it across your contact base. For the broader compliance context and WhatsApp policy requirements, see [Compliance — Opt-in & Consent](/whatsapp/compliance/opt-in-consent).
## What this covers
* All consent states and their meaning
* How consent state changes over time
* Opt-out processing and the STOP flow
* Re-subscription requirements
* Reviewing and filtering contacts by consent state
## Consent states
Every customer in Galantis has one of the following `marketing_state` values:
| State | Meaning | Can receive messages |
| ---------------- | ---------------------------------------- | -------------------- |
| `SUBSCRIBED` | Explicitly opted in | Yes |
| `PENDING` | Consent collected, awaiting confirmation | No |
| `NOT_SUBSCRIBED` | Has not opted in | No |
| `UNSUBSCRIBED` | Previously opted in, now opted out | No |
| `UNKNOWN` | No consent information available | No |
| `INVALID` | Bad or unverifiable data | No |
| `REDACTED` | GDPR/compliance data deletion applied | No |
Only `SUBSCRIBED` customers are eligible for campaign sends and automation message actions. All other states result in the customer being excluded from or skipped in any outbound send.
## How consent state is set
Consent state originates from Shopify and is kept current via the `customers/marketing_consent_updated` webhook. When a customer's consent changes in Shopify — through a checkout opt-in, a form submission, or an admin update — the change propagates to Galantis automatically.
The following events set or change a customer's `marketing_state`:
| Event | Resulting state | Mechanism |
| ------------------------------------------------------ | ----------------------------- | ---------------------------------------------- |
| Customer checks the opt-in box at Shopify checkout | `SUBSCRIBED` | `customers/marketing_consent_updated` webhook |
| Customer submits their number via Back-in-Stock widget | `SUBSCRIBED` | Galantis records consent at submission |
| Customer initiates contact via storefront chat widget | `SUBSCRIBED` | Customer-initiated contact establishes consent |
| Manual import with consent confirmation | `SUBSCRIBED` | Set at import time |
| Customer replies **STOP** to any WhatsApp message | `UNSUBSCRIBED` | Galantis processes inbound STOP reply |
| Customer never opted in | `NOT_SUBSCRIBED` or `UNKNOWN` | Synced from Shopify consent data |
| GDPR deletion request received | `REDACTED` | `customers/redact` webhook |
## Opt-out processing
When a customer replies **STOP** to any WhatsApp message — whether from a campaign, an automation, or an Inbox agent — Galantis processes the reply and moves the customer's `marketing_state` to `UNSUBSCRIBED` immediately.
From that moment:
* The customer is excluded from all future campaign audience calculations
* The customer is skipped in all automation message actions — the skip is recorded as `SKIPPED` in the activity log
* The customer does not receive Back-in-Stock notifications, even if they have an `ACTIVE` subscription record
* The customer remains in any lists or segments they belong to — opt-out affects messaging eligibility, not list or segment membership
Opt-out is processed at the platform level, not just per channel. A customer who replies STOP to a campaign message is opted out of all Galantis messaging — automations, Inbox-initiated messages, and Back-in-Stock notifications — not only the specific campaign they replied to.
## Re-subscription
An `UNSUBSCRIBED` customer cannot be re-added to messaging through any admin action within Galantis. Re-subscription requires explicit new opt-in from the customer through an approved collection method:
* Re-submitting their number via the Back-in-Stock widget
* Checking the opt-in box at the Shopify checkout on a subsequent order
* Any other explicit opt-in mechanism that generates a `customers/marketing_consent_updated` webhook with a subscribed state
When a re-subscription event occurs, Shopify sends the consent update webhook and Galantis moves the customer's `marketing_state` back to `SUBSCRIBED`. From that point, they are eligible to receive messages again.
Do not attempt to manually override `UNSUBSCRIBED` status in Galantis. Doing so would bypass WhatsApp's consent requirements and could result in policy violations and quality degradation on your phone number. The re-subscription path must originate from the customer.
## REDACTED state
`REDACTED` is distinct from `UNSUBSCRIBED`. It is applied when a GDPR or compliance data deletion request is received via Shopify's `customers/redact` webhook. Unlike `UNSUBSCRIBED`, `REDACTED` is not reversible through re-subscription — it signals that the customer's data has been subject to a deletion request and must not be used for any messaging purpose.
See [Compliance — GDPR & Data Privacy](/whatsapp/compliance/gdpr-data-privacy) for full details on how deletion requests are processed.
## Reviewing contacts by consent state
To review your contact base by consent state:
1. Go to **Audience → Contacts**
2. Filter by `marketing_state` to view all customers in a specific state
3. For individual customers, open the contact profile — the current `marketing_state` is visible at the top of the profile alongside other key fields
Filtering by `UNSUBSCRIBED` gives you visibility into how many customers have opted out and when. Filtering by `NOT_SUBSCRIBED` or `UNKNOWN` shows customers who are in your Shopify store but have not opted into WhatsApp marketing — these are contacts you cannot message through Galantis until they provide explicit consent.
## Using consent state in segments
The `Consent status` segment rule lets you build segments that only contain `SUBSCRIBED` customers:
```
Consent status = Yes
```
Adding this rule to any segment used as a campaign audience ensures the segment never contains non-eligible customers — which prevents the consent filter from silently reducing your actual send count below your estimated reach at send time.
See [Segments](./segments) for how to configure this rule alongside other targeting conditions.
## Best practices
* **Never manually import customers as `SUBSCRIBED` without verifiable proof of opt-in.** An import that marks customers as consented without a valid opt-in record is a WhatsApp policy violation.
* **Add `Consent status = Yes` to campaign-facing segments.** This surfaces only messageable customers in reach estimates and prevents confusion when estimated reach differs significantly from actual sends.
* **Monitor opt-out rates after campaigns.** A high volume of STOP replies following a campaign is a signal that the message was not well-targeted or was perceived as unwanted. Review audience quality and message relevance before the next send.
* **Do not re-import `UNSUBSCRIBED` customers as consented.** Re-importing and marking an opted-out customer as subscribed without a genuine new opt-in is a compliance violation that puts your phone number quality at risk.
## Related guides
* [Compliance — Opt-in & Consent](/whatsapp/compliance/opt-in-consent) — WhatsApp policy requirements and collection methods
* [Compliance — GDPR & Data Privacy](/whatsapp/compliance/gdpr-data-privacy) — REDACTED state and deletion request handling
* [Segments](./segments) — Using `Consent status` as a segment rule condition
* [Contacts](./contacts) — Where `marketing_state` appears on the contact profile
# Contacts
Source: https://docs.digifist.com/galantis/whatsapp/audience/contacts
Customer profiles in Galantis — synced from Shopify, enriched with WhatsApp engagement history, and used across campaigns, automations, and the Inbox.
Contacts are the individual customer records in Galantis. Every contact is sourced from Shopify and kept current via webhook sync — when a customer's data changes in Shopify, the change propagates to Galantis within seconds. On top of the Shopify data, Galantis enriches each contact with WhatsApp-specific information: message history, conversation threads, automation activity, and consent status.
A contact's profile is the single source of truth for everything Galantis knows about that customer — it is what campaign targeting, automation conditions, segment rules, and Inbox context all draw from.
## What this covers
* All customer profile fields and their sources
* Related data available per contact
* How sync works and what triggers it
* The `exclude_from_galantis` flag
* Finding and reviewing a contact's profile
## Customer profile fields
| Field | Source | Purpose |
| --------------------- | ------- | ---------------------------------------------------------------- |
| `shopify_customer_id` | Shopify | Links the Galantis contact record to the Shopify customer record |
| `first_name` | Shopify | Display name — used in template variable mapping |
| `last_name` | Shopify | Display name — used in template variable mapping |
| `email` | Shopify | Contact info — available as a template variable |
These fields are synced from Shopify on customer creation and updated whenever the customer record changes in Shopify via the `customers/update` webhook.
| Field | Source | Purpose |
| -------------------- | ------- | ----------------------------------------------------- |
| `phone` | Shopify | The WhatsApp number used for message delivery |
| `phone_country_code` | Shopify | ISO country code for the phone number |
| `phone_calling_code` | Shopify | International dialing prefix (e.g., `+52` for Mexico) |
All three phone fields must be present and valid for a message to be deliverable. A missing `phone_calling_code` is the most common cause of `CUSTOMER_IS_MISSING_CALLING_CODE` delivery failures. When this error appears in campaign analytics or automation activity logs, it indicates the customer's phone number in Shopify is missing the country calling code — this must be corrected in Shopify for the record to sync correctly into Galantis.
Phone number data is synced from Shopify as entered by the customer. Galantis does not normalize or validate phone number format beyond what Shopify provides. If customers in your store frequently enter numbers without country codes, review your Shopify checkout phone field configuration.
| Field | Source | Purpose |
| ----------------- | ------------------ | ---------------------------------------------------------------------------------- |
| `tags` | Shopify | Lifecycle stages and custom tags — used in segment rules and automation conditions |
| `marketing_state` | Shopify / Galantis | Consent status — determines eligibility for campaigns and automations |
| `country` | Shopify | Geo targeting — used in segment rules and country-based automation conditions |
| `locale` | Shopify | Language/locale — useful for language-based segment targeting |
`marketing_state` is the most consequential field on a contact's profile. It is updated by Shopify consent webhooks and by Galantis when a customer replies STOP. See [Consent & Opt-outs](./consent-optouts) for the full state reference.
`tags` are synced via the `customer_tags/added` and `customer_tags/removed` webhooks — tag changes in Shopify propagate to Galantis in near real time and immediately affect segment membership for any segment with tag-based rules.
| Field | Source | Purpose |
| ----------------------- | -------- | ---------------------------------------------------- |
| `synced_at` | Galantis | Timestamp of the last successful sync from Shopify |
| `exclude_from_galantis` | Galantis | Excludes the customer from AI automation suggestions |
`synced_at` is useful for diagnosing whether a recent Shopify change has propagated to Galantis. If a customer's profile in Galantis appears outdated, check `synced_at` against the time of the Shopify change.
`exclude_from_galantis` is a Galantis-side flag that excludes the customer from AI-powered automation suggestions in the Galantis AI flow builder. It does not affect manual automation enrollment or campaign sends.
## Related data per contact
Beyond the profile fields, each contact's record surfaces related data from across the platform:
**Order history** (`orders`) — All Shopify orders associated with the customer, synced via the `orders/create` and `orders/updated` webhooks. Used in segment rules (total spent, order count, days since last order) and available as context in the Inbox conversation view.
**Back-in-Stock subscriptions** (`subscriptions`) — Any active or historical Back-in-Stock widget subscriptions the customer has submitted. Visible per contact to confirm subscription status for a specific variant.
**Message history** (`messages`) — All WhatsApp messages sent to and received from this customer across campaigns, automations, and Inbox conversations. Visible on the contact profile for full communication context.
**Conversation threads** (`conversations`) — All Inbox conversation threads for the customer, with their status (OPEN, PENDING, RESOLVED) and assigned agent.
**List and segment membership** — Which Customer Lists the contact belongs to and which Segments they currently match. Useful for confirming whether a customer should have been included or excluded from a recent campaign.
## How sync works
Galantis maintains customer data through two mechanisms:
**Initial import** — When the app is first installed, Galantis runs a full import of your existing Shopify customer base. This populates the contact database with all customers at the time of installation.
**Ongoing webhook sync** — After the initial import, Galantis receives Shopify webhooks for every customer event:
| Webhook | What it updates |
| ------------------------------------- | ------------------------------------------- |
| `customers/create` | Creates a new contact record |
| `customers/update` | Updates profile fields, phone, tags, locale |
| `customers/delete` | Removes the contact record |
| `customers/marketing_consent_updated` | Updates `marketing_state` |
| `customer_tags/added` | Adds tags to the contact record |
| `customer_tags/removed` | Removes tags from the contact record |
## Finding a contact's profile
Navigate to **Audience → Contacts** and search by name, email, or phone number. The contact profile page shows all fields, related data, and a summary of recent message and automation activity.
The contact profile is also surfaced contextually in the Inbox — when an agent opens a conversation, the customer's Shopify data, order history, and consent status are visible in the sidebar without leaving the thread.
## Best practices
* **Resolve `CUSTOMER_IS_MISSING_CALLING_CODE` errors at the source.** Fix the phone number format in Shopify — Galantis will sync the corrected data via webhook. Attempting to fix it in Galantis directly is not the right approach since the Shopify record will overwrite the change on the next sync.
* **Use `synced_at` to diagnose stale data.** If a customer's segment membership or consent status seems incorrect, check `synced_at` to determine when the last sync occurred and whether a recent Shopify change has had time to propagate.
* **Review tag sync timing for automation conditions.** Tag-based automation conditions (`CUSTOMER_TAG`) evaluate the customer's tags at the moment the condition node is reached — not at trigger time. A customer who gains or loses a tag while in a delayed flow will be evaluated against their tag state at condition evaluation, not at enrollment.
## Related guides
* [Segments](./segments) — Using contact fields as segment rule conditions
* [Consent & Opt-outs](./consent-optouts) — How `marketing_state` is set and enforced
* [Inbox — Assignment & Routing](/whatsapp/inbox/assignment-routing) — How contact context appears in Inbox conversations
* [Support — Message Delivery](/whatsapp/support/troubleshooting/message-delivery) — Resolving phone number format errors
# Audience
Source: https://docs.digifist.com/galantis/whatsapp/audience/index
Customer contacts, static lists, and dynamic segments — the targeting foundation for every campaign and automation in Galantis.
The Audience module is where your customer data lives in Galantis. Every contact synced from Shopify, every list you build manually, and every segment defined by rules is managed here. Campaigns draw their recipients from this data. Automations evaluate conditions against it. Consent state is tracked within it.
Understanding how contacts, lists, and segments relate to each other — and how they behave differently — is the prerequisite for building campaigns and automations that reach the right customers with the right message.
## How audience data works in Galantis
Galantis syncs customer data from Shopify continuously via webhooks. When a customer is created, updated, or deleted in Shopify, the change is reflected in Galantis within seconds. This means your contact profiles, order history, tags, and consent status are always current — you are not working with a stale snapshot.
On top of the synced contact data, Galantis maintains two types of audience groupings:
**Lists** are static. You add customers to a list manually or via import and they stay there until removed. Lists are simple and predictable — useful for curated, stable groups like VIP customers or newsletter subscribers.
**Segments** are dynamic. They are defined by rules evaluated against contact data. As customer data changes, segment membership updates automatically. A customer crosses your spending threshold — they join the high-LTV segment. A customer goes 60 days without ordering — they enter the lapsed segment. No manual management required.
## Guides in this section
Customer profile fields, Shopify sync behavior, and related data available per contact.
Static customer groups — creating, managing, and using lists in campaigns and automations.
Dynamic rule-based groups — all available conditions, operators, and evaluation behavior.
How opt-in status is tracked per customer and how opt-outs are handled.
## How audience data feeds campaigns and automations
| Feature | Uses lists | Uses segments | Uses contact fields |
| ----------------- | --------------------------------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------ |
| **Campaigns** | As include/exclude targets | As include/exclude targets | For variable mapping in templates |
| **Automations** | As exclusion rules, trigger source (`USER_ADDED_TO_LIST`) | As exclusion rules, trigger source (`USER_ADDED_TO_SEGMENT`), condition evaluation | For condition evaluation, variable mapping |
| **Back-in-Stock** | — | — | For consent validation and notification delivery |
## Related guides
* [Campaigns — Audience Targeting](/whatsapp/campaigns/audience-targeting) — Using lists and segments as campaign audiences
* [Automations — Exclusion Rules](/whatsapp/automations/exclusion-rules) — Excluding lists and segments from automation enrollment
* [Compliance — Opt-in & Consent](/whatsapp/compliance/opt-in-consent) — How consent state is enforced across the platform
# Lists
Source: https://docs.digifist.com/galantis/whatsapp/audience/lists
Static customer groups in Galantis — created and managed manually, used as campaign targets and automation exclusions.
Customer Lists are static, manually managed groups. Unlike segments — which update automatically as customer data changes — a list's membership changes only when you explicitly add or remove customers. That predictability is what makes lists useful: when you need a fixed, curated group that does not shift between when you configure a campaign and when you send it, a list is the right tool.
## What this covers
* What lists are and when to use them over segments
* Creating and managing lists
* Adding customers to a list
* How lists are used in campaigns and automations
* Common list use cases
## Lists vs segments
| | Lists | Segments |
| -------------- | ----------------------------------------------------- | -------------------------------------------------------- |
| **Membership** | Static — changes only when you manually add or remove | Dynamic — updates automatically as customer data changes |
| **Management** | Manual | Rule-based, self-maintaining |
| **Best for** | Curated, stable groups | Behavioral or data-driven groups |
| **Example** | VIP customers selected by hand | Customers who spent > \$500 in the last 90 days |
Use a list when the group is defined by human judgment — a handpicked VIP tier, a specific import, a post-event attendee group. Use a segment when the group is defined by customer behavior or data thresholds that should update automatically.
## Creating a list
In the Galantis dashboard, go to **Audience → Lists** and click **New List**.
Give the list a clear, descriptive name. List names appear in the campaign audience builder and in automation exclusion rules — a name like `VIP Customers - Handpicked` is more useful than `List 1`.
Add customers individually by searching for them, or import a batch via CSV upload. Customers can also be added to a list programmatically via the `USER_ADDED_TO_LIST` automation trigger context.
The list is immediately available for use in campaign audience targeting and as an automation exclusion rule or trigger source.
## Adding customers to a list
**Individual add** — Search for a customer by name, email, or phone number in the list management view and add them directly. Use this for one-off additions or small curated groups.
**Bulk import** — Upload a CSV of customer records to add multiple customers at once.
**Recency tracking** — Each list tracks when it was most recently used in a campaign. This is visible in the list detail view and is useful for auditing which lists are actively in use versus stale.
## How lists are used
**In campaigns** — Lists can be added as include or exclude targets in the campaign audience builder. Include a list to send to its members; exclude a list to suppress its members from the send even if they appear in other included sources. See [Campaigns — Audience Targeting](/whatsapp/campaigns/audience-targeting).
**As automation triggers** — The `USER_ADDED_TO_LIST` trigger fires an automation when a customer is added to a specific list. This makes lists a useful mechanism for manually enrolling customers into automation flows — adding a customer to a "Win-Back Candidates" list triggers the win-back flow without any further configuration. See [Automations — Triggers](/whatsapp/automations/triggers).
**As automation exclusions** — Lists can be added as exclusion rules on any automation. Customers on the excluded list are not enrolled in the automation even if they match the trigger. The most common use is a "Do Not Contact" suppression list applied as an exclusion across multiple automations. See [Automations — Exclusion Rules](/whatsapp/automations/exclusion-rules).
## Common use cases
**VIP customers** — A handpicked list of your highest-value customers, used as an include target for VIP-exclusive campaign sends and a condition input for automation branching.
**Newsletter subscribers** — Customers who opted into a specific newsletter or content series, managed separately from general marketing consent.
**Post-purchase follow-up groups** — Customers who purchased a specific product or attended a specific event, grouped manually for a targeted follow-up campaign.
**Re-engagement candidates** — Customers identified for re-engagement based on manual review rather than a data-driven segment rule.
**Suppression / Do Not Contact** — Customers who have requested no messaging beyond the standard opt-out flow. Adding this list as an exclusion on all automations creates a secondary suppression layer on top of consent-state filtering.
## Best practices
* **Keep list names descriptive and consistent.** Lists are referenced by name throughout the campaign builder and automation configuration. A clear naming convention (`[Purpose] - [Date or Version]`) reduces confusion when managing multiple lists.
* **Audit list membership regularly.** Unlike segments, lists do not self-update. A VIP list that has not been reviewed in 6 months may contain customers who are no longer active or relevant. Schedule periodic reviews.
* **Use exclusion lists proactively.** Maintaining a "Do Not Contact" list and applying it as an exclusion across automations provides a safety net for customers who have communicated a preference outside the standard STOP flow.
* **Prefer segments for data-driven groups.** If the criteria for list membership can be expressed as a rule (e.g., "spent more than \$200"), build a segment instead — it will stay accurate without manual maintenance.
## Related guides
* [Segments](./segments) — Dynamic rule-based groups that complement static lists
* [Consent & Opt-outs](./consent-optouts) — How opt-out state interacts with list membership
* [Campaigns — Audience Targeting](/whatsapp/campaigns/audience-targeting) — Using lists as campaign audience sources
* [Automations — Triggers](/whatsapp/automations/triggers) — USER\_ADDED\_TO\_LIST trigger configuration
* [Automations — Exclusion Rules](/whatsapp/automations/exclusion-rules) — Using lists as automation suppression rules
# Segments
Source: https://docs.digifist.com/galantis/whatsapp/audience/segments
Dynamic rule-based customer groups that update automatically as customer data changes — the targeting engine for campaigns and automations.
Customer Segments are dynamic groups defined by rules evaluated against contact data. Unlike lists, which are maintained manually, segments maintain themselves — as a customer's orders, spend, engagement, or tags change in Shopify, their segment membership updates automatically. This makes segments the right tool for any audience group defined by behavior, lifecycle stage, or data thresholds.
Segments are used as campaign audience targets, automation triggers, automation condition evaluations, and automation exclusion rules — they are woven into nearly every part of the Galantis platform.
## What this covers
* How segment rules work
* All available rule conditions and operators
* AND/OR grouping for complex rule logic
* How segment evaluation works
* Using segments in campaigns and automations
## How segment rules work
A segment is defined by one or more rule conditions. When Galantis evaluates a segment, it runs the rules against every customer in your workspace and identifies which customers match. Customers who match become members; customers who no longer match are removed.
Rules use two levels of logic:
* **AND logic within a group** — all conditions in a group must be true for a customer to match that group
* **OR logic between groups** — a customer who matches any group is included in the segment
This structure allows complex expressions like:
```
(Total spent > 500 AND Country = MX)
OR
(Orders count >= 3 AND Consent = Yes)
```
A customer who matches either group is a segment member — they do not need to match both.
## Rule conditions
**Phone number** — Match customers by exact phone number.
| Operator | Behavior |
| ----------- | ------------------------------------------- |
| exact match | Customer's phone equals the specified value |
**Added to list** — Match customers who are members of a specific Customer List.
| Operator | Behavior |
| -------- | ----------------------------------------- |
| in list | Customer is a member of the selected list |
The `Added to list` condition creates an intersection between a dynamic segment and a static list — useful for applying additional rule-based filters on top of a manually curated list.
**Last message received** — Match customers based on the date of their most recent inbound WhatsApp message.
| Operators | date comparison |
| --------- | --------------- |
**Last engaged at** — Match customers based on when they last engaged with a WhatsApp message (opened, replied, or clicked).
| Operators | before / after / between / in last X days |
| --------- | ----------------------------------------- |
**Messages received** — Match customers by total count of WhatsApp messages received.
| Operators | `>`, `<`, `>=`, `<=`, `=`, `between` |
| --------- | ------------------------------------ |
**Messages read** — Match customers by total count of WhatsApp messages they opened.
| Operators | `>`, `<`, `>=`, `<=`, `=`, `between` |
| --------- | ------------------------------------ |
**Automation completions** — Match customers by how many times they have completed an automation flow.
| Operators | `>`, `<`, `>=`, `<=`, `=`, `between` |
| --------- | ------------------------------------ |
Engagement-based conditions are powerful for re-engagement and suppression logic — for example, excluding customers who have not opened any of the last 5 messages from a re-engagement campaign, or targeting customers whose engagement has dropped over a defined period.
**Orders count** — Total number of orders placed.
| Operators | `>`, `<`, `>=`, `<=`, `=`, `between` |
| --------- | ------------------------------------ |
**Total spent** — Cumulative order value across all orders.
| Operators | `>`, `<`, `>=`, `<=`, `=`, `between` |
| --------- | ------------------------------------ |
**Average order value** — Average value per order.
| Operators | `>`, `<`, `>=`, `<=`, `=`, `between` |
| --------- | ------------------------------------ |
**Days since last order** — Number of days since the customer's most recent order.
| Operators | `>`, `<`, `>=`, `<=`, `=`, `between` |
| --------- | ------------------------------------ |
**Days since first order** — Number of days since the customer's first-ever order.
| Operators | `>`, `<`, `>=`, `<=`, `=`, `between` |
| --------- | ------------------------------------ |
**Purchased collection** — Whether the customer has purchased from a specific Shopify collection.
| Operators | in / not in |
| --------- | ----------- |
**Purchased brand** — Whether the customer has purchased products from a specific brand (vendor).
| Operators | in / not in |
| --------- | ----------- |
**Purchased price range** — Whether the customer has purchased products within a specific price range.
| Operators | between / not between |
| --------- | --------------------- |
Purchase history conditions are the foundation of lifecycle segmentation — separating first-time buyers from repeat customers, identifying high-LTV customers, building lapsed-buyer segments based on days since last order, and targeting customers by product category.
**Country** — Customer's country from their Shopify profile.
| Operators | is / is not / in / not in |
| --------- | ------------------------- |
**Language** — Customer's locale/language setting.
| Operators | is / is not / in / not in |
| --------- | ------------------------- |
**Consent status** — Customer's current `marketing_state`.
| Operators | is / is not (Yes / No / Unknown) |
| --------- | -------------------------------- |
**Lifecycle stage** — Customer's current lifecycle stage in Galantis.
| Operators | is / is not / in / not in |
| --------- | ------------------------- |
Country and language conditions are essential for international stores sending localized content — defining separate segments per market and routing them to language-appropriate templates is the standard pattern for multi-region campaigns.
Adding `Consent status = Yes` as a rule to any segment ensures the segment only contains `SUBSCRIBED` customers — which means the segment can be used as a campaign audience without the consent filter removing customers at send time.
## Full rule condition reference
| Rule | Available operators |
| ---------------------- | ----------------------------------------- |
| Phone number | exact match |
| Added to list | in list |
| Last message received | date comparison |
| Last engaged at | before / after / between / in last X days |
| Orders count | `>`, `<`, `>=`, `<=`, `=`, `between` |
| Total spent | `>`, `<`, `>=`, `<=`, `=`, `between` |
| Days since last order | `>`, `<`, `>=`, `<=`, `=`, `between` |
| Days since first order | `>`, `<`, `>=`, `<=`, `=`, `between` |
| Average order value | `>`, `<`, `>=`, `<=`, `=`, `between` |
| Country | is / is not / in / not in |
| Language | is / is not / in / not in |
| Consent status | is / is not (Yes / No / Unknown) |
| Purchased collection | in / not in |
| Purchased brand | in / not in |
| Purchased price range | between / not between |
| Messages received | `>`, `<`, `>=`, `<=`, `=`, `between` |
| Messages read | `>`, `<`, `>=`, `<=`, `=`, `between` |
| Automation completions | `>`, `<`, `>=`, `<=`, `=`, `between` |
| Lifecycle stage | is / is not / in / not in |
## How segment evaluation works
When a segment is evaluated, Galantis runs the rule query against all customer records, syncs the membership pivot table, and emits `UserAddedToSegment` events for customers who newly match the rules — customers who matched before evaluation and still match do not generate a new event.
This event-driven mechanism is what powers the `USER_ADDED_TO_SEGMENT` automation trigger. When a customer's data changes — a new order pushes them over a spending threshold, a tag is added, days since last order increments — the next segment evaluation detects the membership change and fires the trigger for that customer.
## Building effective segments
**A high-LTV lapsed buyer segment**
```
Total spent > [your LTV threshold]
AND Days since last order > 60
AND Consent status = Yes
```
Pairs with the [VIP Win-Back automation recipe](/whatsapp/automations/recipes/vip-win-back).
**A first-time buyer cross-sell segment**
```
Orders count = 1
AND Days since last order < 14
AND Consent status = Yes
```
Customers who made their first purchase in the last 2 weeks — a high-intent window for a second-purchase prompt.
**A Mexico high-spend segment**
```
Country = MX
AND Total spent > 500
AND Consent status = Yes
```
Market-specific high-value audience for a localized campaign.
**A re-engagement suppression segment**
```
Last engaged at > 90 days ago
AND Messages received > 5
```
Customers who have received multiple messages but haven't engaged in 90 days — useful as a campaign exclusion to protect deliverability.
## Best practices
* **Always include `Consent status = Yes` in segments used as campaign audiences.** This ensures the segment only contains `SUBSCRIBED` customers and prevents the consent filter from silently reducing your reach at send time.
* **Use segments as automation exclusions for active sequence participants.** If a customer is enrolled in a post-purchase sequence, a segment defined as `Automation completions < 1 for [post-purchase automation]` can be used as an exclusion to prevent them from being enrolled in a separate re-engagement flow simultaneously.
* **Name segments clearly and include the defining criteria.** `High LTV Lapsed - MX - >500 spent` is more useful than `Segment 3` when you are selecting an audience in the campaign builder.
* **Build and verify segments before referencing them in automations.** A segment used as a trigger source or exclusion rule should have its membership count and rule logic confirmed before the automation is activated.
* **Do not over-segment.** A large number of similar, slightly different segments becomes difficult to maintain. Prefer fewer, well-defined segments that cover clear lifecycle stages or targeting needs.
## Related guides
* [Lists](./lists) — Static groups that complement dynamic segments
* [Consent & Opt-outs](./consent-optouts) — How consent state maps to the `Consent status` segment rule
* [Automations — Triggers](/whatsapp/automations/triggers) — USER\_ADDED\_TO\_SEGMENT trigger behavior
* [Automations — Conditions](/whatsapp/automations/conditions) — SEGMENT\_MEMBERSHIP condition in flow branching
* [Campaigns — Audience Targeting](/whatsapp/campaigns/audience-targeting) — Using segments as campaign audience sources
# Actions
Source: https://docs.digifist.com/galantis/whatsapp/automations/actions
Action nodes and Delay nodes — the execution steps that send messages and control timing in automation flows.
Actions are what a flow actually does. In Galantis automations, two node types produce execution behavior: the **Action Node**, which sends a WhatsApp template to the customer, and the **Delay Node**, which pauses execution for a defined period before the next step runs. Every meaningful automation contains at least one of each.
## What this covers
* Action Node configuration and template assignment
* Delay Node configuration and available time units
* Variable mapping in action nodes
* How action execution is tracked
## Action Node
The Action Node sends an approved WhatsApp template to the customer at the point in the flow where it is placed. It is the only node type that dispatches a message.
### Configuring an Action Node
Click the Action Node to open its settings panel. Select an approved template from the template picker. Only templates with `APPROVED` status are available for selection.
For each variable placeholder in the selected template (`{{1}}`, `{{2}}`, etc.), assign a value from the available customer or order data fields, or enter static text.
Available variable sources:
* `customer.first_name`, `customer.last_name`, `customer.email`, `customer.phone`
* `order.order_number`, `order.total_price`, `order.product_name`
* Store name
* Custom static text
See [Campaigns — Personalization](/whatsapp/campaigns/personalization) for the full variable mapping reference — the same data sources apply in automations.
Save the node. If the assigned template is not `APPROVED`, the node will be flagged during validation and the automation cannot be activated until the template is approved.
### Template approval requirement
Action Nodes can only use templates with `APPROVED` status. An automation with any Action Node referencing an unapproved template is flagged and blocked from activation. This check runs at activation time — if a template is paused by Meta after the automation is already active, the affected Action Node will fail for customers who reach it until the template is restored to `APPROVED` status.
If Meta pauses a template used in an active automation, affected messages will fail silently for customers who reach that Action Node. Monitor template status in **Templates** periodically, especially after Meta quality reviews.
### Consent validation at send time
Before an Action Node dispatches a message, Galantis validates the customer's `marketing_state`. Customers with `UNSUBSCRIBED` or `REDACTED` status are skipped — the node execution is recorded as `SKIPPED` in the activity log rather than `FAILED`. This distinction is important: a skip is a correct compliance behavior, not an error.
## Delay Node
The Delay Node pauses the flow for a specific duration before execution moves to the next connected node. It does not send any message — it exists solely to control timing.
### Available delay units
| Unit | When to use |
| --------- | ------------------------------------------------------------------------ |
| `MINUTES` | Short pauses within the same session — e.g., 10–30 minutes after trigger |
| `HOURS` | Same-day delays — e.g., 2–4 hours after an event |
| `DAYS` | Multi-day sequences — e.g., 3 days after a purchase for a cross-sell |
| `MONTHS` | Long-term re-engagement sequences — e.g., 1 month after last purchase |
### Why delays matter
A flow without delays sends messages the instant a trigger fires. For most use cases this produces a poor customer experience — a welcome message arriving in the same second as Shopify's registration confirmation email, or a recovery message sent before the customer has had any time to return on their own.
Delays also affect conversion logic. An abandoned checkout recovery that fires 30 minutes after abandonment catches customers while the intent is still fresh. The same flow with a 3-day delay is largely irrelevant.
A useful pattern for multi-step flows is to place a delay after every action node, not just after the trigger. This creates breathing room between messages in a sequence and reduces the risk of a customer receiving two messages in rapid succession.
### Delay precision and the abandoned checkout offset
For most triggers, delay timing is precise relative to the moment the trigger fires. For `ABANDONED_CHECKOUT`, factor in the 10-minute polling interval — the trigger fires up to 10 minutes after the actual abandonment event, so a 30-minute delay node results in the message arriving 30–40 minutes after the customer abandoned, not exactly 30. See [Triggers](./triggers) for the polling timing detail.
## Related guides
* [Flow Builder](./flow-builder) — Placing and connecting nodes on the canvas
* [Triggers](./triggers) — Trigger events that precede the first Action or Delay node
* [Conditions](./conditions) — Branching nodes that sit between delays and actions
* [Activity Tracking](./activity-tracking) — How Action Node execution is logged per customer
# Activity Tracking
Source: https://docs.digifist.com/galantis/whatsapp/automations/activity-tracking
Per-customer node execution history and the full audit trail for every automation run in Galantis.
Every automation execution in Galantis is recorded in the activity log. Each time a customer passes through a node — whether it completes successfully, is skipped, fails, or is still pending — a record is written with the outcome and a timestamp. This gives you a complete, per-customer audit trail for every flow without any manual tracking.
## What this covers
* The activity log and what it records
* Node execution statuses and what each means
* How to use the activity log for troubleshooting
* What skipped executions indicate
## What is recorded
For every customer enrolled in an automation, Galantis records:
* The automation and the specific flow version they were enrolled in
* Each node they passed through, in sequence
* The status of each node execution
* Timestamps for each status transition
* The reason for any skip or failure
This data is accessible in **Automations → \[Automation Name] → Activity**.
## Node execution statuses
| Status | Meaning |
| ----------- | ----------------------------------------------------------------------------------------------------- |
| `PENDING` | The node is queued — execution has not yet started for this customer at this node |
| `SCHEDULED` | A Delay Node is active — execution is paused and will resume after the delay elapses |
| `COMPLETED` | The node executed successfully — a message was sent, a condition was evaluated, or a delay elapsed |
| `FAILED` | Execution failed — the action could not be completed, typically due to an API error or template issue |
| `SKIPPED` | Execution was bypassed — see below for skip reasons |
### Understanding SKIPPED
`SKIPPED` is not an error. It indicates that Galantis deliberately did not execute the node for a valid reason. Common skip reasons:
* **Consent** — The customer's `marketing_state` changed to `UNSUBSCRIBED` or `REDACTED` between enrollment and reaching this node. Sending the message would violate WhatsApp's policy.
* **Frequency cap** — The customer was already enrolled in this automation within the configured cap window. The trigger was detected but enrollment was suppressed.
* **Exclusion rule** — The customer became a member of an excluded list or segment before reaching this node.
* **Condition branch** — The customer took the YES branch of a Condition Node, so the NO branch nodes were skipped, and vice versa. This is normal flow behavior.
Reviewing skipped executions is particularly useful for diagnosing why a specific customer did not receive an expected message — the skip record shows exactly which check caused the bypass.
## Using the activity log
Go to **Automations → \[Automation Name] → Activity**.
Search or filter by customer name, phone number, or email to find a specific customer's execution record.
The activity log shows each node the customer passed through in order, with its status and timestamp. Trace the path from enrollment through each node to see where execution completed, stalled, or was skipped.
Click a node record to see its full detail — the specific status reason, the template used (for Action Nodes), and any error message for `FAILED` statuses.
## Common troubleshooting scenarios
**Customer enrolled but never received a message**
Check whether any Action Nodes in their execution path show `SKIPPED`. If yes, expand the skip record to see the reason — consent change, frequency cap, or exclusion rule. If all Action Nodes show `COMPLETED`, the message was dispatched — check the message delivery status in **Audience → Contacts → \[Customer] → Messages** for the delivery outcome.
**Customer shows `SCHEDULED` with no further activity**
The customer is currently inside a Delay Node. `SCHEDULED` means the delay is still running — execution will continue automatically when the delay elapses. This is not a stuck state unless the timestamp is significantly older than the configured delay duration.
**Action Node shows `FAILED`**
Expand the failure record to see the error reason. Common causes:
* Template was paused by Meta after the automation was activated — resolve the template issue and re-activate
* Customer's phone number has a format error — review the contact record for a missing country calling code
* Insufficient credits — check billing balance
**Customer was not enrolled at all**
The customer's trigger event fired but they were not enrolled. Check the activity log for a blocked enrollment record. Possible reasons: consent was not `SUBSCRIBED` at trigger time, frequency cap was active, or the customer was a member of an excluded list or segment.
## Related guides
* [Flow Builder](./flow-builder) — Understanding the node structure that activity tracking maps to
* [Frequency Caps](./frequency-caps) — How cap-blocked enrollments appear in the activity log
* [Exclusion Rules](./exclusion-rules) — How exclusion-blocked enrollments appear in the activity log
* [Opt-in & Consent](/whatsapp/compliance/opt-in-consent) — Consent states that cause SKIPPED execution
# Conditions
Source: https://docs.digifist.com/galantis/whatsapp/automations/conditions
Condition nodes, branching logic, and AND/OR grouping for building targeted automation flows.
Condition nodes evaluate data about the customer or their triggering event and split the flow into a YES path and a NO path. They are what makes automations targeted rather than generic — instead of sending the same message to every customer who triggers a flow, conditions let you branch based on order value, purchase history, segment membership, reply behavior, and more.
Every condition branch must connect to at least one subsequent node. A branch that leads nowhere will fail flow validation.
## What this covers
* All ten available condition types
* AND/OR logic and nested grouping
* How to read a condition node's output
* Practical branching patterns
## Condition types
**`MESSAGE_DELIVERY_STATUS`** — Evaluates whether the last message sent to the customer in this flow was delivered or read.
Use this to branch based on whether previous communication reached the customer. A common pattern is to send a recovery message, wait 24 hours, then check delivery status before deciding whether to send a follow-up or exit the flow for undelivered cases.
**Available evaluations:** delivered, read, failed, sent (but not yet delivered or read)
**`USER_REPLY_STATUS`** — Evaluates whether the customer replied to the last message sent in this flow within a defined window.
Use this to suppress a follow-up message when the customer has already engaged. For example: send an initial recovery message, wait 4 hours, check if the customer replied — if YES, exit the flow; if NO, send a reminder.
This condition requires an active conversation window context — it checks for a customer-initiated inbound message after the last outbound action in the flow.
**`ORDER_RECENCY`** — Evaluates how recently the customer placed an order.
Use this to prevent recovery or re-engagement messages from reaching customers who have already purchased since the trigger fired. This is particularly useful in abandoned checkout flows where the customer may have completed a purchase on a different device or channel after abandoning.
**Available operators:** before / after / within last X days
**`CUSTOMER_TAG`** — Evaluates whether the customer currently has a specific Shopify tag on their customer record.
Use this to differentiate treatment based on lifecycle stage, loyalty tier, or any other tag-based segmentation your store uses. For example: branch VIP-tagged customers to a premium offer template while routing standard customers to a general recovery template.
**Available operators:** has tag / does not have tag
**`PRODUCT_IN_ORDER_HAS_TAG`** — Evaluates whether the order that triggered this flow contains a product with a specific Shopify product tag.
Use this to send product-category-specific follow-ups. For example: in a post-purchase cross-sell flow, check whether the triggering order contained a product tagged "Shoes" — if YES, send an accessories recommendation; if NO, route to a different recommendation template.
**Available operators:** contains a product with tag / does not contain a product with tag
**`SEGMENT_MEMBERSHIP`** — Evaluates whether the customer is currently a member of a specific segment.
Use this to apply dynamic audience logic mid-flow. Segment membership is evaluated at the moment the customer reaches the condition node — not at the time the flow was triggered. This means a customer who joins or leaves a segment between trigger and condition evaluation will be routed correctly based on their current state.
**Available operators:** is a member / is not a member
**`ORDER_VALUE`** — Evaluates the total value of the order that triggered this flow.
Use this to differentiate message treatment by order size. The most common pattern is an abandoned checkout flow that routes high-value abandonments to a personalized VIP recovery template and lower-value abandonments to a standard template.
**Available operators:** `>`, `<`, `>=`, `<=`, `=`, `between`
**`ITEM_COUNT_IN_ORDER`** — Evaluates the number of line items in the triggering order.
Use this to differentiate between single-item and multi-item orders, which often warrant different messaging strategies — a customer who bought one item may respond differently to a cross-sell than a customer who already bought multiple products.
**Available operators:** `>`, `<`, `>=`, `<=`, `=`, `between`
**`LIST_MEMBERSHIP`** — Evaluates whether the customer is currently a member of a specific Customer List.
Use this similarly to segment membership, but against static lists rather than dynamic rule-based segments. Useful for suppressing messages to customers on a VIP or do-not-contact list, or for routing list members to a dedicated message variant.
**Available operators:** is a member / is not a member
**`CUSTOMER_COUNTRY`** — Evaluates the customer's country from their Shopify profile.
Use this to localize messaging — routing customers from different markets to templates written in the appropriate language, or applying market-specific offers. Particularly relevant for Galantis's primary markets (LATAM, MENA, India) where a single flow serving multiple countries often needs country-level branching.
**Available operators:** is / is not / in list / not in list
## AND/OR logic and grouping
Multiple conditions can be combined within a single Condition Node using AND and OR operators, and grouped for complex evaluation.
**AND logic within a group** — all conditions in the group must be true for the group to evaluate as true:
```
Order Value > 100
AND Customer Country = MX
→ Both must be true
```
**OR logic between groups** — if any group evaluates as true, the overall condition evaluates as true:
```
(Order Value > 100 AND Customer Country = MX)
OR
(Customer Tag = "VIP")
→ Either group being true is sufficient
```
This structure allows conditions like: "Route to the VIP template if the order is over \$100 from Mexico, OR if the customer is tagged VIP regardless of order value."
Group conditions in the condition node's settings panel by adding rule groups and selecting AND or OR as the inter-group operator.
## Condition reference
| Condition | Evaluates | Key operators |
| -------------------------- | ----------------------------------- | ------------------------------------ |
| `MESSAGE_DELIVERY_STATUS` | Delivery state of last message | delivered / read / failed |
| `USER_REPLY_STATUS` | Whether customer replied | replied / did not reply |
| `ORDER_RECENCY` | Time since last order | before / after / within X days |
| `CUSTOMER_TAG` | Shopify tag presence | has / does not have |
| `PRODUCT_IN_ORDER_HAS_TAG` | Product tag in triggering order | contains / does not contain |
| `SEGMENT_MEMBERSHIP` | Current segment membership | is / is not member |
| `ORDER_VALUE` | Triggering order total | `>`, `<`, `>=`, `<=`, `=`, `between` |
| `ITEM_COUNT_IN_ORDER` | Line item count in triggering order | `>`, `<`, `>=`, `<=`, `=`, `between` |
| `LIST_MEMBERSHIP` | Current list membership | is / is not member |
| `CUSTOMER_COUNTRY` | Customer's country | is / is not / in / not in |
## Best practices
* **Always connect both YES and NO branches.** A condition with an unconnected branch fails validation and blocks activation. Even if the NO path should do nothing, connect it to an explicit exit point or omit the condition if branching is not needed.
* **Use `ORDER_RECENCY` in recovery flows.** An abandoned checkout customer who purchased before the recovery message sends should not receive a recovery message. A recency check before the action node prevents this.
* **Prefer segment conditions for complex audience logic.** Rather than stacking multiple conditions in a single node, consider building a segment that captures the complex logic and using a single `SEGMENT_MEMBERSHIP` condition node. This makes the flow easier to read and the segment independently useful for campaigns.
* **Evaluate country conditions early in international flows.** If a flow needs to send different templates per language, place the country condition node before any action nodes so routing happens before any message is sent.
## Related guides
* [Flow Builder](./flow-builder) — Placing and connecting Condition Nodes on the canvas
* [Actions](./actions) — The Action Nodes that conditions route customers toward
* [Triggers](./triggers) — What data is available from each trigger for condition evaluation
* [Recipes](./recipes/index) — Condition usage in context across common flow patterns
# Exclusion Rules
Source: https://docs.digifist.com/galantis/whatsapp/automations/exclusion-rules
Exclude specific Customer Lists or Segments from an automation entirely, independent of trigger and frequency cap logic.
Exclusion rules let you permanently exclude members of specific Customer Lists or Customer Segments from an automation — regardless of whether they match the trigger, pass the frequency cap, or have `SUBSCRIBED` consent. A customer who is a member of an excluded list or segment will never be enrolled in that automation while the exclusion is in place.
Exclusion rules are configured per automation and complement — rather than replace — consent filtering and frequency caps.
## What this covers
* How exclusion rules work and when they are evaluated
* Configuring list and segment exclusions
* The difference between exclusion rules and frequency caps
* Common exclusion patterns
## How exclusion rules work
When a trigger event fires for a customer, Galantis evaluates the following checks in sequence before enrolling the customer:
1. Is the customer's `marketing_state = SUBSCRIBED`?
2. Is the customer within the frequency cap window?
3. Is the customer a member of any excluded list or segment?
If the customer is a member of an excluded list or segment, they are not enrolled — regardless of the outcomes of checks 1 and 2. The exclusion is recorded in the activity log.
Exclusion rules are evaluated at the moment of trigger — they reflect the customer's list and segment membership at that point in time. A customer added to an excluded list after they have already been enrolled and are mid-flow is not affected retroactively — exclusion prevents enrollment, it does not cancel in-progress executions.
## Configuring exclusion rules
Navigate to **Automations → \[Automation Name] → Settings** (or the exclusion rules panel within the flow configuration).
Select one or more Customer Lists to exclude. Any customer who is a member of a selected list at the time of trigger will be skipped.
Select one or more Customer Segments to exclude. Segment membership is evaluated dynamically at trigger time — a customer who joins the excluded segment after the automation was activated will be excluded from that point forward.
Exclusion rules take effect immediately on save. No re-activation is required.
## Exclusion rules vs frequency caps
Both exclusion rules and frequency caps prevent customers from being enrolled, but they serve different purposes:
| | Exclusion Rules | Frequency Caps |
| -------------- | ------------------------------------------------ | -------------------------------------------- |
| **Based on** | List or segment membership | Time since last enrollment |
| **Scope** | Specific customers in defined groups | All customers, per time window |
| **Permanence** | As long as the customer is a list/segment member | Until the cap window expires |
| **Use case** | Suppress specific audiences entirely | Limit message frequency across all customers |
Use exclusion rules when certain customers should never receive a specific automation. Use frequency caps to control how often any customer can be enrolled.
## Common exclusion patterns
**Suppress recent purchasers from a recovery flow**
Exclude a segment defined as `Days since last order < 3`. Customers who purchased very recently are unlikely to respond to a recovery message and may find it irrelevant or annoying.
**Exclude active automation participants**
If a customer is already enrolled in a high-touch post-purchase sequence, exclude them from a separate re-engagement automation during the same period to avoid sending too many messages simultaneously.
**Suppress a suppression list**
Maintain a "Do Not Contact" Customer List for customers who have requested no messaging outside the standard opt-out flow. Add this list as an exclusion on every automation.
**Exclude VIP customers from standard flows**
If VIP customers receive a separate, dedicated automation, exclude the VIP list from your standard flows to prevent them from receiving both the VIP and the standard messaging sequences.
## Related guides
* [Frequency Caps](./frequency-caps) — Time-based enrollment limits per customer
* [Audience — Lists](/whatsapp/audience/lists) — Creating and managing Customer Lists for use as exclusions
* [Audience — Segments](/whatsapp/audience/segments) — Creating dynamic segments for exclusion rules
* [Activity Tracking](./activity-tracking) — How exclusion-blocked enrollments are recorded
# Flow Builder
Source: https://docs.digifist.com/galantis/whatsapp/automations/flow-builder
The visual node-based editor for building, configuring, and activating WhatsApp automation flows in Galantis.
The Flow Builder is the canvas where automation flows are designed. It presents a node-based graph interface — each step in the flow is a node, nodes are connected by edges that represent execution paths, and the full flow is stored as a structured JSON object of `nodes` and `edges` arrays. Every node has a visual position on the canvas that reflects the logical sequence of the flow.
Building a flow means placing nodes, connecting them in order, configuring each node's settings, and activating when the flow is ready.
## What this covers
* The Flow Builder interface and canvas layout
* Node types and how they connect
* How flows are stored
* Activating and deactivating flows
* AI-assisted flow creation via Galantis AI
## Opening the Flow Builder
In the Galantis dashboard, go to **Automations** and click **New Automation**, or open an existing automation to edit its flow.
The Flow Builder canvas loads with an empty canvas or the existing flow. A `TriggerNode` is always present as the entry point — it cannot be removed or repositioned to a non-entry position.
Drag nodes onto the canvas from the node panel or click the `+` connector on any existing node to add a new step. Connect nodes by drawing edges between them.
Click any node to open its settings panel. Configure the trigger event, delay duration, condition logic, or template assignment depending on the node type.
When the flow is complete, Galantis runs validation checks before activation. Resolve any flagged issues, then toggle the automation to **Active**.
## Node types
Every flow is built from four node types. Each type has a specific role in the execution sequence.
**TriggerNode** is the entry point of every flow. It defines the event that starts the automation and accepts exactly one trigger per flow.
Every automation has exactly one `TriggerNode` — it cannot be duplicated or placed mid-flow. The trigger fires when a qualifying event occurs for a customer, enrolling them into the flow from this point.
Configuration includes:
* The trigger event type (see [Triggers](./triggers) for all available options)
* Whether to include existing users who already match the trigger condition at activation time (`include_existing_users`)
The `TriggerNode` connects to the first step in the flow — typically a `DelayNode` or `ConditionNode`.
**DelayNode** pauses flow execution for a defined duration before the next node runs. It does not send any message — it simply holds the customer at that position in the flow until the delay elapses.
Available delay units: `MINUTES`, `HOURS`, `DAYS`, `MONTHS`.
Delays are essential for timing flows correctly. A welcome message sent 10 minutes after registration feels deliberate. The same message sent within seconds feels automated and impersonal. An abandoned checkout recovery sent 30 minutes after abandonment arrives while the session is still fresh.
Add a delay after every trigger before the first action node. Sending immediately on trigger — especially for events like New Order Placed or New Customer Created — can make messages arrive simultaneously with Shopify's own transactional emails, reducing impact.
**ConditionNode** evaluates a condition against the customer's data and branches the flow into a **YES** path and a **NO** path. Both paths must connect to at least one subsequent node — a condition branch that leads nowhere will fail validation.
Conditions support AND/OR logic and nested grouping for complex evaluations. See [Conditions](./conditions) for the full list of available condition types and operators.
Every condition branch should lead to an action or a further delay — avoid creating condition branches that only lead to more conditions without any eventual action, as these create flows that enroll customers but never send them anything.
**ActionNode** executes the send of an approved WhatsApp template to the customer. This is the node that actually dispatches a message.
Configuration includes:
* Selecting an approved template
* Mapping template variables to customer or order data fields
An automation with an action node whose assigned template is not `APPROVED` will be flagged during validation and cannot be activated.
See [Actions](./actions) for full Action node configuration details.
## How flows are stored
Flows are stored as structured JSON with two arrays:
* **`nodes`** — an array of node objects, each with a type, configuration, and canvas position
* **`edges`** — an array of connection objects defining which node connects to which
This structure is managed automatically by the Flow Builder canvas. You do not edit the JSON directly — changes made on the canvas are persisted to the underlying structure on save.
## Flow validation
Before a flow can be activated, Galantis runs a set of validation checks:
| Check | What is validated |
| --------------------------- | ----------------------------------------------------------------------------- |
| Template approval | All Action nodes use `APPROVED` templates |
| Node connections | All nodes are connected — no orphaned nodes |
| Condition branches | Both YES and NO branches of every Condition node connect to a subsequent node |
| Condition completeness | All condition logic is fully configured with no empty fields |
| Frequency cap configuration | Frequency cap is set and valid |
Validation errors are surfaced inline on the canvas — flagged nodes are highlighted and the specific issue is described in the node's settings panel. Resolve all validation issues before attempting to activate.
## Activating and deactivating flows
Toggle the automation status between **Active** and **Inactive** from the automation detail page. Deactivating a flow stops new customers from being enrolled. Customers already in the flow at the time of deactivation continue through their remaining nodes — deactivation does not cancel in-progress executions.
## Galantis AI assistance
The Flow Builder includes AI-powered assistance via Galantis AI. When building or editing a flow, Galantis AI can:
* Suggest appropriate triggers and action sequences based on a goal you describe
* Highlight incomplete or conflicting node configurations
* Surface optimization suggestions — for example, flagging a missing delay in an abandonment recovery flow
See [Galantis AI](/whatsapp/galantis-ai/ai-flow-builder) for the full AI flow builder reference.
## Related guides
* [Triggers](./triggers) — All trigger events and their configuration
* [Conditions](./conditions) — Condition types, operators, and branching logic
* [Actions](./actions) — Action and Delay node configuration
* [Activity Tracking](./activity-tracking) — Monitoring flow execution per customer
# Frequency Caps
Source: https://docs.digifist.com/galantis/whatsapp/automations/frequency-caps
Limit how often an automation can fire for a single customer to prevent over-messaging.
Frequency caps control how often a specific automation can enroll and message a single customer. They are a guardrail against over-messaging — without them, a high-frequency trigger like `ORDER_PLACED` or `USER_ADDED_TO_SEGMENT` could enroll the same customer multiple times in rapid succession, sending them several messages from the same flow within hours or days.
Every automation should have a frequency cap configured. It is one of the factors Galantis validates before a flow can be activated.
## What this covers
* The five available frequency cap options
* How caps are enforced
* How caps interact with consent filtering
* Choosing the right cap for each automation type
## Available frequency caps
| Cap | Description |
| ---------- | ------------------------------------------------------------------------------------------------------------ |
| `EVER` | The automation fires at most once per customer, ever — regardless of how many times the trigger event occurs |
| `24 hours` | At most once per customer per 24-hour period |
| `7 days` | At most once per customer per 7-day rolling window |
| `14 days` | At most once per customer per 14-day rolling window |
| `30 days` | At most once per customer per 30-day rolling window |
When a customer is blocked by a frequency cap, the trigger event is detected but the customer is not enrolled into the flow for that occurrence. The block is recorded in the automation's activity log.
## How caps are enforced
Frequency caps are evaluated at the trigger level — at the moment a trigger event fires for a customer, Galantis checks whether the customer has been enrolled in this automation within the cap window before proceeding.
If the customer is within the cap window, they are not enrolled for that trigger occurrence. The next trigger event for that customer after the cap window expires will enroll them normally.
## Caps and consent filtering
Frequency caps and consent validation are independent checks that both apply before enrollment:
1. **Consent check** — Is the customer's `marketing_state` = `SUBSCRIBED`? If not, skip.
2. **Frequency cap check** — Has this customer been enrolled within the cap window? If yes, skip.
A customer must pass both checks to be enrolled. Passing the consent check does not bypass the cap, and the cap window does not affect consent status.
## Choosing the right cap
Use **`EVER`** for automations that represent a single lifecycle event — something that should happen once and only once per customer regardless of how many times the underlying trigger fires.
**Best for:**
* New Customer Welcome — a customer should receive a welcome message once, even if they place multiple orders
* VIP tier promotion — a promotion sent when a customer first reaches VIP status should not repeat each time they place an order while VIP-tagged
* Any flow tied to a first-occurrence milestone
`EVER` caps are permanent. Once a customer has been enrolled and the cap is applied, they will never be enrolled in that automation again, even if the automation's content changes significantly. For flows you may want to re-run after a long period, use a `30 days` cap instead.
Use **`7 days`** or **`14 days`** for recovery and re-engagement flows where repetition makes sense across separate purchase cycles but should not occur in rapid succession.
**Best for:**
* Abandoned Checkout Recovery — a customer who abandons multiple checkouts in different sessions should be recoverable each time, but not messaged twice in the same week for two abandonments on consecutive days
* Post-purchase cross-sell — relevant after each purchase, but not multiple times within the same week
A `7 days` cap on an abandoned checkout automation means a customer who abandons twice in the same week is only enrolled on the first abandonment. The second, occurring within 7 days, is skipped.
Use **`24 hours`** for flows tied to transactional events that can legitimately recur daily but should not result in multiple messages on the same day.
**Best for:**
* Order Shipped notifications — a customer who places two orders fulfilled on the same day should not receive two shipping notifications within hours of each other
* Back-in-Stock — a customer subscribed to multiple variants restocked on the same day should receive one notification, not one per variant
For Order Placed and Order Shipped flows, consider whether a `24 hours` cap might inadvertently suppress legitimate messages for customers who genuinely place multiple orders in a day. Evaluate your order frequency data before choosing this cap.
Use **`30 days`** for segment-triggered flows where the underlying segment membership changes regularly and re-enrollment over time is appropriate.
**Best for:**
* Win-back flows triggered when a customer enters a lapsed-buyer segment — a customer who purchases, lapses, is messaged, and then lapses again after another period deserves re-enrollment after a meaningful gap
* Lifecycle nurture flows tied to dynamic segments where customers can exit and re-enter as their data changes
A `30 days` cap ensures the same customer does not receive the same win-back flow repeatedly within a single month, even if segment membership fluctuates.
## Best practices
* **Set a cap on every automation before activating.** An automation without a frequency cap is a configuration gap — even for triggers that seem unlikely to fire repeatedly, a cap provides a safety net.
* **Review cap settings when changing trigger logic.** If you change a trigger from `ORDER_PLACED` to `USER_ADDED_TO_SEGMENT`, the appropriate cap may also change. Revisit cap configuration whenever the trigger is updated.
* **Use `EVER` cautiously on long-lived automations.** A welcome flow with an `EVER` cap is correct. A promotional cross-sell with an `EVER` cap means customers are permanently excluded from that automation after one enrollment — which may not be the intent if the automation runs for years.
## Related guides
* [Exclusion Rules](./exclusion-rules) — Excluding entire lists or segments from an automation, independent of caps
* [Triggers](./triggers) — Trigger frequency affects which cap is most appropriate
* [Activity Tracking](./activity-tracking) — How cap-blocked enrollments are recorded in the activity log
# Automations
Source: https://docs.digifist.com/galantis/whatsapp/automations/index
Event-driven WhatsApp flows that run automatically when a defined trigger occurs — no manual intervention required.
Automations are the core of Galantis's revenue engine. They listen for events in Shopify or the Galantis platform and respond automatically with targeted WhatsApp messages — recovering abandoned checkouts, welcoming new customers, confirming orders, and re-engaging lapsed buyers without any manual work.
Every automation is built with a visual, node-based flow editor. Flows are structured around a single trigger, optional branching conditions, action nodes that send WhatsApp templates, and delay nodes that control timing. Once active, an automation runs continuously against every customer who matches its trigger.
## How automations work
A flow executes one customer at a time, moving through nodes sequentially:
1. **Trigger** fires when a qualifying Shopify or platform event occurs for a customer
2. **Delay** pauses execution for a defined duration before the next step
3. **Condition** evaluates customer or order data and branches the flow YES or NO
4. **Action** sends an approved WhatsApp template to the customer
Each node execution is recorded in the activity log with a status of `PENDING`, `SCHEDULED`, `COMPLETED`, `FAILED`, or `SKIPPED` — giving a full audit trail per customer per run.
## Guides in this section
The visual node-based editor — canvas layout, node types, and flow structure.
All nine available triggers and the Shopify or platform events that fire them.
Action nodes, Delay nodes, and how WhatsApp templates are dispatched.
All condition types, YES/NO branching logic, and AND/OR grouping.
Preventing over-messaging with per-automation send limits.
Excluding specific lists or segments from an automation entirely.
Per-customer node execution history and the full audit trail.
Pre-built flow examples for the most common automation use cases.
## Before building your first automation
Two prerequisites apply to every automation:
* At least one template with `APPROVED` status — automations can only send pre-approved WhatsApp templates. See [Templates](/whatsapp/templates/index).
* A clear understanding of the trigger event and the customer behavior it represents — see [Triggers](./triggers) before configuring your first flow.
If you are setting up automations for the first time, the [First Automation](/whatsapp/getting-started/first-automation) guide walks through a complete end-to-end setup.
## Compliance
Automations validate customer consent status before dispatching any message. Customers with `UNSUBSCRIBED` or `REDACTED` marketing state are skipped automatically, and the skip is recorded in the activity log. Frequency caps apply on top of consent filtering — a customer who is opted in but has already received a message within the cap window will also be skipped.
See [Opt-in & Consent](/whatsapp/compliance/opt-in-consent) and [Frequency Caps](./frequency-caps) for full details.
# Abandoned Checkout Recovery
Source: https://docs.digifist.com/galantis/whatsapp/automations/recipes/abandoned-checkout
Recover customers who started checkout but did not complete — with order value branching for VIP and standard recovery paths.
Abandoned checkout recovery is consistently the highest-ROI automation available to Shopify merchants. Customers who reached checkout showed strong purchase intent — a well-timed, relevant message brings many of them back to complete the order.
This recipe uses an order value condition to split customers into two paths: high-value abandonments receive a personalized VIP recovery message, while standard abandonments receive a general recovery template. A follow-up reminder is sent to all customers 24 hours after the first message.
## Flow structure
```
Trigger: Abandoned Checkout
→ Delay: 30 minutes
→ Condition: Order Value > 100
YES → Action: Send VIP recovery template
NO → Action: Send standard recovery template
→ Delay: 24 hours
→ Action: Send reminder template
```
## Node-by-node breakdown
### Trigger — Abandoned Checkout
**Trigger:** `ABANDONED_CHECKOUT`
Fires when a customer starts a checkout but does not complete it. Galantis polls for abandoned checkouts every 10 minutes, so the trigger fires within 10 minutes of abandonment.
**Recommended frequency cap:** `7 days` — a customer who abandons multiple times in the same week should only receive one recovery sequence. If they abandon again after 7 days, a new sequence is appropriate.
**Recommended exclusion:** Add a segment exclusion for customers who purchased within the last 3 days — this prevents the flow from firing for customers who abandoned one cart but completed a different order recently.
***
### Delay — 30 minutes
A 30-minute delay gives the customer time to complete the purchase on their own before any message is sent. Because the `ABANDONED_CHECKOUT` trigger fires up to 10 minutes after actual abandonment, the total time from abandonment to message delivery is approximately 30–40 minutes.
Avoid reducing this delay significantly — messages arriving within minutes of abandonment can feel intrusive. 30 minutes is long enough to feel considered while the session context is still fresh.
***
### Condition — Order Value > 100
**Condition type:** `ORDER_VALUE`
**Operator:** `>`
**Value:** `100`
Branches the flow based on the total value of the abandoned cart. Adjust the threshold to match your store's AOV — the goal is to identify the top tier of abandoners who warrant a more personalized, higher-effort recovery message.
**YES path** — High-value abandonment. Route to a VIP recovery template with stronger personalization and potentially a more compelling offer.
**NO path** — Standard abandonment. Route to a general recovery template.
Add a second condition for `CUSTOMER_TAG = "VIP"` using OR logic alongside the order value condition to catch high-value customers regardless of the specific abandoned cart value.
***
### Action — VIP recovery template (YES path)
Send a personalized recovery template addressing the customer by name and referencing the abandoned cart value or a specific product. Consider including a time-limited incentive — free shipping or a small discount — for high-value recoveries where the conversion is worth the margin cost.
**Suggested variable mapping:**
* `{{1}}` → `customer.first_name`
* `{{2}}` → `order.total_price`
***
### Action — Standard recovery template (NO path)
Send a general recovery template with a clear CTA linking back to the checkout. Less personalization is needed here — a simple, friendly reminder with a direct link performs well for standard-value abandonments.
**Suggested variable mapping:**
* `{{1}}` → `customer.first_name`
***
### Delay — 24 hours
After both paths complete their first action, the flow converges and waits 24 hours. This is the gap between the initial recovery message and the follow-up reminder.
***
### Action — Reminder template
A single reminder message sent to all customers who received the first recovery message and did not complete their purchase. Keep this message brief — it is a final nudge, not a second pitch.
Consider adding a `USER_REPLY_STATUS` or `ORDER_RECENCY` condition before this final action to suppress the reminder for customers who already replied to the first message or completed a purchase in the 24-hour window. This improves the customer experience and reduces unnecessary sends.
## Templates required
This recipe requires three approved templates:
| Template | Purpose |
| -------------------------- | --------------------------------------------- |
| VIP recovery template | First message — high-value abandonments |
| Standard recovery template | First message — standard abandonments |
| Reminder template | Second message — all non-converting customers |
## Related recipes
* [New Customer Welcome](./new-customer-welcome) — For customers at the start of their lifecycle
* [Post-Purchase Cross-Sell](./post-purchase-cross-sell) — For customers who completed a purchase
## Related guides
* [Triggers](../triggers) — Abandoned Checkout trigger timing and polling behavior
* [Conditions](../conditions) — ORDER\_VALUE condition configuration
* [Frequency Caps](../frequency-caps) — Recommended cap settings for recovery flows
# Back-in-Stock Notification
Source: https://docs.digifist.com/galantis/whatsapp/automations/recipes/back-in-stock-notification
Automatically notify customers when a product variant they subscribed to is restocked.
The back-in-stock notification flow is the delivery engine for the Back-in-Stock module. When a customer subscribes to an out-of-stock variant through the storefront widget, this automation sends them a WhatsApp message the moment that variant's inventory is replenished — no manual intervention required.
This is the simplest recipe in terms of flow structure: a single trigger connected directly to a single action. Its power is in the precision of the delivery — every customer receives a notification only for the specific variant they subscribed to, at the exact moment it becomes available.
## Flow structure
```
Trigger: Back in Stock
→ Action: Send restock notification template with product link
```
## Node-by-node breakdown
### Trigger — Back in Stock
**Trigger:** `BACK_IN_STOCK`
**Source:** Galantis — fires when a subscribed product variant's `inventory_quantity` changes from `0` to a positive value.
This trigger fires only for variants that have active Back-in-Stock subscribers. If a variant is restocked but has no active subscribers, the trigger does not fire. If a variant has 50 active subscribers and is restocked, the trigger fires and the action is executed for all 50 customers.
The trigger is detected via Shopify's `products/update` webhook. When Galantis receives the webhook and detects an inventory change from `0` to `> 0`, it identifies all `ACTIVE` subscriptions for that variant and begins executing this flow for each subscriber.
**Recommended frequency cap:** `24 hours` — protects against edge cases where inventory fluctuates around zero multiple times in the same day, which could otherwise trigger multiple notifications to the same subscriber for the same restock event.
This automation is tightly coupled to the Back-in-Stock widget and subscription system. For the trigger to fire, customers must have subscribed through the widget and their subscription must be in `ACTIVE` status. See [Back-in-Stock — Notification Logic](/whatsapp/back-in-stock/notification-logic) for the full pipeline.
***
### Action — Restock notification template
The restock notification is a high-intent message — the customer explicitly asked to be notified. The template should be direct, confirm the specific product is back, and include a clear link to the product page.
Effective restock notification template elements:
* Confirm what is back in stock (product name and ideally the specific variant — size, color, etc.)
* Create urgency where genuine — if the restock quantity is limited, say so
* A direct link button to the product page using a `URL` button type
## No delay required
Unlike most other recipes, this flow deliberately omits a delay node between the trigger and the action. The customer subscribed specifically to receive this notification the moment the product is available. A delay would reduce the value of the notification — if inventory is limited, customers who subscribed later in the day benefit from a faster notification.
## Consent and subscription guardrails
Before sending, Galantis automatically enforces two guardrails:
1. **Subscription status** — Only customers with `ACTIVE` subscription status receive the notification. Customers with `CANCELLED`, `NOTIFIED`, or `PENDING` subscriptions are excluded.
2. **Consent status** — Customers with `UNSUBSCRIBED` or `REDACTED` `marketing_state` are skipped even if they have an `ACTIVE` subscription.
After a notification is sent, the subscription status moves to `NOTIFIED`. A notified subscription does not receive a second notification if the same variant is restocked again in the future — the customer would need to re-subscribe.
## Templates required
| Template | Purpose |
| -------------------- | ------------------------------------------------------------- |
| Restock notification | Alerts subscriber that their product variant is back in stock |
## Related guides
* [Back-in-Stock — Notification Logic](/whatsapp/back-in-stock/notification-logic) — Full pipeline from inventory webhook to message dispatch
* [Back-in-Stock — Subscription Lifecycle](/whatsapp/back-in-stock/subscription-lifecycle) — Subscription statuses and how they interact with this flow
* [Triggers](../triggers) — BACK\_IN\_STOCK trigger source and behavior
# Automation Recipes
Source: https://docs.digifist.com/galantis/whatsapp/automations/recipes/index
Pre-built flow examples for the most common WhatsApp automation use cases in Galantis.
Recipes are fully documented automation flows built around the most common Shopify merchant use cases. Each recipe shows the complete node sequence — trigger, delays, conditions, and actions — with the reasoning behind each step explained.
Use recipes as a starting point for your own flows. Every recipe can be adapted: add or remove condition branches, change delay durations, swap templates, or extend the sequence with additional steps.
## Available recipes
Recover customers who started checkout but did not complete — with value-based branching for VIP and standard recovery paths.
Trigger product-specific recommendations after an order based on what the customer purchased.
Re-engage high-value lapsed customers when they enter a defined lapsed-buyer segment.
Notify customers automatically when a product variant they subscribed to is restocked.
Send a welcome message with a first-order discount shortly after a new customer registers.
## Before using a recipe
Every recipe sends WhatsApp templates. Before activating any recipe-based automation:
* Create and submit the required templates for Meta approval — see [Templates](/whatsapp/templates/index)
* Configure the appropriate frequency cap for the automation's use case — see [Frequency Caps](../frequency-caps)
* Add any relevant exclusion rules — see [Exclusion Rules](../exclusion-rules)
Templates must reach `APPROVED` status before the automation can be activated.
# New Customer Welcome
Source: https://docs.digifist.com/galantis/whatsapp/automations/recipes/new-customer-welcome
Send a welcome message with a first-order discount shortly after a new customer registers on your Shopify store.
A welcome automation is the first impression your brand makes on WhatsApp. It arrives shortly after a customer creates an account or places their first order — reinforcing the relationship, setting expectations, and typically offering an incentive to drive a second purchase. It is one of the most consistently high-performing automations across Shopify stores for its simplicity and the warmth of the timing.
## Flow structure
```
Trigger: New Customer Created
→ Delay: 10 minutes
→ Action: Send welcome template with first-order discount
```
## Node-by-node breakdown
### Trigger — New Customer Created
**Trigger:** `CUSTOMER_CREATED`
**Source:** Shopify — fires via the `customers/create` webhook when a new customer record is created.
A new customer record is created in Shopify when a customer registers an account or completes their first checkout as a guest who is then saved as a customer.
**Recommended frequency cap:** `EVER` — a customer should receive a welcome message exactly once. Using `EVER` ensures that even if the customer's data triggers the webhook multiple times (edge case), only one welcome message is sent.
**Important:** This trigger fires for every new customer regardless of consent status. Galantis validates `marketing_state` before dispatching the action — only customers with `SUBSCRIBED` consent will receive the message. Consent is collected at the Shopify checkout opt-in step, which typically occurs in the same session that creates the customer record.
***
### Delay — 10 minutes
A 10-minute delay is long enough to avoid the message arriving simultaneously with Shopify's own registration confirmation email or order confirmation, while being short enough that the customer is still in the context of having just interacted with your store.
This is a deliberate timing choice — not a technical requirement. The welcome message landing 10 minutes after registration feels attentive. The same message arriving 3 days later loses all of its warmth and immediacy.
For customers who registered through a first purchase (rather than a standalone account creation), consider whether 10 minutes is still appropriate — if the Shopify order confirmation, shipping confirmation, and welcome message all arrive within a short window, the experience may feel crowded. A 30-minute delay is a reasonable alternative if your onboarding sends are dense.
***
### Action — Welcome template with first-order discount
The welcome template is the first WhatsApp message a customer receives from your brand. The goals are: reinforce that they are connected to your WhatsApp channel, deliver any promised incentive (first-order discount), and invite engagement.
Effective welcome template elements:
* Address the customer by name
* Acknowledge the relationship ("Welcome to \[Store Name]")
* Deliver the first-order discount code using a `COPY_CODE` button — customers can copy it directly from the WhatsApp message
* A secondary `URL` button linking to your store or a featured collection
**Suggested variable mapping:**
* `{{1}}` → `customer.first_name`
* `{{2}}` → static text with the discount code (e.g., `WELCOME10`)
Use a `COPY_CODE` button type for the discount code rather than including it inline in the body text. The button makes the code instantly copyable on mobile, reducing friction between receiving the message and applying the discount.
## Extending this recipe
**Add a follow-up step**
Extend the sequence with a second message 3–5 days after the welcome — a "getting started" or "our most popular products" message that drives the customer back to the store before their interest fades.
**Add a condition before the action**
Insert an `ORDER_RECENCY` condition before the action to check whether the customer already placed an order in the 10-minute window since registering (possible for customers who registered via checkout). If they have already purchased, skip the discount message and send a simpler welcome instead.
**Localize for different markets**
If your store serves multiple language markets, add a `CUSTOMER_COUNTRY` condition after the delay to route customers to language-appropriate welcome templates.
## Templates required
| Template | Purpose |
| --------------------------------- | ----------------------------------------- |
| Welcome with first-order discount | Initial welcome message for new customers |
## Related recipes
* [Abandoned Checkout Recovery](./abandoned-checkout) — For customers who showed intent but did not complete a purchase
* [Post-Purchase Cross-Sell](./post-purchase-cross-sell) — The next automation in a customer's lifecycle after first purchase
## Related guides
* [Triggers](../triggers) — CUSTOMER\_CREATED trigger and consent timing considerations
* [Frequency Caps](../frequency-caps) — Why EVER is the correct cap for welcome flows
* [Templates — Variables & Localization](/whatsapp/templates/variables-localization) — Setting up COPY\_CODE buttons and variable mapping
# Post-Purchase Cross-Sell
Source: https://docs.digifist.com/galantis/whatsapp/automations/recipes/post-purchase-cross-sell
Send product-specific recommendations after an order based on what the customer purchased.
Post-purchase cross-sell flows turn completed orders into additional revenue by recommending relevant complementary products while the customer's purchase intent is still high. The key to relevance is branching on what was purchased — a customer who bought shoes is a natural candidate for an accessories recommendation, while a customer who bought a completely different category warrants a different message or no message at all.
This recipe branches on product tag to send category-specific cross-sell recommendations.
## Flow structure
```
Trigger: New Order Placed
→ Condition: Product in Order Has Tag = "Shoes"
YES → Delay: 3 days
→ Action: Send accessories recommendation template
NO → (exit — no message sent for other categories)
```
## Node-by-node breakdown
### Trigger — New Order Placed
**Trigger:** `ORDER_PLACED`
Fires immediately when a Shopify order is created. The triggering order's product data — including product tags — is available for condition evaluation.
**Recommended frequency cap:** `7 days` — prevents customers who place multiple orders in the same week from receiving multiple cross-sell messages from the same automation. Each order is a valid trigger over time, but daily sends from the same flow are excessive.
***
### Condition — Product in Order Has Tag = "Shoes"
**Condition type:** `PRODUCT_IN_ORDER_HAS_TAG`
**Tag value:** `"Shoes"`
Evaluates whether any product in the triggering order carries the specified Shopify product tag. If the order contains at least one product tagged "Shoes," the customer takes the YES path.
The NO path exits without sending a message in this recipe — it is reserved for customers whose orders do not contain the targeted product category. Extend the flow by adding additional condition branches for other product tags if you want to send category-specific recommendations for multiple product types.
To handle multiple product categories in a single flow, stack multiple condition nodes — one per category — each on the NO branch of the previous. Each YES branch leads to its own delay and action. This creates a linear evaluation where each customer is routed to the first category that matches their order.
***
### Delay — 3 days
A 3-day delay gives the customer time to receive and experience the purchased product before the recommendation arrives. Cross-sell messages sent immediately after purchase can feel transactional. A 3-day gap feels like a helpful follow-up rather than an immediate upsell.
Adjust the delay based on your product type — physical goods that take time to arrive may warrant a longer delay (5–7 days) timed closer to the expected delivery date.
***
### Action — Accessories recommendation template
Send a template recommending accessories or complementary products relevant to what the customer purchased. Use a product-specific template if you have one, or a general accessories recommendation with a curated collection link.
**Suggested variable mapping:**
* `{{1}}` → `customer.first_name`
* `{{2}}` → `order.product_name` (the purchased product for context)
## Extending this recipe
**Add more product categories**
Chain additional `PRODUCT_IN_ORDER_HAS_TAG` conditions on the NO path of the first condition to handle other categories — skincare, electronics, apparel, and so on — each routing to its own relevant recommendation template.
**Add an order value filter**
Before the product tag condition, add an `ORDER_VALUE > X` condition to limit cross-sell messages to orders above a certain threshold — focusing effort on higher-value customers.
**Add a purchase recency check**
After the delay, add an `ORDER_RECENCY` condition to check whether the customer has already placed another order since the trigger fired. If they have, skip the cross-sell — they are already engaged.
## Templates required
This recipe requires one approved template per active product category branch:
| Template | Purpose |
| -------------------------- | ------------------------------------------------------------------------ |
| Accessories recommendation | Cross-sell message for customers who purchased from the "Shoes" category |
Add one template per additional category branch if extending the recipe.
## Related recipes
* [Abandoned Checkout Recovery](./abandoned-checkout) — For customers who did not complete a purchase
* [VIP Win-Back](./vip-win-back) — For customers who purchased historically but have lapsed
## Related guides
* [Conditions](../conditions) — PRODUCT\_IN\_ORDER\_HAS\_TAG condition configuration
* [Triggers](../triggers) — ORDER\_PLACED trigger behavior and data availability
# VIP Win-Back
Source: https://docs.digifist.com/galantis/whatsapp/automations/recipes/vip-win-back
Re-engage high-value lapsed customers the moment they enter a defined lapsed-buyer segment.
Win-back flows target customers who have a strong purchase history but have stopped buying. The VIP win-back recipe is specifically aimed at high-lifetime-value customers — the segment of buyers most worth the effort of a direct, personalized re-engagement message with an exclusive offer.
The power of this recipe lies in the trigger: instead of running on a scheduled basis, it fires automatically the moment a customer's data causes them to enter the lapsed segment. There is no manual list building or campaign scheduling required.
## Flow structure
```
Trigger: User Added to Segment ("High LTV - Lapsed")
→ Delay: 1 hour
→ Action: Send exclusive win-back offer template
```
## Node-by-node breakdown
### Trigger — User Added to Segment
**Trigger:** `USER_ADDED_TO_SEGMENT`
**Segment:** "High LTV - Lapsed"
Fires when a customer newly matches the rules of the defined segment and is added to its membership. The trigger fires only on the transition into membership — customers who were already in the segment when the automation was activated are not enrolled unless `include_existing_users` is enabled.
**Defining the segment**
The "High LTV - Lapsed" segment is a dynamic, rule-based segment you build in **Audience → Segments**. A typical rule structure:
```
Total spent > [your high LTV threshold]
AND Days since last order > [your lapse threshold, e.g., 60]
```
Adjust the thresholds to match your store's data. A fashion brand with frequent repeat purchases might define lapse as 30 days; a furniture brand with longer purchase cycles might set it at 180 days.
**Recommended frequency cap:** `30 days` — a customer who lapsed, was messaged, purchased, and then lapsed again after another period deserves re-enrollment after a meaningful gap. `30 days` prevents the same customer from receiving the win-back multiple times within a single month if their data fluctuates around the lapse threshold.
***
### Delay — 1 hour
A 1-hour delay between segment entry and message send is a short buffer that prevents the message from arriving in the same moment the segment evaluation runs. It also avoids the awkwardness of a customer receiving a lapse message immediately after an event that pushed them into the lapsed state (such as a price change affecting their total spend calculation).
This delay can be extended if preferred — 6 or 12 hours is also reasonable. The goal is to avoid a message that feels instantaneous in response to a data change the customer is unaware of.
***
### Action — Exclusive win-back offer template
The win-back template for high-LTV customers should reflect their value to your store. This is not the moment for a generic promotional message — customers who spent significantly with your brand respond better to personalized acknowledgment and an offer that feels exclusive.
Effective elements for a VIP win-back template:
* Address the customer by name
* Acknowledge the relationship without being heavy-handed ("We've missed you" is sufficient; detailed purchase history recaps feel surveillance-like)
* A genuinely exclusive offer — a discount not available in standard campaigns, early access to a new collection, or free shipping that is not broadly advertised
**Suggested variable mapping:**
* `{{1}}` → `customer.first_name`
## Building the segment
The "High LTV - Lapsed" segment drives this entire flow. Before activating the automation, build and verify the segment in **Audience → Segments**:
1. Set a `Total spent` threshold that reflects your definition of high LTV
2. Set a `Days since last order` threshold that reflects your definition of lapsed
3. Add `Consent status = SUBSCRIBED` as a rule to exclude non-opted-in customers from the segment entirely — this prevents the trigger from firing for customers who cannot be messaged
4. Review the initial membership count — if the segment is very large, consider increasing the LTV threshold to focus on your top tier before activating with `include_existing_users`
If you activate this automation with `include_existing_users` enabled and the segment already has thousands of members, a large batch of win-back messages will be sent within a short period. Review your credit balance and consider activating without `include_existing_users` first to let the flow run on new entrants only.
## Templates required
| Template | Purpose |
| ------------------ | --------------------------------------------------- |
| VIP win-back offer | Re-engagement message for high-LTV lapsed customers |
## Related recipes
* [Abandoned Checkout Recovery](./abandoned-checkout) — For customers who showed intent but did not purchase
* [New Customer Welcome](./new-customer-welcome) — For customers at the beginning of their lifecycle
## Related guides
* [Triggers](../triggers) — USER\_ADDED\_TO\_SEGMENT trigger and include\_existing\_users behavior
* [Audience — Segments](/whatsapp/audience/segments) — Building the lapsed buyer segment
* [Frequency Caps](../frequency-caps) — Recommended 30-day cap for segment-triggered flows
# Triggers
Source: https://docs.digifist.com/galantis/whatsapp/automations/triggers
The nine automation triggers available in Galantis — the Shopify and platform events that start a flow.
A trigger is the entry point of every automation. It defines the event that enrolls a customer into the flow. When that event fires for a qualifying customer, Galantis starts executing the flow from the `TriggerNode` for that customer — independently of any other customer's execution.
Every automation has exactly one trigger. Choosing the right trigger is the most consequential decision in flow design — it determines which customer behavior the automation responds to and when the first message can reach the customer.
## What this covers
* All nine available triggers with their source and description
* The `include_existing_users` option
* Trigger-specific notes and timing considerations
## Available triggers
### Order Placed
**Trigger:** `ORDER_PLACED`
**Source:** Shopify — fires when a new order is created via the `orders/create` webhook.
Fires immediately when a customer completes a purchase. The triggering order's data (order number, total price, product names, tags) is available in condition nodes and action variable mapping for this flow.
Common uses: order confirmation messages, post-purchase cross-sell sequences, review request flows.
Galantis receives this trigger via Shopify's `orders/create` webhook — it fires on every new order, including orders placed through all sales channels connected to your Shopify store, not only your online storefront.
***
### Order Cancelled
**Trigger:** `ORDER_CANCELLED`
**Source:** Shopify — fires via the `orders/cancelled` webhook.
Fires when an order is cancelled in Shopify, regardless of who initiated the cancellation. Use with a `CUSTOMER_TAG` or `ORDER_VALUE` condition to segment your response — for example, sending a win-back offer to high-value cancelled orders while sending a simpler acknowledgment to lower-value ones.
***
### Order Shipped
**Trigger:** `ORDER_SHIPPED`
**Source:** Shopify — fires when a fulfillment is created via the `orders/updated` webhook with shipping data.
Fires when an order is marked as fulfilled and a tracking number is available. Use for shipping confirmation messages and delivery update flows.
### New Customer Created
**Trigger:** `CUSTOMER_CREATED`
**Source:** Shopify — fires via the `customers/create` webhook.
Fires when a new customer record is created in Shopify — typically at the point of first purchase or account registration. This is the standard entry point for welcome sequences.
Add a delay of 10–15 minutes after this trigger before the first action. New customers typically receive a Shopify registration or order confirmation email almost immediately — a short delay prevents your WhatsApp message from arriving in the same moment and reduces the sense of automated messaging.
***
### Customer Tagged
**Trigger:** `CUSTOMER_TAGGED`
**Source:** Shopify — fires via `customer_tags/added` webhook when a specific tag is added to a customer record.
Fires when a defined tag is applied to a customer in Shopify, either manually or through a Shopify Flow or third-party app. Useful for lifecycle-based triggers — VIP promotion, loyalty tier upgrades, or any workflow where a Shopify tag signals a status change.
Configuration requires specifying the exact tag string to listen for. Only the defined tag fires this trigger — other tags added to the same customer do not.
### Abandoned Checkout
**Trigger:** `ABANDONED_CHECKOUT`
**Source:** Shopify — polled every 10 minutes via the Shopify Admin API.
Fires when a customer starts a checkout but does not complete it. Because Shopify does not emit a real-time webhook for abandoned checkouts, Galantis polls for them on a 10-minute interval. This means the trigger fires at most 10 minutes after abandonment occurs, not instantly.
This is typically the highest-ROI automation trigger available — abandoned checkout recovery consistently drives significant recovered revenue.
The 10-minute polling interval means there is an inherent delay between the moment a customer abandons and when the trigger fires. Account for this when configuring your first delay node — a 30-minute delay after the trigger results in the customer receiving the message approximately 30–40 minutes after abandonment, not exactly 30 minutes.
### User Added to List
**Trigger:** `USER_ADDED_TO_LIST`
**Source:** Galantis — fires when a customer is added to a specific Customer List.
Fires when a customer is manually added to a defined list, imported into it, or added programmatically. Useful for triggering flows based on internal list management — for example, a flow that fires when a customer is added to a "VIP" or "Re-engagement" list.
Configuration requires specifying which list to listen for. Adding a customer to a different list does not fire this trigger.
***
### User Added to Segment
**Trigger:** `USER_ADDED_TO_SEGMENT`
**Source:** Galantis — fires when a customer newly matches a segment's rules and is added to segment membership.
Fires when segment evaluation runs and a customer moves from non-member to member status for the defined segment. This trigger does not fire for customers who were already members when the automation was activated — it fires only on the transition into membership.
This is particularly powerful for lifecycle-based automation — for example, a flow that fires when a customer crosses into a "High LTV - Lapsed" segment for the first time.
***
### Back in Stock
**Trigger:** `BACK_IN_STOCK`
**Source:** Galantis — fires when a subscribed product variant's inventory changes from `0` to a positive quantity.
Fires when Galantis detects a restock event for a variant that has active subscribers. This trigger is the engine behind the Back-in-Stock notification module. See [Back-in-Stock — Notification Logic](/whatsapp/back-in-stock/notification-logic) for how the restock detection pipeline works.
## Trigger reference
| Trigger | Source | Event |
| ----------------------- | -------- | ----------------------------------------------------- |
| `ORDER_PLACED` | Shopify | New order created |
| `ORDER_CANCELLED` | Shopify | Order cancelled |
| `ORDER_SHIPPED` | Shopify | Order fulfilled/shipped |
| `CUSTOMER_CREATED` | Shopify | New customer registered |
| `CUSTOMER_TAGGED` | Shopify | Specific tag added to customer |
| `ABANDONED_CHECKOUT` | Shopify | Checkout started, not completed (polled every 10 min) |
| `USER_ADDED_TO_LIST` | Galantis | Customer added to a specific list |
| `USER_ADDED_TO_SEGMENT` | Galantis | Customer newly matches a segment's rules |
| `BACK_IN_STOCK` | Galantis | Subscribed variant restocked |
## Include existing users
Every trigger supports an `include_existing_users` option. When enabled at the time of activation, Galantis retroactively enrolls customers who already match the trigger condition — for example, customers who abandoned a checkout before the automation was active, or customers already in a segment when the segment trigger is configured.
When disabled (default), only events that occur after the automation is activated will enroll customers.
Use `include_existing_users` carefully for high-volume triggers like `ORDER_PLACED` or `CUSTOMER_CREATED`. Enabling it on a large existing customer base can generate a significant immediate send volume. Review your frequency caps and credit balance before activating with this option enabled.
## Related guides
* [Flow Builder](./flow-builder) — Building and connecting nodes on the canvas
* [Conditions](./conditions) — Branching logic based on trigger event data
* [Frequency Caps](./frequency-caps) — Controlling how often a trigger can fire per customer
* [Recipes](./recipes/index) — Pre-built flows showing trigger configuration in context
# Analytics
Source: https://docs.digifist.com/galantis/whatsapp/back-in-stock/back-in-stock-analytics
Back-in-Stock performance metrics — active subscriptions, notifications sent, click rate, conversion rate, and revenue attribution.
Back-in-Stock analytics measure the commercial impact of the module — how many customers are waiting for restocked products, how many received notifications, and how many converted to a purchase. Because the pipeline is fully automated, analytics are the primary tool for evaluating whether the module is performing well and identifying opportunities to improve conversion.
## What this covers
* All five available metrics and what each measures
* How to interpret the metrics together
* What good performance looks like
* Using analytics to diagnose pipeline issues
## Metrics
**Active subscriptions** is the count of subscription records currently in `ACTIVE` status — customers who have subscribed and are waiting for a restock notification.
This metric tells you how much pent-up demand exists across your out-of-stock catalog at any given time. A growing active subscription count on a specific product is a signal of strong demand — it can inform restocking decisions and inventory planning beyond its role in the notification pipeline.
**How to read it:**
A high active subscription count on a variant that has been out of stock for a long time may indicate that restocking is overdue. Conversely, a low active subscription count on a frequently out-of-stock variant may indicate the widget is not visible or is not converting visitors to subscribers effectively — check widget placement and copy.
Active subscriptions decrease when:
* Notifications are sent (subscriptions move to `NOTIFIED`)
* Customers cancel (subscriptions move to `CANCELLED`)
* Customers opt out of WhatsApp marketing (subscriptions remain `ACTIVE` but become ineligible for notification dispatch)
Review active subscription counts before planning a restock. A variant with 500 active subscribers warrants a different restocking quantity decision than one with 5 — and both warrant a WhatsApp notification campaign at launch.
**Notifications sent** is the total count of WhatsApp restock notification messages successfully dispatched — across all variants, all products, and all time periods within the selected date range.
This is the primary volume metric for the module. It reflects how active your inventory restocking is and how many subscriber notification opportunities the pipeline has processed.
**How to read it:**
Notifications sent in isolation is a volume number — it becomes meaningful when compared against active subscriptions and conversion rate. A high notifications sent count with a low conversion rate suggests the notification content or timing is not driving action. A low notifications sent count may indicate infrequent restocking, low subscription capture, or pipeline issues preventing notifications from firing.
Notifications sent does not equal messages delivered. A dispatched notification may fail delivery due to phone number issues, insufficient credits, or consent state changes. Cross-reference with campaign or automation analytics for delivery confirmation.
**Click rate** is the percentage of notification recipients who tapped the product link in the restock message.
```
Click rate = Clicks ÷ Notifications sent × 100
```
Click rate measures message relevance and CTA effectiveness. A customer who subscribed to a specific variant and receives a notification that confirms that variant is back should have strong motivation to click — a low click rate on a well-configured notification is unusual and worth investigating.
**Common causes of low click rate:**
* The notification arrived significantly after the restock — if a variant sold out again before the subscriber received the notification, clicking the link leads to an out-of-stock page
* The product link in the template is broken or redirects incorrectly
* The notification message does not clearly confirm which product is back and why the customer should act now
* The notification arrived outside of the customer's active hours — a 3 AM notification may be dismissed before it is read
**Conversion rate** is the percentage of notified customers who completed a purchase of the restocked product.
```
Conversion rate = Purchases ÷ Notifications sent × 100
```
Conversion rate is the definitive measure of the module's commercial effectiveness. Back-in-Stock should consistently outperform other campaign types on conversion rate because the audience is self-selected high-intent customers — they actively requested to be notified about this specific product.
**Factors that improve conversion rate:**
* Fast notification dispatch — customers who receive the notification while inventory is still available convert at higher rates
* Urgency signals in the notification template — "Limited stock" performs better than a generic "It's back" message when inventory is genuinely constrained
* A direct product link that takes the customer to the specific variant page, not just the product root page
* Notification timing that reaches the customer during their active hours
**Revenue generated** is the attributed revenue from purchases made by customers who received a Back-in-Stock notification within a defined attribution window.
This metric translates the module's activity into a concrete business outcome — the revenue that would not have been captured without the notification pipeline. It is the primary metric for evaluating ROI and justifying the module's billing cost.
**How to use it:**
Revenue generated should be compared against:
* The cost of notifications sent (credits consumed per notification × credit cost)
* The value of active subscriptions not yet notified (potential revenue awaiting a restock event)
A healthy Back-in-Stock module should produce revenue attribution that clearly exceeds its credit cost — if this ratio is poor, investigate conversion rate and click rate for the optimization opportunities those metrics surface.
## Reading the metrics together
The five metrics form a funnel from subscription capture to revenue:
```
Active subscriptions → How much demand is captured and waiting
↓ Restock event fires
Notifications sent → How many customers were reached
↓ Customer opens message
Click rate → How compelling the notification was
↓ Customer visits product
Conversion rate → How effectively the product page closed the sale
↓ Purchase completed
Revenue generated → The commercial outcome of the full pipeline
```
Each step in the funnel can be optimized independently. A high notifications sent count with low click rate points to the notification content or delivery timing. A high click rate with low conversion rate points to the product page experience or post-click availability. A high conversion rate with low revenue points to low subscription volume — not enough customers are subscribing in the first place.
## Accessing analytics
Navigate to **Back-in-Stock → Analytics** to view the full metrics dashboard. Metrics can be filtered by date range and by specific product or variant to isolate performance for individual items.
## Best practices
* **Review active subscription counts before restocking.** Use the data to inform inventory decisions — a variant with 200 active subscribers is a stronger restocking candidate than one with 3.
* **Monitor click rate after template changes.** If you update the restock notification template, watch for changes in click rate in the first batch of notifications after the change goes live.
* **Investigate any sudden drop in notifications sent.** A drop that does not correspond to fewer restocks may indicate the pipeline is not firing — check for automation deactivation, template approval status, or a failed Shopify webhook connection.
* **Compare conversion rate across product categories.** High-demand categories (limited edition, seasonal) typically convert at higher rates than replenishment restocks (basics, consumables). Separate analysis by product type prevents aggregate metrics from masking underperformance in specific segments.
## Related guides
* [Notification Logic](./notification-logic) — Understanding what drives the notifications sent count
* [Subscription Lifecycle](./subscription-lifecycle) — How subscription status affects the active subscriptions count
* [Back-in-Stock Add-on Billing](/whatsapp/billing/add-ons/back-in-stock) — Credit cost per notification relative to revenue generated
# Back-in-Stock
Source: https://docs.digifist.com/galantis/whatsapp/back-in-stock/index
Capture WhatsApp numbers from customers on out-of-stock product pages and automatically notify them the moment a variant is restocked.
The Back-in-Stock module converts inventory gaps into a recoverable revenue opportunity. When a product variant is out of stock, customers can subscribe through a storefront widget using their WhatsApp number. The moment that variant is restocked in Shopify, Galantis detects the inventory change and dispatches a WhatsApp notification automatically — no manual work, no delay, no missed restock window.
The module has two distinct parts that work together: the **storefront widget**, which captures subscriptions on your live store, and the **notification pipeline**, which listens for restock events and sends the message. Both must be configured for the full flow to work.
## How it works end to end
```
Customer visits out-of-stock product page
→ Widget appears on the variant
→ Customer submits their WhatsApp number
→ Subscription created with ACTIVE status
→ Variant restocked in Shopify
→ Shopify sends products/update webhook
→ Galantis detects inventory_quantity 0 → > 0
→ BACK_IN_STOCK automation trigger fires
→ WhatsApp notification sent to all ACTIVE subscribers
→ Subscription status moves to NOTIFIED
```
## What this section covers
* Installing and verifying the storefront widget
* Customizing widget appearance and branding
* How subscriptions move through their lifecycle
* The full notification pipeline from restock detection to message dispatch
* Per-variant product and inventory rules
* Analytics and conversion metrics
## Guides in this section
Script tag injection, verification steps, and troubleshooting widget display issues.
All branding and appearance settings — button, modal, colors, fonts, and form states.
PENDING, ACTIVE, NOTIFIED, and CANCELLED — how subscriptions transition between states.
The full pipeline from Shopify restock webhook to WhatsApp message dispatch.
Per-variant subscription behavior, subscription limits, and eligibility rules.
Active subscriptions, notification volume, click rate, conversion rate, and revenue attribution.
## Prerequisites
Before the Back-in-Stock module can send notifications:
* Your WhatsApp Business Account must be connected — see [WhatsApp Connection](/whatsapp/getting-started/whatsapp-connection)
* An approved WhatsApp template must exist for the restock notification message — see [Templates](/whatsapp/templates/index)
* The `write_script_tags` Shopify permission must be granted — required for widget injection
Subscription capture (the widget) works independently of the notification template — customers can subscribe before the template is approved. But notifications will not send until an approved template is in place and assigned to the Back-in-Stock automation flow.
## Billing
Back-in-Stock is billed as a separate add-on with two components: a **monthly tier subscription** that determines how many subscribers you can hold (Starter \$19 / 250 subs → Enterprise \$149 / 10,000 subs), and **1 Conversation credit per delivered notification** drawn from the same credit pool as campaigns. **Enterprise core plan includes the Starter BIS tier (250 subscribers) by default.** See [Back-in-Stock Add-on Billing](/galantis/whatsapp/billing/add-ons/back-in-stock) for the full pricing breakdown.
# Notification Logic
Source: https://docs.digifist.com/galantis/whatsapp/back-in-stock/notification-logic
The full pipeline from Shopify restock webhook to WhatsApp notification dispatch for Back-in-Stock subscribers.
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. Galantis 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
Galantis 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](/whatsapp/audience/consent-optouts).
**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](/whatsapp/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](/whatsapp/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](/whatsapp/billing/add-ons/back-in-stock).
## 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
| Cause | Result | How to identify |
| ---------------------------------------------------------- | ------------------------------ | ------------------------------------------------------------------ |
| Subscriber in `PENDING`, `NOTIFIED`, or `CANCELLED` status | Not enrolled | Subscription status in **Back-in-Stock → Subscriptions** |
| Subscriber's `marketing_state` ≠ `SUBSCRIBED` | Skipped — consent check failed | Contact profile in **Audience → Contacts** |
| Subscriber within frequency cap window | Skipped — cap active | Automation activity log |
| Notification template not `APPROVED` | Flow fails for all subscribers | Template status in **Templates** |
| Insufficient credits | Fails after partial dispatch | Billing balance in **Billing → Overview** |
| Phone number missing calling code | `FAILED` per subscriber | Automation activity log, error: `CUSTOMER_IS_MISSING_CALLING_CODE` |
## Related guides
* [Subscription Lifecycle](./subscription-lifecycle) — How subscription statuses affect notification eligibility
* [Product & Inventory Rules](./product-inventory-rules) — Per-variant rules that affect which variants can trigger the pipeline
* [Automations — Recipes — Back-in-Stock Notification](/whatsapp/automations/recipes/back-in-stock-notification) — The automation flow configuration
* [Automations — Activity Tracking](/whatsapp/automations/activity-tracking) — Diagnosing per-subscriber notification outcomes
* [Support — Message Delivery](/whatsapp/support/troubleshooting/message-delivery) — Resolving delivery failures
# Product & Inventory Rules
Source: https://docs.digifist.com/galantis/whatsapp/back-in-stock/product-inventory-rules
Per-variant subscription behavior, eligibility rules, subscription limits, and how inventory quantity drives the Back-in-Stock module.
Back-in-Stock subscriptions operate at the variant level — a customer subscribes to a specific size, color, or option combination of a product, not to the product as a whole. The module's eligibility rules are also applied at the variant level, based on the variant's `inventory_quantity` value in Shopify. Understanding how these rules work ensures the widget appears where it should and notifications fire when they should.
## What this covers
* Why subscriptions are per variant, not per product
* How `inventory_quantity = 0` controls widget eligibility
* Per-variant subscription limits
* Multi-variant and multi-product subscription behavior
* Edge cases in inventory management
## Subscriptions are per variant
When a customer submits their WhatsApp number through the Back-in-Stock widget, Galantis records the subscription against the specific variant they have selected — not against the parent product. The subscription record stores the variant's `selected_options` (e.g., `Size: M, Color: Blue`) to identify exactly which combination the customer is waiting for.
This means:
* A customer subscribed to **Size: M, Color: Blue** will only receive a notification when that exact variant is restocked
* If **Size: L, Color: Blue** restocks, their subscription is not triggered — it is a different variant
* A customer who wants notifications for multiple variants must subscribe separately to each one
This per-variant precision is the correct behavior — a customer waiting for a specific size does not want to be notified that a different size is available, as that does not solve their problem.
## Widget eligibility: inventory\_quantity = 0
The subscription widget only appears on a product page when the currently selected variant has `inventory_quantity = 0` in Shopify. This is evaluated client-side when the customer selects a variant on the product page.
| Variant inventory | Widget visible |
| ------------------------ | ---------------------------- |
| `inventory_quantity = 0` | Yes — widget button appears |
| `inventory_quantity > 0` | No — widget button is hidden |
When a customer switches between variants on a product page, the widget shows or hides dynamically based on the selected variant's inventory. A product page where some variants are in stock and others are out of stock will show the widget only for the out-of-stock selections.
The widget evaluates inventory based on the data embedded in the Shopify product page at load time. A variant that sells out after the page was loaded will not trigger the widget to appear until the page is refreshed. This is a client-side limitation of the script tag injection approach.
## Subscription limits
Galantis supports configurable subscription limits per product and per variant. These limits control how many active subscriptions can exist for a given product or variant at any one time.
**Why limits matter:** For high-demand products, an unlimited subscription list can create notification volume that exceeds your credit balance or overwhelms a limited restock quantity. Setting a per-variant limit ensures the notification list stays proportionate to the inventory you can fulfill.
Subscription limits per product and per variant are configurable in the Galantis dashboard.
## Multi-variant subscriptions
A customer can hold multiple active subscriptions simultaneously — across different variants of the same product and across completely different products. Each subscription is a distinct record and is evaluated independently:
* A customer waiting for **Size: S** and **Size: M** of the same product has two separate subscriptions
* When **Size: S** restocks, only the **Size: S** subscription triggers — **Size: M** remains `ACTIVE` until that variant restocks
* A customer subscribed to variants across three different products will receive up to three separate notifications as each variant restocks, governed by the frequency cap on the automation
There is no enforced limit on how many subscriptions a single customer can hold. Frequency caps on the Back-in-Stock automation control how often a customer can receive notifications within a given time window, regardless of how many active subscriptions they hold. See [Automations — Frequency Caps](/whatsapp/automations/frequency-caps).
## Inventory quantity edge cases
**Partial restocks** — If a variant is restocked with a quantity lower than the number of active subscribers, all subscribers still receive notifications. Galantis does not check whether the restocked quantity is sufficient to fulfill all subscribers — the notification pipeline fires for all `ACTIVE` subscriptions regardless of restock volume. Urgency language in the notification template ("Limited stock — get yours now") reflects the genuine scarcity without Galantis needing to manage allocation.
**Rapid inventory fluctuation** — A variant that restocks and immediately sells out before all notifications are dispatched still triggers the full notification batch. Customers who click the link in their notification may find the product out of stock again. This is expected behavior — the notification is accurate at the moment of dispatch.
**Inventory adjustments that do not represent a true restock** — An inventory correction that moves a variant from `0` to a positive number — for example, a merchant correcting an erroneous zero-inventory entry — will trigger the Back-in-Stock pipeline just as a genuine restock would. Galantis cannot distinguish between a correction and a genuine restock from the webhook payload alone. If inventory corrections are common in your workflow, be aware that they will fire notifications to subscribers.
**Inventory tracking disabled** — If a product in Shopify has inventory tracking disabled, Shopify does not report an `inventory_quantity` for its variants. In this case, the widget will not appear (since Galantis cannot confirm `inventory_quantity = 0`) and the restock trigger cannot fire. Enable inventory tracking in Shopify for any product you want to use with Back-in-Stock.
Back-in-Stock depends entirely on Shopify's inventory data being accurate and tracking being enabled. Products with inventory tracking disabled, products managed by third-party inventory systems that do not sync back to Shopify's native inventory fields, or products with manual stock management that is not reflected in Shopify will not work correctly with the Back-in-Stock module.
## Related guides
* [Subscription Lifecycle](./subscription-lifecycle) — How subscription status controls notification eligibility
* [Notification Logic](./notification-logic) — How the restock detection pipeline uses inventory data
* [Variants & Pricing](/whatsapp/catalog/variants-pricing) — How Galantis stores variant-level inventory data from Shopify
* [Automations — Frequency Caps](/whatsapp/automations/frequency-caps) — Controlling notification frequency for customers with multiple subscriptions
# Subscription Lifecycle
Source: https://docs.digifist.com/galantis/whatsapp/back-in-stock/subscription-lifecycle
How Back-in-Stock subscriptions move through PENDING, ACTIVE, NOTIFIED, and CANCELLED states in Galantis.
Every Back-in-Stock subscription in Galantis has a status that tracks where it is in its lifecycle — from the moment a customer submits their WhatsApp number through to notification delivery or cancellation. Status determines whether a subscriber receives a restock notification and prevents customers from being notified multiple times for the same restock event.
## What this covers
* All four subscription statuses and their meaning
* How status transitions are triggered
* The role of status in notification eligibility
* Viewing and managing subscriptions
## Subscription statuses
| Status | Meaning | Eligible for notification |
| ----------- | -------------------------------------------------------------------- | ------------------------- |
| `PENDING` | Newly submitted — awaiting activation | No |
| `ACTIVE` | Enrolled — will receive a notification when the variant is restocked | Yes |
| `NOTIFIED` | Notification sent — subscription expires after notification | No |
| `CANCELLED` | Customer unsubscribed | No |
Only subscriptions in `ACTIVE` status receive restock notifications. All other statuses are excluded from the notification dispatch.
## Status transitions
### PENDING
A subscription enters `PENDING` status the moment a customer submits their WhatsApp number through the storefront widget. At this point the subscription has been recorded but has not yet been activated.
### ACTIVE
Once activated, the subscription enters `ACTIVE` status and the customer is enrolled to receive a notification when the subscribed variant is restocked. A customer can hold multiple `ACTIVE` subscriptions simultaneously — one per variant they have subscribed to, across different products.
`ACTIVE` is the only status eligible for restock notification dispatch. When the `BACK_IN_STOCK` trigger fires for a variant, Galantis queries all `ACTIVE` subscriptions for that variant and enrolls each one in the notification flow.
### NOTIFIED
After a restock notification is successfully sent, the subscription status moves to `NOTIFIED`. This is a terminal status for that subscription record — a notified subscription does not receive a second notification if the same variant is restocked again.
`NOTIFIED` status provides duplicate notification protection. Without it, a variant that fluctuates between zero and positive inventory multiple times (a common pattern during high-demand restocks) could send repeated notifications to the same customer for the same restock event.
If a customer wants to receive future notifications for the same variant, they must re-subscribe through the widget — which creates a new subscription record in `PENDING` status.
Moving to `NOTIFIED` does not mean the customer received and read the message — it means the notification was dispatched by Galantis. If the message failed to deliver (due to a phone number issue, an expired conversation window, or insufficient credits), the subscription still moves to `NOTIFIED`. Check the automation activity log for delivery status details on the notification message itself.
### CANCELLED
A subscription moves to `CANCELLED` when a customer unsubscribes.
`CANCELLED` subscriptions are permanently excluded from notification dispatch. A cancelled subscription cannot be reactivated — if the customer wants to subscribe again, they must submit a new subscription through the widget.
## Consent state and subscription status
Subscription status and marketing consent (`marketing_state`) are two independent checks that both apply before a notification is sent:
1. **Subscription status must be `ACTIVE`**
2. **Customer's `marketing_state` must be `SUBSCRIBED`**
A customer with an `ACTIVE` subscription but `UNSUBSCRIBED` or `REDACTED` consent status will not receive a notification — the consent check excludes them even though their subscription is technically eligible. This ensures a customer who opted out of WhatsApp marketing through any channel is not messaged via the Back-in-Stock pipeline.
Consent state takes precedence over subscription status. An `ACTIVE` subscription on an `UNSUBSCRIBED` customer will never trigger a notification send. If a customer subscribed through the widget but has since replied STOP to another message, their Back-in-Stock subscription becomes effectively inactive even though its status remains `ACTIVE`.
## Viewing and managing subscriptions
Navigate to **Back-in-Stock → Subscriptions** to view all subscription records. The list can be filtered by status, product, variant, and date range.
Per-subscription details show:
* The customer's WhatsApp number and name
* The specific product and variant subscribed to
* The current status and status history
* The timestamp of subscription creation and any status transition
Individual subscription records can be cancelled by an admin from the subscription detail view — useful for removing subscriptions submitted in error or for customers who request cancellation through a support channel.
## Related guides
* [Widget Installation](./widget-installation) — How subscriptions are created through the storefront widget
* [Notification Logic](./notification-logic) — How `ACTIVE` subscriptions are enrolled into the notification pipeline
* [Product & Inventory Rules](./product-inventory-rules) — Per-variant subscription limits and eligibility
* [Consent & Opt-outs](/whatsapp/audience/consent-optouts) — How `marketing_state` interacts with subscription status
# Widget Design
Source: https://docs.digifist.com/galantis/whatsapp/back-in-stock/widget-design
Customize the Back-in-Stock widget button, subscription modal, and form states to match your brand.
The Back-in-Stock widget is fully customizable from the Galantis dashboard. Every visual element — the subscription button, the modal that opens when a customer taps it, the form colors, and the states shown after submission — is controlled through **Back-in-Stock → Settings** and applied to your storefront immediately when saved.
One configuration applies across your entire storefront.
## What these settings control
* Button position, type, color, font, and label text
* Modal headline and font
* Form background and state colors (default, success, error)
* Font sizing and spacing
## How to access
In the Galantis dashboard, go to **Back-in-Stock → Settings**.
Configure the options described below.
Changes are applied to your storefront immediately after saving — no redeployment needed.
## Settings
**Button position**: Controls where the subscription button appears on the product page.
* **Right** — Bottom-right corner. Default and works for most themes.
* **Left** — Bottom-left corner. Use when your theme places other fixed elements at the bottom-right.
* **Custom** — Precise placement using CSS offset values. Use when neither default position fits your theme layout.
***
**Button type**: Determines the visual style of the button.
* **Pre-designed** — Uses Galantis's built-in button design. Optimized for visibility and mobile tap targets.
* **Custom** — Fully custom button design for stores with strict brand guidelines.
***
**Button background color**: The fill color of the subscription button. Enter a hex value. We recommend using your primary brand color or a high-contrast accent color that stands out against your product page background.
***
**Button font**: The typeface used for the button label text. Enter a font family name. The font must be loaded by your Shopify theme — the widget inherits fonts available on the page.
***
**Button text**: The CTA label displayed on the button. Keep this direct and action-oriented. Common values:
* `Notify me when available`
* `Alert me when back`
* `Get notified`
***
**Button font size and spacing**: Controls the size of the button label text and the internal padding of the button. Adjusting these is useful when your theme's layout makes the default button feel disproportionate.
Test button sizing on mobile. Back-in-Stock subscriptions are most commonly submitted from mobile devices — a button that looks right on desktop may have a tap target that is too small on a phone screen.
The modal is the overlay that opens when a customer taps the subscription button. It contains the headline text, the WhatsApp number input field, and the submit button.
***
**Headline text**: The primary message shown at the top of the subscription modal. This is the customer's first prompt after tapping the button — it should confirm what they are signing up for and set expectations.
Effective headline examples:
* `Get notified on WhatsApp when this is back in stock`
* `We'll message you on WhatsApp the moment it's available`
* `Leave your number and we'll let you know`
***
**Headline font**: The typeface used for the modal headline. Enter a font family name consistent with your store's typography.
***
**Form background color**: The background color of the subscription modal. Use your store's background color or a neutral that keeps the form legible. Avoid colors that reduce contrast against the input field and submit button.
The modal appears on top of your product page content. A form background color that closely matches your page background can make the modal feel like it did not open — use a slightly offset shade or a subtle border to ensure the modal is visually distinct from the page behind it.
The widget displays distinct visual states after the customer interacts with the form. Each state has its own background color to communicate the outcome clearly.
***
**Success background color**: Shown after a customer successfully submits their WhatsApp number. The success state confirms the subscription was recorded and sets the expectation that they will receive a WhatsApp message when the product is back.
Use a color that communicates a positive outcome — green or your brand's success color. Ensure sufficient contrast for the confirmation text displayed over it.
***
**Error background color**: Shown when a submission fails — for example, when an invalid phone number format is entered or a network error occurs.
Use a color that signals an issue without being alarming — a muted red or amber works well.
## Best practices
* **Match button color to your brand's primary CTA color.** The Back-in-Stock button competes visually with Add to Cart — using a secondary color that is clearly distinct from your main CTA reduces the chance of customer confusion while still being visible.
* **Keep the headline text specific.** "Get notified" is weaker than "We'll message you on WhatsApp when this is back." Customers who understand exactly what they are subscribing to convert at higher rates and are less likely to report the notification as unexpected.
* **Test all three form states before launch.** Verify the success state, the error state, and the default state each display as intended on both desktop and mobile. A success state that uses your error color creates customer confusion.
* **Revisit widget design after theme updates.** Shopify theme updates can shift layout elements that interact with the widget button position. Check the widget placement after any theme update that affects product page layout.
* **Use `Custom` button type only when necessary.** Pre-designed buttons are optimized for mobile tap targets and accessibility contrast. Custom buttons require manual testing to ensure they meet the same standards.
## Related guides
* [Widget Installation](./widget-installation) — Installing the widget and verifying it on your storefront
* [Subscription Lifecycle](./subscription-lifecycle) — What happens after a customer submits the form
# Widget Installation
Source: https://docs.digifist.com/galantis/whatsapp/back-in-stock/widget-installation
Install the Back-in-Stock subscription widget on your Shopify storefront via Galantis script tag injection.
The Back-in-Stock widget is injected into your Shopify storefront automatically by Galantis using a script tag — no manual theme editing required. When a product variant has zero inventory, the widget button appears on that product page and lets customers submit their WhatsApp number to subscribe for a restock notification.
## What this covers
* How script tag injection works
* Installation steps
* How to verify the widget is live
* Troubleshooting display issues
## How installation works
Galantis writes a script tag to your Shopify store using the `write_script_tags` permission granted during app installation. The script loads on product pages automatically and checks variant inventory in real time — displaying the subscription button only when a variant's `inventory_quantity` is `0`.
No changes to your Shopify theme files are needed. The widget is added and updated entirely through Shopify's script tag system.
The `write_script_tags` Shopify permission is required for the widget to inject. This permission is requested during the initial Galantis app installation. If the widget is not appearing, verify this permission is active under **Shopify Admin → Apps → Galantis → Permissions**.
## Installation steps
In the Galantis dashboard, go to **Back-in-Stock → Settings**.
Set the button position, colors, label text, and modal copy before saving. The widget script will be injected with these settings applied. See [Widget Design](./widget-design) for the full settings reference.
Saving triggers Galantis to write or update the script tag in your Shopify store. No further action is required to deploy the widget to your storefront.
Navigate to a product page with at least one out-of-stock variant. The subscription button should appear for the out-of-stock variant. Switch to an in-stock variant — the button should disappear.
Enter your own WhatsApp number in the widget and submit. Confirm a subscription record appears in **Back-in-Stock → Subscriptions** with `ACTIVE` status.
## How the widget detects out-of-stock variants
The widget script evaluates the current variant's `inventory_quantity` on the product page. When a customer switches between variants — selecting a different size or color — the widget dynamically shows or hides based on whether the selected variant is in stock.
This evaluation happens client-side using the variant data embedded in the Shopify product page. It reflects the inventory state at the time the page was loaded — a variant that goes out of stock after the page was opened will not trigger the widget until the page is refreshed.
## Placement options
The widget button can be positioned in three ways, configured under **Back-in-Stock → Settings → Button position**:
* **Right** — Bottom-right corner of the page
* **Left** — Bottom-left corner of the page
* **Custom** — Precise placement via CSS offset values, useful when your theme's layout conflicts with the default positions
The subscription modal that opens when a customer taps the button is centered on the page regardless of button position.
## Verifying the widget
After saving settings, confirm the widget works correctly by completing each check:
| Check | How to verify |
| -------------------------------------- | ------------------------------------------------------------------------------------------ |
| Button appears on out-of-stock variant | Visit a product page with an out-of-stock variant — button should be visible |
| Button disappears on in-stock variant | Switch to an in-stock variant on the same product — button should hide |
| Modal opens correctly | Tap the button — the subscription modal should open with your configured headline and form |
| Submission creates a subscription | Submit your WhatsApp number — check **Back-in-Stock → Subscriptions** for the new record |
## Troubleshooting
**Widget not appearing on any page**
* Confirm Galantis has `write_script_tags` permission in **Shopify Admin → Apps → Galantis → Permissions**
* Clear your browser cache and reload the product page on your live storefront — not in the Shopify theme editor preview
* Check your browser console for JavaScript errors that may indicate a script loading conflict with your theme
**Widget not appearing on a specific product**
* Confirm the variant you are viewing genuinely has `inventory_quantity = 0` in Shopify — the widget only appears for zero-inventory variants
* If the product uses a third-party inventory management app, confirm that app's inventory data is reflected correctly in Shopify's native inventory fields
**Widget appears but submission fails**
* Check the browser console for network errors on the subscription submission request
* Confirm your WhatsApp Business Account is connected under **Settings → WhatsApp Connection**
The Shopify theme editor preview does not execute third-party script tags. Always verify the widget on your live storefront URL. Testing in the Shopify Customizer preview will show the widget as absent even when it is correctly installed.
## Related guides
* [Widget Design](./widget-design) — Customizing the widget's appearance before or after installation
* [Subscription Lifecycle](./subscription-lifecycle) — What happens after a customer submits their number
* [Getting Started — First Back-in-Stock](/whatsapp/getting-started/first-back-in-stock) — End-to-end setup walkthrough including a restock test
# Back-in-Stock Add-on
Source: https://docs.digifist.com/galantis/whatsapp/billing/add-ons/back-in-stock
Back-in-Stock pricing tiers from 19 to 149 dollars per month, included subscriber limits, 2-cent-per-subscriber overage, and how Enterprise gets the Starter tier included by default.
Back-in-Stock is an opt-in add-on for stores that want to notify shoppers via WhatsApp when a product is restocked. It is billed as a monthly tier with an included subscriber limit. Above the included limit, overage is charged at \$0.02 per additional subscriber. **Enterprise core plan includes the Starter tier (250 subscribers) by default** — every other plan opts in by purchasing a tier.
## Pricing
Up to **250 subscribers** included. Good for small catalogs or pilot rollouts.
Up to **1,000 subscribers** included. Standard tier for active Shopify stores.
Up to **5,000 subscribers** included. For high-traffic catalogs and seasonal peaks.
Up to **10,000 subscribers** included. For large catalogs with sustained Back-in-Stock demand.
### Tier summary
| Tier | Included subscribers | Price / month |
| ---------- | -------------------: | ------------: |
| Starter | 250 | \$19 |
| Growth | 1,000 | \$39 |
| Scale | 5,000 | \$79 |
| Enterprise | 10,000 | \$149 |
**Enterprise core plan (\$399/mo)** includes Back-in-Stock at the **Starter tier (250 subscribers)** at no extra cost. If you exceed 250 subscribers as an Enterprise customer, you can upgrade to a higher BIS tier — only the difference is billed.
## Overage
Above the included subscriber limit, overage is billed at **\$0.02 per additional subscriber per month**. This is added as a usage-based line item on top of your monthly tier subscription.
We recommend monitoring subscriber count in **Billing → Usage** and upgrading to the next tier when you hit 80–90% of the included limit — it almost always works out cheaper than paying overage.
## Choosing the right tier
Go to **Billing → Usage → Back-in-Stock** to see your current subscriber count.
Start one tier above your current count if you expect modest growth. Skip tiers if you're seasonal or running a launch.
Subscribers can pile up faster than expected after a viral product or restock event. The Usage page shows a 30-day trend.
A tier upgrade is cheaper than accumulating overage above \~10% of the included limit. Upgrades take effect immediately.
## Where to track Back-in-Stock usage
Go to **Billing → Usage** in the Galantis app to see:
* Current subscriber count vs included limit
* 30-day trend
* Overage units and cost (if applicable)
## How Back-in-Stock appears on your invoice
Back-in-Stock charges appear on the **Galantis (Shopify) invoice** as:
* "Galantis WhatsApp — Back-in-Stock \[tier name] — \$X / month"
* "Galantis WhatsApp — Back-in-Stock Overage — N subscribers × \$0.02"
For Enterprise customers, the included Starter tier does not appear as a separate line item — it's part of the core plan price. Only upgrades above Starter and overages are billed separately.
## FAQ
A subscriber is a unique customer who has opted in to receive Back-in-Stock notifications for one or more products via WhatsApp. The same customer subscribing to multiple products counts as 1 subscriber.
Subscribers remain on your list until they opt out, are unsubscribed automatically due to inactivity, or are manually removed. See [Subscription lifecycle](/galantis/whatsapp/back-in-stock/subscription-lifecycle).
Yes — each delivered Back-in-Stock notification consumes 1 Conversation credit, drawn from your plan allowance and Conversation tier. The Back-in-Stock add-on covers the subscriber list management itself; the actual delivery uses the same credit pool as campaigns and automation flows.
Yes. Upgrades take effect immediately and are prorated for the remainder of the current Shopify cycle. Downgrades are typically applied at the start of the next billing cycle to keep invoicing predictable.
***
How all Galantis charges appear on your Shopify invoice.
Pricing and overage structure for the Inbox add-on.
# Inbox Add-on
Source: https://docs.digifist.com/galantis/whatsapp/billing/add-ons/inbox
Inbox pricing — $19 per agent seat per month (500 threads each), tiered overage pricing, and which plans include a seat by default.
The Inbox module is billed per agent seat and uses its own usage concept — **Inbox Threads** — which is separate from the platform Conversation credits used for campaign and automation flow delivery. Scale and Enterprise plans include one Inbox seat in the plan price; additional seats are billed individually.
## What's included with each plan
| Plan | Inbox threads included | Included seats | Need more? |
| -------------- | ----------------------- | -------------- | ------------------------------ |
| Free | 50 threads / month | 0 | Upgrade to a paid plan |
| Starter | 50 threads / month | 0 | Add an Additional Agent (\$19) |
| Growth | 50 threads / month | 0 | Add an Additional Agent (\$19) |
| **Scale** | **500 threads / month** | **1 seat** | Add an Additional Agent (\$19) |
| **Enterprise** | **500 threads / month** | **1 seat** | Add an Additional Agent (\$19) |
Plans without an included seat still get **50 inbox threads per month** so you can try the module out. To actively run support over WhatsApp, add an Additional Agent — that unlocks the full 500-thread allowance per seat.
## Pricing
* **\$19 per agent / month**
* Includes **500 Inbox Threads** per agent per month
* Scale and Enterprise plans include 1 seat in the plan price
* Additional seats are billed at \$19 / seat / month
* Seats can be added or removed at any time during a billing cycle
Overage is billed in blocks of 500 Inbox Threads per month, using tiered pricing based on total monthly thread volume across all seats:
| Monthly Inbox Threads | Price per 500 threads |
| --------------------- | --------------------: |
| Under 5,000 | \$5 |
| 5,000 – 25,000 | \$4 |
| 25,000+ | \$3 |
Overage is calculated monthly and added to your Shopify invoice as a usage-based line item.
## How Inbox usage is counted
An **Inbox Thread** represents a support thread handled in the Inbox module. Each agent seat includes 500 threads per month. Usage beyond the included amount is billed as overage in 500-thread blocks using the tiered rates above. Inbox usage is pooled across seats — a 3-seat account has 1,500 included threads in total before overage starts.
Inbox Threads are **not** the same as Conversation credits. Conversation credits track campaign and automation flow delivery. Inbox Threads track support activity in the Inbox module. They have separate balances and separate billing.
## Adding or removing seats
Go to the Galantis app, then **Billing → Add-ons → Inbox**.
Increase or decrease the number of Additional Agent seats. Scale and Enterprise show 1 seat as "included" — additional seats are billed on top.
Adjustments take effect immediately. Pro-rated charges or credits appear on your next Shopify invoice.
Go to **Inbox → Settings → Agents** to [assign the seat to a team member](/galantis/whatsapp/inbox/assignment-routing).
## Where to track Inbox usage
Go to **Billing → Usage** in the Galantis app to see:
* Active agent seats (included + Additional Agents)
* Total included threads (seats × 500)
* Current month thread usage
* Overage totals (if applicable)
## How Inbox appears on your invoice
Inbox charges appear on the **Galantis (Shopify) invoice** as:
* "Galantis WhatsApp — Inbox Agent Seat — N × \$19 / month"
* "Galantis WhatsApp — Inbox Overage — X × 500-thread blocks @ tier rate"
The included seat on Scale and Enterprise plans is part of the core plan price — it does not appear as a separate line item.
***
How all Galantis charges appear on your Shopify invoice.
Pricing and overage structure for the Back-in-Stock add-on.
# What is a Conversation?
Source: https://docs.digifist.com/galantis/whatsapp/billing/conversations
The precise definition of a Conversation, what counts (DELIVERED-only), what does not, and how Conversations are deducted across Free Plan, paid plans, and monthly tiers.
A **Conversation** is a Galantis platform usage unit consumed when a WhatsApp template message is delivered. Understanding exactly what counts — and what does not — helps you predict usage and avoid surprises on your Shopify invoice.
Conversations are not WhatsApp credits and they do not pay Meta charges. Meta bills WhatsApp messaging directly in Meta Business Manager. Galantis bills the platform Conversation separately.
## What counts as a Conversation
A Conversation is consumed when **all** of the following are true:
* The message is a **WhatsApp template message** (campaign or automation flow)
* The message status becomes **DELIVERED**
* The message is billable under WhatsApp messaging rules
A Conversation is **not** consumed for:
* Drafts or previews
* Failed sends
* Undelivered messages
* Inbound replies in the Inbox (those are tracked as Inbox Threads — see [Inbox add-on](/galantis/whatsapp/billing/add-ons/inbox))
## The credit model
Galantis uses a flat rate: **1 delivered Conversation = 1 credit**, regardless of destination country or template category. Meta's per-country and per-category charges still apply on the Meta side, but they don't change how many Galantis credits a delivered message consumes.
Credits come from three places — in this deduction order:
Each plan includes a fixed monthly Conversation allowance (Free 20, Starter 50, Growth 250, Scale 1,000, Enterprise 2,000). These are spent first.
If you added a tier (\$1 = 100 credits, 68 tiers from \$5 to \$5,000), those credits are spent after the plan allowance.
If both are depleted mid-campaign, Galantis blocks new sends and prompts an instant tier upgrade. Existing in-flight sends complete on the current balance.
Want to add or change a tier? See [Tiers & upgrades](/galantis/whatsapp/billing/tiers-and-upgrades) for the full list and how upgrades work.
## Counting happens on delivery
Usage is recorded at the point of delivery, not when you click Send.
```mermaid theme={null}
flowchart TD
A[Campaign or flow attempts send] --> B{Message DELIVERED?}
B -->|No| C[0 credits consumed]
B -->|Yes| D[Deduct 1 credit from balance]
D --> E[Plan allowance, then tier]
E --> F[Usage updated]
```
## Estimation vs. final usage
Before sending a campaign, Galantis shows an estimate of required Conversations. Final usage is reconciled based on actual delivered messages.
Estimates can differ from final usage for the following reasons:
* Delivery rate differs from expected
* Segment size changes between estimate and send
* Recipient country distribution shifts (affects Meta's charges, not your Galantis credit count — but estimates may show both)
## Examples
You launch a campaign with a template message. The message is delivered successfully.
**Result:** 1 Conversation credit consumed per delivered recipient.
A send fails or the recipient number is invalid. The message does not reach DELIVERED status.
**Result:** 0 credits consumed.
You preview or test a template without sending it to real recipients.
**Result:** 0 credits consumed.
An [abandoned-checkout automation](/galantis/whatsapp/automations/recipes/abandoned-checkout) fires and delivers a template message to a customer.
**Result:** 1 Conversation credit consumed per delivered recipient. Automation deliveries draw from the same balance as campaigns.
## Conversations vs. Inbox Threads
The Inbox module also uses the word "conversation" to describe support threads. To avoid confusion, this documentation uses two consistent terms:
* **Conversations (or credits)** — the billing unit for delivered campaign and automation messages
* **Inbox Threads** — support threads handled in the Inbox module, billed separately per agent seat
How Inbox Threads are priced and counted separately from platform Conversations.
## Developer notes
This section is intended for engineers and QA. Customers can skip it.
Create a usage event only when:
* `status == "DELIVERED"`
* message is a billable template message
Suggested fields:
* `message_id` (idempotency key)
* `waba_id` / `business_id`
* `template_name`
* `template_category`
* `destination_country`
* `delivered_at`
Delivery webhooks can be retried. Deduction must be idempotent on `message_id` to avoid double-charging.
1. Plan included Conversations
2. Monthly tier Conversations
If both are insufficient:
* Block new campaign sends
* Prompt immediate tier upgrade
* Pause automation sends (policy choice)
***
The 68 Conversation tiers, the \$1 = 100 credits rate, and how upgrades work.
Where to track usage and what happens when you run out of Conversations.
# Invoices & Line Items
Source: https://docs.digifist.com/galantis/whatsapp/billing/invoices-and-line-items
What shows up on Meta vs Shopify invoices, how each plan and add-on appears as a line item, and what happens during the 7-day free trial.
Galantis billing involves two separate invoices that are always independent. Meta bills WhatsApp messaging charges directly in Meta Business Manager. Galantis bills your platform subscription, Conversation tier, and add-ons through **Shopify Billing** — they appear on your standard Shopify invoice. Neither invoice contains the other's charges.
## Invoice breakdown
Your Shopify invoice from Galantis may include:
* Core App plan subscription (Starter, Growth, Scale, or Enterprise — Free Plan has no charge)
* Monthly Conversation tier (optional, at \$1 = 100 credits)
* Inbox agent seats
* Back-in-Stock add-on tier
* Usage-based overages (Inbox threads, Back-in-Stock subscribers)
Add-on details:
* [Inbox add-on](/galantis/whatsapp/billing/add-ons/inbox)
* [Back-in-Stock add-on](/galantis/whatsapp/billing/add-ons/back-in-stock)
Meta invoices include WhatsApp messaging charges based on destination country and template category. These are billed directly in **Meta Business Manager / Business Suite billing**.
Meta's official pricing model.
Per-country / per-currency rates.
Meta charges never appear on the Shopify invoice from Galantis. They are billed separately, on Meta's own cycle, with Meta's own payment method.
## During the 7-day free trial
When you move from Free Plan to a paid plan, the first 7 days are free. During those 7 days:
* No Galantis charges appear on your Shopify invoice
* The plan's Conversation allowance is available immediately (use it for real sends)
* Add-ons or Conversation tiers added during the trial start billing on day 8 alongside the plan
Your first Shopify charge from Galantis appears on day 8, prorated for the remainder of your Shopify billing cycle if needed.
You can cancel during the trial at no cost. Sending stops at cancellation; data and configuration are retained according to standard retention policy.
## Common line item examples
* "Galantis WhatsApp — Scale Plan — \$179 / month"
* "Galantis WhatsApp — Conversation Tier \$100 (10,000 credits) — \$100 / month"
Plan charges renew monthly on your Shopify billing date. Conversation tiers reset each cycle and persist until you manually downgrade.
* "Galantis WhatsApp — Inbox Agent Seat — 3 × \$19 / month"
Scale and Enterprise include 1 Inbox seat in the plan price. Any seat beyond the included one is billed at \$19/seat/month.
* "Galantis WhatsApp — Back-in-Stock Growth (1,000 subscribers) — \$39 / month"
* "Galantis WhatsApp — Back-in-Stock Overage — 350 subscribers × \$0.02 = \$7.00"
Back-in-Stock is an opt-in add-on. Overage is calculated on the highest subscriber count reached during the cycle.
The Free Plan has no Galantis line items on your Shopify invoice. The plan is permanent and remains active until you upgrade or uninstall the app.
Exact line-item naming depends on your Shopify billing configuration. The goal is always unambiguous separation from Meta charges and clear labeling for audits and finance teams.
## Upgrades and downgrades on the invoice
Plan and tier upgrades take effect immediately. Charges are prorated for the rest of the current Shopify cycle and the new plan/tier is billed in full from the next cycle onwards.
Downgrades are a manual action in **Billing**. We recommend making downgrades effective at the start of your next billing cycle to avoid proration edge cases and keep invoicing predictable.
If a campaign needs more Conversations than your balance allows, you can upgrade the tier from the send flow itself. The upgrade is invoiced like any other tier change.
***
Plans, included Conversations, and the full billing structure.
Official Meta WhatsApp pricing resources and where to view your charges.
# Meta Rate Card & WhatsApp Charges
Source: https://docs.digifist.com/galantis/whatsapp/billing/meta-rate-card
Official Meta WhatsApp pricing links, where to view your Meta charges, and how Meta's per-country pricing relates to Galantis Conversation credits (flat $1 = 100 credits).
Meta controls WhatsApp messaging pricing. Charges vary by destination country and template category and are billed directly in Meta Business Manager — they never appear on your Shopify invoice from Galantis. This page links to the official Meta resources and explains how Meta's pricing relates to the flat Galantis credit model.
## Official Meta pricing
Meta's official pricing model and conversation categories.
Per-country / per-currency rates on Meta's invoice.
Always cross-check your real Meta charges directly in Meta Business Manager — Meta updates pricing periodically and the rate card linked above is the authoritative source.
## Where to see Meta charges
Meta WhatsApp messaging charges are visible in **Meta Business Manager / Business Suite billing** under the [WABA](/galantis/whatsapp/integrations/meta-whatsapp/connecting-waba) you have connected to Galantis.
Meta charges never appear as Galantis line items. The Galantis Shopify invoice only covers the platform subscription, the Conversation tier, and add-ons — see [Invoices & line items](/galantis/whatsapp/billing/invoices-and-line-items).
## Meta charges vs. Galantis Conversations
These are two separate things billed by two separate companies. They are easy to confuse, so here's the contrast:
| | Meta charge | Galantis Conversation credit |
| ----------------- | --------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| What it pays for | The WhatsApp message itself (delivery on Meta's infrastructure) | The Galantis platform (sending engine, scheduler, segments, analytics, automations) |
| Who bills it | Meta, via Meta Business Manager | Galantis, via Shopify Billing |
| How it varies | By destination country + template category | Flat: 1 delivered template = 1 credit |
| When it's charged | On every billable WhatsApp messaging event under Meta's rules | When the template message reaches DELIVERED |
## How Galantis uses Meta pricing signals
Galantis uses Meta's pricing signals only for **pre-send estimation** — to show you the expected Meta cost of a campaign before you press Send. The Galantis credit count itself stays flat: **1 delivered conversation = 1 credit**, regardless of country or category.
That means:
* Pre-send estimates can show two numbers — Galantis credits needed (flat) and estimated Meta cost (varies)
* Your Galantis credit balance is unaffected by changes in Meta's rate card
* A campaign to high-cost destinations spends the same number of Galantis credits as a campaign to low-cost destinations of the same size
If Meta updates its rate card, your Meta invoice will reflect the new rates immediately. Your Galantis plan, tier, and credit balance are unaffected.
***
How Galantis meters platform usage and what triggers a Conversation.
How pre-send estimates work and where to track your balance.
# Billing Overview
Source: https://docs.digifist.com/galantis/whatsapp/billing/overview
Plans and pricing for Galantis WhatsApp: Free Plan, four paid plans with a 7-day free trial, how Conversations work, and which add-ons you can stack on top.
Galantis WhatsApp pricing has two parts that are always billed separately. **Meta bills WhatsApp messaging charges directly** in Meta Business Manager — you must keep a valid payment method there. **Galantis bills the platform** via your Shopify invoice: your plan, your Conversations tier (optional), and any add-ons. Conversations are a Galantis platform unit and never replace Meta's charges.
What counts (DELIVERED-only), what does not, and why usage can vary by destination.
Monthly Conversation tiers, the \$1 = 100 credits rate, and how upgrades work.
Where to track usage and what happens when a campaign needs more Conversations than you have.
***
## Free Plan
The Free Plan is permanent and requires no payment method. It is sized for evaluation and very small Shopify stores.
**Included every month**
* 20 Conversation credits
* 1 automation flow
* **1 campaign per month**
* **Up to 100 contacts**
* 50 inbox threads
* Shopify sync, Meta Catalog, analytics
**Not included:** [AI-assisted flow builder](/galantis/whatsapp/automations/flow-builder), included Inbox seat, Back-in-Stock add-on, dedicated onboarding partner manager.
Ready for more than 1 campaign per month or more than 100 contacts? Pick a paid plan below — the first 7 days are free.
***
## Paid plans
Every paid plan starts with a **7-day free trial**. No credit card or external payment method is needed — billing runs through Shopify, and the first charge appears on your Shopify invoice on day 8. Upgrading between paid plans later does not start a new trial.
For stores starting with WhatsApp campaigns.
* 50 Conversations / month
* 1 automation flow
* Unlimited campaigns + contacts
* 50 inbox threads
* 7-day free trial
For stores running regular campaigns plus a few automations.
* 250 Conversations / month
* 5 automation flows
* Unlimited campaigns + contacts
* 50 inbox threads
* 7-day free trial
AI-assisted flow builder + an included Inbox seat.
* 1,000 Conversations / month
* 20 automation flows
* AI-assisted flow builder
* 1 Inbox seat (500 threads)
* Unlimited campaigns + contacts
* 7-day free trial
Highest tier with dedicated onboarding support.
* 2,000 Conversations / month
* Unlimited automation flows
* AI-assisted flow builder
* 1 Inbox seat (500 threads)
* Dedicated onboarding partner manager
* Higher WhatsApp spend cap (negotiated)
### Feature comparison
| | Free | Starter | Growth | Scale | Enterprise |
| ------------------------- | :-------: | :-------: | :-------: | :----------: | :----------: |
| Price / month | \$0 | \$39 | \$79 | \$179 | \$399 |
| 7-day free trial | — | ✅ | ✅ | ✅ | ✅ |
| Conversations / month | 20 | 50 | 250 | 1,000 | 2,000 |
| Automation flows | 1 | 1 | 5 | 20 | Unlimited |
| AI-assisted flow builder | — | — | — | ✅ | ✅ |
| Campaigns | 1 / month | Unlimited | Unlimited | Unlimited | Unlimited |
| Contacts | 100 max | Unlimited | Unlimited | Unlimited | Unlimited |
| Inbox threads included | 50 | 50 | 50 | 500 (1 seat) | 500 (1 seat) |
| Dedicated partner manager | — | — | — | — | ✅ |
| Higher spend cap | — | — | — | — | Negotiated |
All paid plans include Shopify sync, Meta Catalog, campaigns, analytics, and the Inbox module. Add-ons (extra Inbox seats, Back-in-Stock subscribers, larger Conversation tiers) are billed on top of the plan price.
***
## What Meta bills
Meta charges for WhatsApp messaging based on **destination country** and **template category**. These charges are billed directly in **Meta Business Manager** billing.
Meta's official pricing model and how conversation categories work.
Per-country / per-currency rates that determine your Meta invoice.
Galantis does not collect Meta WhatsApp messaging charges from you. Those charges never appear as Galantis line items on your Shopify invoice.
## What Galantis bills
Galantis bills via Shopify Billing for:
* **Core App plan** (Free / Starter / Growth / Scale / Enterprise)
* **Conversation credits** — your plan allowance plus an optional monthly Conversation tier (\$1 = 100 credits, from \$5 to \$5,000)
* **Add-ons** — additional Inbox seats, Back-in-Stock subscribers
See invoice examples: [Invoices & line items](/galantis/whatsapp/billing/invoices-and-line-items)
***
## Getting started (billing-ready setup)
Connect your Meta Business to Galantis. Your [WABA](/galantis/whatsapp/integrations/meta-whatsapp/connecting-waba) must be approved and usable for sending.
Meta bills WhatsApp messaging charges directly. A valid Meta payment method is required for real sending.
Start on the **Free Plan** (no payment needed) or pick a paid plan to begin a **7-day free trial**. Paid plans bill through Shopify on day 8 — no credit card setup needed in Galantis.
Plans include a small Conversation allowance. For larger campaigns or recurring sends, add a Conversation tier (\$1 = 100 credits) to avoid send-time blocking.
***
## Conversations: the short definition
A **Conversation** is a Galantis platform usage unit consumed when a WhatsApp template message is **DELIVERED** (campaigns + automation flows).
* 1 Conversation = 1 delivered template message
* Drafts, previews, and failed sends do not consume Conversations
* Meta's per-country / per-category charges are separate and billed directly by Meta
The Conversation credit rate is a flat **\$1 = 100 credits** when you add a monthly tier on top of your plan allowance.
Full explanation: [What is a Conversation?](/galantis/whatsapp/billing/conversations)
## Monthly Conversation tiers
Most merchants sending regular campaigns add a monthly Conversation tier on top of their plan allowance.
* 68 tiers available, from \$5 (500 credits) to \$5,000 (500,000 credits)
* Flat rate: \$1 = 100 credits, every tier
* Billed monthly, no rollover
* Upgrades persist until you manually downgrade
Details and full tier list: [Tiers & upgrades](/galantis/whatsapp/billing/tiers-and-upgrades)
## Send-time estimation & instant upgrades
Before you send a campaign, Galantis estimates the Conversations required based on:
* estimated recipients
* template category
* destination mix (when available)
If your remaining Conversations are insufficient, we prompt an upgrade immediately. After upgrading, you can continue sending. Final usage is reconciled on **DELIVERED** status.
Details: [Usage & blocking](/galantis/whatsapp/billing/usage-and-blocking)
***
## Add-ons
Extra agent seats (\$19/seat/month, 500 inbox threads each). Scale and Enterprise include 1 seat.
Subscriber-based tiers from \$19 (250 subscribers) to \$149 (10,000 subscribers).
## Where to track usage
You can track usage under **Billing → Usage** in the Galantis app:
* Conversations remaining (this cycle)
* Reset / renewal date
* Breakdown by source (plan included / monthly tier)
* Add-on usage (Inbox threads, Back-in-Stock subscribers)
***
## FAQ
No. Meta bills WhatsApp messaging charges directly in Meta Business Manager. Your Shopify invoice from Galantis only covers your plan, Conversation tier, and add-ons.
No. The 7-day free trial applies once, when you first move from Free Plan to a paid plan. Upgrading between paid plans (for example Starter → Growth) starts billing immediately and is prorated for the current cycle.
No. Galantis bills through Shopify. As long as your Shopify store has a payment method on file, the 7-day trial is enabled automatically and the first charge appears on your Shopify invoice on day 8.
No. Conversations reset each billing cycle. Unused Conversations do not roll over.
No. Plan and tier upgrades persist until you manually downgrade in Billing.
Go to **Billing → Usage** to see remaining Conversations, breakdown, and the reset date.
***
The precise definition, examples, and edge cases.
What appears on Meta vs Shopify invoices, with example line items.
# Conversation Tiers & Upgrades
Source: https://docs.digifist.com/galantis/whatsapp/billing/tiers-and-upgrades
Galantis Conversation tiers — 68 monthly tiers from 5 to 5,000 dollars at a flat rate of 1 dollar per 100 credits, how upgrades work, and which tier to pick.
Conversation tiers are an optional monthly add-on that increases your Conversation allowance beyond what your plan includes. The rate is flat: **\$1 = 100 credits**, every tier, no markup. Tiers do not roll over and upgrades persist until you manually downgrade. For most stores sending production campaigns, adding a monthly tier is recommended to avoid send-time blocking.
The credit rate changed: tiers are now priced at **\$1 = 100 credits** (previously \$1 = 50). The 68 available tiers run in graduated increments from \$5 (500 credits) up to \$5,000 (500,000 credits).
## Where credits come from
You spend credits in this order:
Each plan includes a fixed monthly Conversation allowance — Free 20, Starter 50, Growth 250, Scale 1,000, Enterprise 2,000. Spent first.
If you add a tier, those credits are spent after your plan allowance is depleted.
If both are exhausted mid-campaign, Galantis blocks new sends and prompts an instant tier upgrade so you can continue.
See [Billing overview](/galantis/whatsapp/billing/overview) for the full plan table.
## Tier list
A short list of commonly chosen tiers to anchor your decision. All 68 tiers from \$5 to \$5,000 are selectable in the Billing dropdown — these are good reference points for picking the right size.
| Price / month | Conversation credits / month | Roughly fits |
| ------------: | ---------------------------: | ----------------------------------- |
| \$5 | 500 | Pilot sends, low-volume stores |
| \$10 | 1,000 | Small store, weekly campaigns |
| \$20 | 2,000 | Small/medium store with automations |
| \$40 | 4,000 | Medium store, regular campaigns |
| \$100 | 10,000 | High-engagement store |
| \$200 | 20,000 | Growth-stage store |
| \$500 | 50,000 | High-volume store |
| \$1,000 | 100,000 | Multi-brand or large catalog |
| \$2,500 | 250,000 | Enterprise volume |
| \$5,000 | 500,000 | Highest standard tier |
Start with the tier that covers about 80% of your typical monthly volume. You can upgrade at send-time if a campaign needs more — and you can downgrade any month if you're routinely under-using.
All 68 tiers — every step shown. Custom tiers above \$5,000 are available on request.
| Price / month | Credits / month | | Price / month | Credits / month |
| ------------: | --------------: | - | ------------: | --------------: |
| \$5 | 500 | | \$1,075 | 107,500 |
| \$10 | 1,000 | | \$1,150 | 115,000 |
| \$20 | 2,000 | | \$1,200 | 120,000 |
| \$40 | 4,000 | | \$1,300 | 130,000 |
| \$60 | 6,000 | | \$1,400 | 140,000 |
| \$80 | 8,000 | | \$1,500 | 150,000 |
| \$100 | 10,000 | | \$1,600 | 160,000 |
| \$125 | 12,500 | | \$1,700 | 170,000 |
| \$150 | 15,000 | | \$1,800 | 180,000 |
| \$175 | 17,500 | | \$1,900 | 190,000 |
| \$200 | 20,000 | | \$2,000 | 200,000 |
| \$250 | 25,000 | | \$2,100 | 210,000 |
| \$300 | 30,000 | | \$2,200 | 220,000 |
| \$350 | 35,000 | | \$2,300 | 230,000 |
| \$400 | 40,000 | | \$2,400 | 240,000 |
| \$450 | 45,000 | | \$2,500 | 250,000 |
| \$500 | 50,000 | | \$2,600 | 260,000 |
| \$550 | 55,000 | | \$2,700 | 270,000 |
| \$600 | 60,000 | | \$2,800 | 280,000 |
| \$650 | 65,000 | | \$2,900 | 290,000 |
| \$700 | 70,000 | | \$3,000 | 300,000 |
| \$750 | 75,000 | | \$3,200 | 320,000 |
| \$800 | 80,000 | | \$3,500 | 350,000 |
| \$850 | 85,000 | | \$3,800 | 380,000 |
| \$900 | 90,000 | | \$4,000 | 400,000 |
| \$950 | 95,000 | | \$4,500 | 450,000 |
| \$1,000 | 100,000 | | \$5,000 | 500,000 |
The full ladder includes every \$100 increment from \$1,200 through \$4,900 — only a representative selection is printed here for readability. Every step in the Galantis Billing dropdown follows the same flat \$1 = 100 credits rate.
## Upgrade and downgrade behavior
Upgrades can happen at any time, including during campaign send-time. The new tier becomes your active tier immediately and remains active for all future billing cycles. The new credits become available right away so an in-progress campaign can finish.
Upgrades do not auto-downgrade next month. If you want a lower tier next cycle, you must manually downgrade in **Billing → Tiers**.
Downgrades are a manual action in Billing. We recommend making downgrades effective at the start of your next billing cycle to avoid proration edge cases and keep billing predictable.
When a campaign requires more Conversations than your remaining balance, Galantis shows a blocking warning and lets you upgrade your tier immediately without leaving the send flow. Final usage is reconciled based on **DELIVERED** messages after the campaign completes.
If you regularly send well over 500,000 Conversations per month, contact your account manager or [support](/galantis/whatsapp/support) to discuss a custom tier or Enterprise volume agreement.
***
How to track Conversations and what happens when a campaign is blocked.
How tiers appear on your Shopify invoice.
# Usage & Campaign Blocking
Source: https://docs.digifist.com/galantis/whatsapp/billing/usage-and-blocking
How to track Conversations, when usage resets, how pre-send estimates work, Free Plan limits, and what happens when you don't have enough Conversations.
Conversations reset each billing cycle with no rollover. You can track your remaining balance, reset date, and breakdown at any time under **Billing → Usage**. When a campaign needs more Conversations than your balance allows, sending is blocked until you upgrade your tier — or, on the Free Plan, until your next monthly reset.
## Where to track usage
In **Billing → Usage**, you can view:
* Conversations remaining (this cycle)
* Reset / renewal date
* Breakdown (plan included / monthly tier)
* Add-on usage (Inbox threads, Back-in-Stock subscribers)
* Plan-specific limits (Free Plan: campaigns this month, contact count)
## Monthly reset
Conversations reset each billing cycle. Unused Conversations do not carry forward.
No rollover keeps billing predictable and aligned with your monthly tier selection. If you regularly under-use your tier, consider downgrading at the next cycle.
## Pre-send estimation
Before a campaign sends, Galantis estimates how many Conversations are needed based on:
* Estimated recipients in the selected segment
* Template category
* Destination mix (when available)
Segment size and template category drive the estimate shown before sending.
Galantis shows the estimated Conversations required so you can confirm your balance is sufficient.
If your balance is insufficient, upgrade your monthly tier without leaving the send flow.
Final Conversations consumed are based on actual DELIVERED messages, not the pre-send estimate.
## What happens when you run out of Conversations
Campaign sending is blocked when your remaining Conversation balance is insufficient. You are prompted to upgrade your monthly tier — sending continues immediately after the upgrade is confirmed.
Automation flows are paused or queued when insufficient Conversations are available. This prevents partial sends and keeps usage traceable. Flows resume automatically as soon as more credits become available (new cycle, manual top-up, or tier upgrade).
Free Plan accounts get 20 Conversation credits per month and **1 campaign per month**. Once either limit is reached, sending is blocked for the rest of the cycle. To send more, upgrade to a paid plan (7-day trial included) or wait for the next reset.
## Spend cap and safety limits
Accounts have a default safety cap to reduce accidental runaway sends.
* Warning at **80%** of balance
* Warning at **90%** of balance
* Sending blocked at **100%** until upgraded, topped up, or the cap is adjusted
Enterprise accounts receive a higher default spend cap, negotiated per account during onboarding. Contact your account manager to adjust the cap if your sending volume regularly approaches the default.
## Free Plan limits
The Free Plan applies extra caps beyond the Conversation balance:
| Limit | Free Plan | Paid plans |
| -------------------------- | --------- | -------------------- |
| Campaigns per month | 1 | Unlimited |
| Contacts (audience) | 100 max | Unlimited |
| Conversations per month | 20 | 50 – 2,000 (by plan) |
| Add a Conversation tier | — | ✅ |
| Add-ons (Inbox seats, BIS) | — | ✅ |
Reaching the campaigns or contacts cap blocks the corresponding action (creating a campaign, importing contacts) until you upgrade to a paid plan. See [Billing overview](/galantis/whatsapp/billing/overview) for the full plan table.
***
How monthly Conversation tiers work and how to upgrade.
The precise definition of a Conversation and what triggers usage.
# Audience Targeting
Source: https://docs.digifist.com/galantis/whatsapp/campaigns/audience-targeting
Build campaign audiences using Customer Lists and Segments, with include/exclude rules and real-time reach estimation.
Campaigns in Galantis use a flexible audience composition model — you select one or more Customer Lists and Segments, set each as include or exclude, and Galantis calculates the deduplicated audience count before you send. Only customers with `SUBSCRIBED` marketing consent are included in the final send, regardless of list or segment membership.
## What this covers
* How audience selection works
* Including and excluding lists and segments
* Estimating reach before sending
* How deduplication and consent filtering are applied
## How audience targeting works
Campaigns use a flexible audience composition model for audience composition. You build your target audience by combining any number of Customer Lists and Customer Segments:
* **Include** — customers in this list or segment are added to the potential audience
* **Exclude** — customers in this list or segment are removed from the potential audience, even if they appear in an included list or segment
Exclusions always take precedence over inclusions. A customer who appears in both an included segment and an excluded list will be excluded from the send.
## Selecting your audience
In **Campaigns → New Campaign** (or an existing draft), navigate to the audience configuration step.
Select one or more Customer Lists or Customer Segments and mark them as **Include**. You can mix lists and segments in the same campaign.
Select any lists or segments you want to remove from the audience and mark them as **Exclude**. Common exclusions include recent purchasers, recently messaged customers, or customers already in an active automation sequence.
Click **Estimate Reach** to preview the deduplicated, consent-filtered audience count before sending.
## Reach estimation
The reach estimate reflects:
* All customers from included lists and segments
* Minus customers removed by exclusion rules
* Minus duplicate customers who appear in multiple included sources
* Minus customers whose `marketing_state` is not `SUBSCRIBED`
The estimate is a preview only — the final audience is recalculated at send time to account for any changes in segment membership or consent status that occur between estimation and dispatch.
Reach estimates can differ from final send counts when segment membership changes between estimation and send time — for example, customers who unsubscribed or whose data changed in a way that affects segment rules.
## Example targeting logic
```
INCLUDE: Segment "High LTV Mexico"
INCLUDE: List "VIP Customers"
EXCLUDE: Segment "Purchased in last 7 days"
```
In this example, the audience includes all customers in the High LTV Mexico segment and the VIP Customers list — but removes any who purchased within the last 7 days, regardless of which included source they came from.
## Consent filtering
Regardless of targeting configuration, the final send audience is filtered to include only customers with `marketing_state = SUBSCRIBED`. Customers with any other consent state — `NOT_SUBSCRIBED`, `UNSUBSCRIBED`, `PENDING`, `UNKNOWN`, `INVALID`, or `REDACTED` — are automatically excluded from delivery.
This filtering runs at send time, not at estimation time. A reach estimate may include customers who are later excluded at send if their consent state changes between the two steps.
## Credit requirements
Galantis validates that your credit balance is sufficient to cover the estimated audience size before allowing a campaign to launch. If credits are insufficient, the campaign will be blocked at the pre-launch compliance check. See [Compliance Checks](./compliance-checks) for the full pre-launch validation list, and [Billing Overview](/whatsapp/billing/overview) for credit management.
## Best practices
* **Always add a recent-purchaser exclusion.** Customers who just bought are less likely to need a promotional message and more likely to find it irrelevant. A segment rule of `Days since last order < 7` is a low-effort exclusion that protects engagement rates.
* **Use Estimate Reach before every send.** A quick check prevents surprises — especially if you have added or removed customers from lists recently or updated segment rules.
* **Layer lists and segments thoughtfully.** Include/exclude logic can become difficult to audit when many layers are combined. Document your targeting rationale, especially for recurring campaign audiences.
* **Keep exclusion lists current.** A "Do Not Contact" or suppression list is only effective if it is maintained. Review and update exclusion lists regularly.
## Related guides
* [Audience — Lists](/whatsapp/audience/lists) — Creating and managing static Customer Lists
* [Audience — Segments](/whatsapp/audience/segments) — Dynamic rule-based segment configuration
* [Compliance Checks](./compliance-checks) — Pre-launch checks including consent validation and credit balance
* [Personalization](./personalization) — Using customer data in message content
# Campaign Analytics
Source: https://docs.digifist.com/galantis/whatsapp/campaigns/campaign-analytics
Track sent, delivered, read, and failed message counts for every campaign in Galantis.
Campaign analytics give you a clear picture of how each broadcast performed — from the number of messages dispatched to how many were opened by recipients. Every metric is tracked at the individual message level through the WhatsApp API and aggregated per campaign, giving you accurate delivery data without estimation.
## What this covers
* The four core delivery metrics and what each measures
* How campaign status reflects delivery progress
* How to interpret results and identify issues
## Core metrics
Each campaign tracks four delivery metrics drawn from the WhatsApp Cloud API's message status callbacks:
**Sent** is the count of messages successfully dispatched from Galantis to the WhatsApp API.
A message reaching `SENT` status means it left Galantis and was accepted by Meta's infrastructure. It does not confirm the message reached the customer's device.
If the sent count is lower than your estimated audience size, the gap typically reflects:
* Customers whose consent status changed to non-`SUBSCRIBED` between estimation and send time
* Messages that failed the API submission step — review `FAILED` count for details
**Delivered** is the count of messages confirmed as received by the customer's device.
A delivered message has reached the recipient's WhatsApp client. The customer may not have opened it yet.
A significant gap between sent and delivered counts can indicate:
* Recipients with inactive WhatsApp accounts or phone numbers
* Temporary device or connectivity issues on the recipient's end
* Phone numbers that are no longer registered on WhatsApp
A consistently low delivery rate relative to sent count across multiple campaigns is worth investigating — it may point to list quality issues.
**Read** is the count of messages opened by the recipient. WhatsApp sends a read receipt when the customer opens the message, which Galantis records as a status update.
Read rate (read ÷ delivered) is your primary engagement metric. It reflects how compelling your message subject and sender context is — customers decide whether to open based on the message preview visible in their WhatsApp notification.
Some customers disable read receipts in their WhatsApp privacy settings. For these recipients, a message that was opened will not generate a read status update. Actual open rates are likely higher than the read count reflects.
**Failed** is the count of messages that could not be delivered. The error reason is tracked per message and is visible in the campaign detail view.
Common failure reasons:
| Error | Cause |
| ---------------------------------- | ---------------------------------------------------------- |
| `CUSTOMER_IS_NOT_OPTED_IN` | Customer's consent state changed after audience estimation |
| `CUSTOMER_IS_MISSING_CALLING_CODE` | Phone number is missing the country calling code |
| `INSUFFICIENT_CREDITS` | Credit balance ran out during dispatch |
A high failure count warrants immediate review. Widespread `CUSTOMER_IS_NOT_OPTED_IN` failures suggest a list quality issue. `CUSTOMER_IS_MISSING_CALLING_CODE` failures indicate a data quality problem in your customer records. `INSUFFICIENT_CREDITS` failures mean the campaign ran out of credits partway through dispatch.
## How metrics are tracked
Delivery status updates are received from Meta via webhook. Each time a message status changes — from `sent` to `delivered`, or `delivered` to `read`, or to `failed` — Galantis updates the `Message` model record for that specific message.
Galantis monitors delivery status during and after dispatch to tally counts and update the campaign-level status. When all messages have a terminal status, the campaign moves to `SENT`, `PARTIALLY_SENT`, or `FAILED`.
## Reading campaign results
Navigate to **Campaigns → \[Campaign Name]** to view the full analytics breakdown. Results are available as soon as dispatch begins — metrics update in real time as status webhooks arrive from Meta.
Use the per-message error view to drill into `FAILED` messages and identify the specific error reason per recipient.
## Interpreting performance
| Signal | Likely meaning |
| ------------------------------- | ------------------------------------------------------------------ |
| High sent, low delivered | List contains inactive or invalid numbers |
| High delivered, low read | Message content or timing needs improvement |
| High read, low click-through | CTA button or offer relevance needs review |
| High failed with consent errors | List quality issue — review audience data sources |
| High failed with credit errors | Insufficient credits — review billing balance before next campaign |
## Best practices
* **Review failed messages after every campaign.** Even a small failure rate contains actionable signal — error types tell you whether the issue is data quality, consent, or billing.
* **Track read rate over time, not just per campaign.** A single campaign's read rate is affected by timing, audience, and content simultaneously. Trends across campaigns are more meaningful than individual results.
* **Compare delivered-to-read rate across campaign types.** Promotional and informational campaigns often have different baseline read rates. Comparing like-for-like gives more useful benchmarks.
* **Act on `CUSTOMER_IS_MISSING_CALLING_CODE` failures.** These indicate phone number records that will always fail until corrected. Update affected contact records in Shopify so they sync correctly into Galantis.
## Related guides
* [Scheduling & Throttling](./scheduling-throttling) — How batch dispatch affects when metrics appear
* [Compliance Checks](./compliance-checks) — Pre-launch validations that reduce failure rates
* [Audience Targeting](./audience-targeting) — List and segment quality practices that improve deliverability
* [Quality & Deliverability](/whatsapp/compliance/quality-deliverability) — How delivery performance affects your phone number rating
# Campaign Types
Source: https://docs.digifist.com/galantis/whatsapp/campaigns/campaign-types
The three campaign types in Galantis — Promotional, Informational, and Catalog — and when to use each.
Galantis supports three campaign types. The type of a campaign is determined by the template you select — specifically, the template's Meta-approved category (`MARKETING` or `UTILITY`) and its message format (standard, single product, multi-product, or whole catalog). Choosing the right type for the right use case keeps your messaging compliant and protects your phone number's quality rating.
## What this covers
* The three campaign types and their intended use cases
* How campaign type is determined
* Why matching type to content matters for compliance
## Campaign types
**Promotional campaigns** use templates in the `MARKETING` category. They are designed for messages that offer value, drive action, or announce something to the customer.
**Common use cases:**
* Discount offers and sale announcements
* New product launches
* Seasonal or event-based promotions
* Re-engagement messages for lapsed customers
* Flash sales with time-limited offers
Promotional campaigns typically have the highest engagement potential — customers who have opted in are often receptive to well-timed, relevant offers. They also carry the highest per-message cost on **Meta's pricing model**, which varies by country. Galantis Conversation credits are flat (1 per delivered message regardless of category), so this cost difference only appears on your Meta invoice, not on the Galantis (Shopify) invoice.
Promotional content must be submitted under the `MARKETING` template category. Using a `UTILITY` template to send promotional content is a Meta policy violation and a common cause of template rejection or phone number quality downgrade.
**Informational campaigns** use templates in the `UTILITY` category. They are appropriate for non-promotional communications where the customer benefits from the information regardless of a purchase decision.
**Common use cases:**
* Store announcements (new hours, policy changes, temporary closures)
* [Back-in-stock](/galantis/whatsapp/back-in-stock/index) announcements sent as a broadcast rather than an automation
* Program or membership updates
* Non-promotional product education content
Utility templates carry lower per-message pricing on **Meta's rate card** in most markets and tend to have lower block rates because customers generally expect and welcome transactional or informational messages. Galantis Conversation credits remain flat at 1 per delivered message — the Meta saving applies to your Meta invoice only.
Keep Utility templates genuinely informational. Embedding promotional CTAs, discount codes, or offer language in a Utility template will trigger rejection during Meta review or a quality flag after it is live.
**Catalog campaigns** use product-specific message formats — Single Product Message (SPM), Multi-Product Message (MPM), or Whole Catalog — to showcase products directly inside WhatsApp. These formats require a synced Meta Catalog.
**Common use cases:**
* Featured product showcases
* Collection-based promotional sends
* Cross-sell or upsell messages referencing specific products
* Full catalog browse prompts for high-intent audiences
Catalog campaigns combine `MARKETING` category compliance with interactive product UI — customers can view product details, variants, and pricing without leaving WhatsApp.
See [Message Composition](./message-composition) for the full breakdown of catalog message formats and their structural requirements.
## How campaign type is determined
Campaign type is not a setting you select explicitly. It is derived automatically from the template you assign to the campaign:
| Template category | Template format | Resulting campaign type |
| ----------------- | ------------------------------------------------------------------ | ----------------------- |
| `MARKETING` | Standard (text, image, video) | Promotional |
| `UTILITY` | Standard | Informational |
| `MARKETING` | `SINGLE_PRODUCT_MESSAGE`, `MULTI_PRODUCT_MESSAGE`, `WHOLE_CATALOG` | Catalog |
## Why type accuracy matters
Meta enforces category compliance at the template level — both during the approval review and after a template is live through quality monitoring. Mismatched category and content is one of the most common causes of template rejection. Beyond rejection, sending promotional content through Utility templates to benefit from lower pricing is a policy violation that can result in your template being paused and your phone number receiving a quality downgrade.
We recommend reviewing the [Quality & Deliverability](/whatsapp/compliance/quality-deliverability) guide before configuring your first campaign template category.
## Related guides
* [Message Composition](./message-composition) — Catalog and rich message format details
* [Compliance Checks](./compliance-checks) — Pre-launch validations including template category verification
* [Templates — Categories](/whatsapp/templates/template-categories) — Marketing vs Utility category rules
# Compliance Checks
Source: https://docs.digifist.com/galantis/whatsapp/campaigns/compliance-checks
The pre-launch validations Galantis runs before any campaign can be sent.
Before a campaign can be launched — whether immediately or on a schedule — Galantis runs a set of pre-launch compliance checks. These validations exist to prevent policy violations, protect your phone number's quality rating, and ensure the campaign has everything it needs to deliver successfully. A campaign that fails any check cannot be sent until the issue is resolved.
## What this covers
* The four pre-launch checks and what each validates
* What a failed check means and how to resolve it
* The relationship between compliance checks and campaign status
## Pre-launch checks
**What is checked:** The template assigned to the campaign must have `APPROVED` status in Meta's template system.
**Why it matters:** WhatsApp does not accept messages using templates in `DRAFT`, `PENDING_APPROVAL`, or `REJECTED` status. A campaign using an unapproved template would fail at the API level for every recipient.
**How to resolve:** If your template is `PENDING_APPROVAL`, wait for Meta to complete the review — approval typically takes minutes to a few hours. If the template is `REJECTED`, review the rejection reason in **Templates → \[Template Name] → Status**, fix the issue, and resubmit. Do not launch the campaign until the template reaches `APPROVED` status.
Template approval status is checked at launch time, not at the time the template is selected during campaign configuration. A template that was approved when you built the campaign may have since been paused by Meta — always confirm status before sending.
**What is checked:** The final audience — after applying include/exclude rules and deduplication — must contain only customers with `marketing_state = SUBSCRIBED`.
**Why it matters:** Sending to non-opted-in customers violates WhatsApp's Business Policy and can trigger quality degradation on your phone number. Galantis enforces this automatically by filtering the audience at send time, but the check confirms the audience is not entirely empty after filtering.
**How to resolve:** If the check fails because no `SUBSCRIBED` customers remain after filtering, review your audience selection. The most likely causes are: your selected lists or segments contain no opted-in customers, or all opted-in customers are removed by an exclusion rule. Adjust your targeting and re-estimate reach before attempting to launch again.
See [Opt-in & Consent](/whatsapp/compliance/opt-in-consent) for how consent states are assigned and managed.
**What is checked:** The selected template's category must accurately reflect the message content and intended purpose.
**Why it matters:** Meta monitors category compliance both during template approval and after templates are live. Using a `UTILITY` template to send `MARKETING` content is a policy violation — it misrepresents the message purpose to both Meta and the recipient.
**How to resolve:** If your message content is promotional in nature (offers, discounts, product launches), ensure the template uses the `MARKETING` category. If the template's category does not match your intended use, you will need to create a new template with the correct category and obtain approval before launching.
See [Campaign Types](./campaign-types) for how template category maps to campaign type, and [Templates — Categories](/whatsapp/templates/template-categories) for category definitions.
**What is checked:** Your current credit balance must be sufficient to cover the estimated send volume for the campaign.
**Why it matters:** Credits are consumed per message sent. If your balance runs out partway through a campaign dispatch, remaining messages will fail with an `INSUFFICIENT_CREDITS` error. The pre-launch check catches this before dispatch begins to prevent partial sends.
**How to resolve:** If your balance is insufficient, top up credits or upgrade your plan before launching. The credit requirement is calculated from the estimated audience size — a larger audience requires more credits. Review your estimated reach in **Campaigns → \[Campaign] → Audience** and compare it against your current balance in **Billing → Overview**.
See [Billing Overview](/whatsapp/billing/overview) for credit management, and [Billing — Conversations](/whatsapp/billing/conversations) for how per-message costs are calculated.
## Check summary
| Check | Blocks launch if... |
| ----------------- | ------------------------------------------------------- |
| Template status | Template is not `APPROVED` |
| Audience consent | No `SUBSCRIBED` customers remain after filtering |
| Template category | Category does not match message content purpose |
| Credit balance | Balance is insufficient for the estimated audience size |
## When checks run
Pre-launch checks run at the moment you click **Send** or confirm a scheduled campaign. They are not run during campaign configuration — you can build and save a campaign in `DRAFT` status regardless of template approval state or credit balance. The checks gate the transition from `DRAFT` to `PENDING` or `SCHEDULED`.
For scheduled campaigns, checks run at the time of scheduling, not at the scheduled send time. This means a campaign that passes checks at scheduling time could encounter an issue by the time it actually sends — for example, if a template is paused by Meta or credits are depleted between scheduling and dispatch.
For scheduled campaigns, we recommend reviewing template status and credit balance shortly before the scheduled send time to catch any issues that arose after scheduling.
## Related guides
* [Templates — Approval Lifecycle](/whatsapp/templates/approval-lifecycle) — Template status states and the review process
* [Audience Targeting](./audience-targeting) — Building consent-compliant audiences
* [Campaign Types](./campaign-types) — Matching template category to message purpose
* [Billing Overview](/whatsapp/billing/overview) — Managing and monitoring your credit balance
# Campaigns
Source: https://docs.digifist.com/galantis/whatsapp/campaigns/index
One-time WhatsApp broadcasts sent to segmented audiences — with flexible targeting, scheduling, and real-time delivery analytics.
Campaigns are one-time WhatsApp broadcasts sent to a targeted audience. They are the primary tool for reaching customers at scale — product launches, promotional offers, seasonal announcements, and catalog-driven messages all run through campaigns.
Every campaign requires a pre-approved WhatsApp template. The message is sent to all qualifying recipients in the selected audience simultaneously, with delivery tracked per message through the WhatsApp API.
## How campaigns work
A campaign moves through a defined lifecycle from configuration to send:
1. **Select a template** — choose an approved template and map its variables to customer or order data
2. **Build your audience** — select lists and segments to include or exclude; preview reach before sending
3. **Schedule or send** — dispatch immediately or set a future date and time
4. **Monitor results** — track sent, delivered, read, and failed counts per campaign
Only customers with `SUBSCRIBED` marketing consent are included in the final send. Audience filtering, compliance checks, and credit validation all run automatically before any message is dispatched.
## Guides in this section
Promotional, informational, and catalog campaign formats.
Lists, segments, include/exclude rules, and reach estimation.
Rich Cards, Single and Multi-Product Messages, and Whole Catalog format.
Immediate send, scheduled delivery, and WhatsApp throughput limits.
Dynamic variable mapping for customer, order, and product data.
Sent, delivered, read, and failed metrics per campaign.
Pre-launch validations Galantis runs before any campaign can send.
## Before sending your first campaign
Two prerequisites must be in place before a campaign can be launched:
* At least one template with `APPROVED` status — see [Templates](/whatsapp/templates/index) for how to create and submit templates for Meta review
* At least one Customer List or Segment containing `SUBSCRIBED` customers — see [Audience](/whatsapp/audience/index)
If you are setting up campaigns for the first time, the [First Campaign](/whatsapp/getting-started/first-campaign) guide in Getting Started walks through the full end-to-end process.
# Message Composition
Source: https://docs.digifist.com/galantis/whatsapp/campaigns/message-composition
Campaign message formats in Galantis — from standard rich cards to single and multi-product messages and whole catalog browsing.
The message format of a campaign is determined by the template you select. Galantis supports five distinct formats — from simple promotional cards to interactive product carousels and full catalog browsing. Each format serves a different purpose and has different structural requirements, some of which depend on a synced Meta Catalog.
## What this covers
* All five campaign message formats and their use cases
* Structural components of each format
* Which formats require a Meta Catalog
* Guidance on choosing the right format
## Message formats
**Single Rich Card** (`SINGLE_RICH_CARD`) is a promotional message format combining a header, body text, footer, and up to three action buttons into a single visual card.
**Structure:**
* `HEADER` — Text with optional variable
* `BODY` — Rich text with dynamic variables
* `FOOTER` — Static short text (e.g., "Reply STOP to unsubscribe")
* `BUTTONS` — Up to 3 buttons: Quick Reply, URL, Phone Number, or Copy Code
**Best for:** Single-focus promotional messages where one clear CTA drives the customer toward a product page, discount redemption, or direct response.
**Meta Catalog required:** No
Single Rich Cards work well for time-limited offers. Use a `COPY_CODE` button for discount codes and a `URL` button linking directly to the product or collection page.
**Multi Rich Card** (`MULTI_RICH_CARD`) presents multiple cards in a horizontally swipeable carousel. Each card in the carousel has its own image, body text, and buttons.
**Structure:**
* `BODY` — Carousel-level introductory text
* `CAROUSEL` — Multiple individual cards, each with image, body, and buttons
**Best for:** Showcasing several products, collections, or offer options in a single message where the customer can swipe through and choose what interests them. More engaging than sending multiple separate messages.
**Meta Catalog required:** No — card content is defined at the template level, not pulled from a live catalog sync.
Carousel card content is fixed in the template at creation time. If product details or offers change frequently, a catalog-based format (SPM or MPM) may be easier to maintain since it pulls live product data.
**Single Product Message** (`SINGLE_PRODUCT_MESSAGE`, SPM) showcases one specific product from your synced catalog, including variants, pricing, and a buy button that opens the product in WhatsApp's native commerce UI.
**Structure:**
* `HEADER` — Product pulled from catalog (`PRODUCT` header type)
* `BODY` — Supporting text with dynamic variables
* `FOOTER` — Static text
* `BUTTONS` — Action buttons
* `PRODUCT_SECTIONS` — Product and variant selection data from catalog
**Best for:** Targeted product promotions where a specific item is the focus — such as a best-seller highlight, a back-in-stock broadcast, or a personalized recommendation based on purchase history.
**Meta Catalog required:** Yes — the product displayed is pulled from your synced Meta Catalog. The catalog must be connected and the product must have `SYNCED` status before this format can be used.
**Multi-Product Message** (`MULTI_PRODUCT_MESSAGE`, MPM) displays up to 30 products from your synced catalog in a scrollable list, allowing customers to browse and select from multiple items in a single message.
**Structure:**
* `HEADER` — Text with optional variable
* `BODY` — Introductory message text
* `FOOTER` — Static text
* `BUTTONS` — Action buttons
* `PRODUCT_SECTIONS` — Multiple product entries from catalog, organized into sections
**Best for:** Collection-based campaigns, curated product selections, or "shop the look" style sends where the goal is to drive browsing rather than focus on a single item.
**Meta Catalog required:** Yes — products are pulled from your synced Meta Catalog. All products included must have `SYNCED` status.
**Whole Catalog** (`WHOLE_CATALOG`) sends a message with a catalog browse button that opens your entire WhatsApp catalog, allowing customers to browse all available products without the merchant pre-selecting items.
**Structure:**
* `BODY` — Introductory message text
* `FOOTER` — Static text
* `CATALOG` button — Opens the full catalog browser in WhatsApp
**Best for:** High-intent audiences who are likely to browse broadly — such as a segment of frequent purchasers, customers who have visited your store multiple times, or a VIP list. Also useful for stores with large catalogs where pre-selecting products for MPM is impractical.
**Meta Catalog required:** Yes — the entire catalog must be synced and connected to Meta.
## Format selection guide
| Format | Catalog required | Products shown | Best use case |
| ---------------- | ---------------- | --------------------- | ------------------------------------- |
| Single Rich Card | No | 0 (image only) | Single-focus promotion or offer |
| Multi Rich Card | No | Up to \~10 (carousel) | Multi-product showcase, fixed content |
| SPM | Yes | 1 specific product | Targeted product promotion |
| MPM | Yes | Up to 30 products | Collection or curated product send |
| Whole Catalog | Yes | Full catalog | Browse-driven, high-intent audiences |
## Meta Catalog requirements
SPM, MPM, and Whole Catalog formats all require:
1. A Meta Catalog connected to your Galantis workspace — see [Catalog — Meta Catalog](/whatsapp/catalog/meta-catalog)
2. Products with `SYNCED` status in your catalog — see [Catalog — Health](/whatsapp/catalog/catalog-health)
If a product referenced in an SPM or MPM template has not been successfully synced to Meta, that template cannot be used in a campaign until the sync issue is resolved.
## Related guides
* [Campaign Types](./campaign-types) — How message format determines campaign type
* [Personalization](./personalization) — Populating dynamic variables in message body and header
* [Catalog](/whatsapp/catalog/index) — Full catalog sync and Meta connection reference
* [Templates — Formats](/whatsapp/templates/template-formats) — Template structure components in detail
# Personalization
Source: https://docs.digifist.com/galantis/whatsapp/campaigns/personalization
Map dynamic variables in campaign templates to customer, order, and product data for personalized message delivery.
Campaign messages support dynamic content through template variable mapping. Variables defined in a template at creation time — such as `{{1}}` or `{{2}}` — are mapped to real customer or order data fields when a campaign is configured. At send time, Galantis populates each variable with the recipient's actual data before dispatching the message to the WhatsApp API.
Personalized messages perform better than generic broadcasts. Addressing a customer by name, referencing their last order, or surfacing a product they viewed increases relevance and reduces the likelihood of a block or report.
## What this covers
* How template variables are defined and mapped
* Available data sources for variable values
* How to configure variable mapping in a campaign
* Fallback behavior when data is missing
## How variable mapping works
Template variables are positional placeholders — `{{1}}`, `{{2}}`, `{{3}}` — defined in the template body and optionally in the header. When you select a template for a campaign, Galantis presents each variable placeholder and lets you assign it a dynamic value from your customer or order data.
The mapping is stored as a `template_variables_mapping` configuration on the campaign:
```json theme={null}
[
{ "initialValue": "{{1}}", "selectedValue": "customer.first_name" },
{ "initialValue": "{{2}}", "selectedValue": "order.total_price" }
]
```
At send time, each placeholder is replaced with the corresponding value from the recipient's Shopify profile.
## Available variable values
The following customer fields are available as variable values:
| Field | Value |
| --------------------- | ------------------------ |
| `customer.first_name` | Customer's first name |
| `customer.last_name` | Customer's last name |
| `customer.email` | Customer's email address |
| `customer.phone` | Customer's phone number |
`customer.first_name` is the most commonly used variable — opening a message with the customer's name meaningfully increases engagement compared to a generic greeting.
Order data variables reference the customer's most recent order unless otherwise specified.
| Field | Value |
| -------------------- | -------------------------------------- |
| `order.order_number` | Shopify order number |
| `order.total_price` | Order total |
| `order.product_name` | Name of the first product in the order |
Order data variables are most useful in post-purchase campaign contexts — for example, a cross-sell campaign that references the customer's recent purchase.
Order data variables reference Shopify order records synced into Galantis. If a customer has no order history, these variables may be empty. Configure a static fallback value where appropriate.
**Store name**: The name of your Shopify store — useful for brand reinforcement in the message body.
**Custom static text**: A fixed string you type directly into the variable mapping. Use this for:
* Discount codes that apply to all recipients (`SUMMER20`)
* Static URLs for landing pages or collection links
* Fixed product names or offer descriptions for campaigns where the content does not vary per recipient
Static text is the right choice when a variable slot needs a value but no dynamic customer or order data is appropriate for that position.
For catalog-based message formats (SPM and MPM), product data is pulled directly from your synced Meta Catalog rather than from template variable mapping. Product name, price, image, and variant data are populated automatically from the catalog record.
Standard template body variables (`{{1}}`, `{{2}}`) can still be used alongside catalog product data — for example, a variable greeting in the body text while the product card is populated from the catalog.
See [Message Composition](./message-composition) for how catalog product data works in SPM and MPM formats.
## Configuring variable mapping in a campaign
In the campaign builder, choose an approved template. Galantis detects the variable placeholders defined in that template.
For each placeholder (`{{1}}`, `{{2}}`, etc.), select a value from the available data fields or enter custom static text.
Review the mapping before proceeding. Confirm that each variable is assigned a value that makes sense in the context of the message body.
## Best practices
* **Always map `{{1}}` to `customer.first_name` when the template opens with a greeting.** This is the single highest-impact personalization variable and requires no extra configuration.
* **Use static text for offer codes.** Discount codes are the same for all recipients — map them as static text rather than leaving the variable unmapped.
* **Avoid mapping email or phone to visible message body variables.** Customers generally do not expect to see their own contact details reflected back to them in a promotional message.
* **Review mappings when reusing templates across campaigns.** A variable mapping that worked for a post-purchase send (using `order.total_price`) will not make sense in a re-engagement campaign where many recipients have no recent order.
## Related guides
* [Message Composition](./message-composition) — Template formats and their variable support
* [Templates — Variables & Localization](/whatsapp/templates/variables-localization) — How variables are defined in templates
* [Audience Targeting](./audience-targeting) — Combining personalization with precise audience selection
# Scheduling & Throttling
Source: https://docs.digifist.com/galantis/whatsapp/campaigns/scheduling-throttling
Send campaigns immediately or schedule them for a future time — and understand how WhatsApp throughput limits affect delivery.
Galantis gives you two delivery options for every campaign: send immediately upon launch, or schedule for a specific date and time. Once dispatched, messages are processed in batches subject to WhatsApp's per-phone-number throughput limits. Understanding how throttling works helps you set accurate delivery expectations and plan sends around time-sensitive campaigns.
## What this covers
* Immediate send vs scheduled delivery
* How batch dispatch works
* WhatsApp throughput limits and what they mean for large audiences
* Campaign status during and after dispatch
## Send options
Selecting **Send now** queues the campaign for dispatch as soon as you confirm the launch. The campaign moves to `PENDING` status and message dispatch begins immediately.
Use immediate send for:
* Time-sensitive offers where delay would reduce relevance (flash sales, limited stock alerts)
* Campaigns where audience timing is not critical
* Test sends to small audiences during setup
Even with immediate send, large audiences are processed in batches. The campaign will not appear as `SENT` until all messages have been dispatched — this can take time depending on audience size and throughput limits.
Selecting **Schedule** sets a `scheduled_date_start` — a future date and time when the campaign will begin dispatch. The campaign moves to `SCHEDULED` status and sits in the queue until that time, at which point it is processed identically to an immediate send.
Use scheduled send for:
* Timezone-aware sends where you want messages to arrive during a specific window (e.g., morning local time in LATAM markets)
* Coordinated launches tied to a product release or event date
* Pre-prepared campaigns that should go out at a predictable time
Consider your audience's timezone when scheduling. WhatsApp messages are delivered immediately — a campaign scheduled for 9:00 AM in your timezone may arrive at 3:00 AM for customers in a different region. Segment by country and schedule separate campaigns per timezone for large international audiences.
## How batch dispatch works
When a campaign begins sending, Galantis processes recipients in batches rather than all at once. Each batch is dispatched sequentially through the WhatsApp Cloud API.
This approach:
* Prevents API rate limit violations on large audiences
* Allows delivery status to be tracked per message as batches complete
* Supports partial success states where some messages succeed and others fail
## WhatsApp throughput limits
WhatsApp enforces per-phone-number message throughput limits that cap how many messages can be sent per unit of time. These limits are set by Meta and vary based on your phone number's quality tier and business verification status.
The practical effect is that campaigns to large audiences take longer to complete than campaigns to small ones. Throughput limits are not configurable within Galantis — they are enforced at the API level by Meta.
If your phone number has a reduced quality rating, throughput limits may be lower than standard. This is one of several reasons why maintaining a good quality rating directly affects campaign performance. See [Quality & Deliverability](/whatsapp/compliance/quality-deliverability) for how quality ratings are managed.
## Campaign status reference
| Status | Description |
| ---------------- | ------------------------------------------------------------------ |
| `DRAFT` | Campaign is being configured — not queued or sent |
| `PENDING` | Queued for immediate dispatch — processing has begun |
| `SCHEDULED` | Queued for a future send time — waiting for `scheduled_date_start` |
| `SENT` | All messages dispatched successfully |
| `PARTIALLY_SENT` | Some messages succeeded, some failed — review per-message errors |
| `FAILED` | All messages failed — check error details and retry |
Galantis monitors dispatch progress continuously, tallying successful and failed message counts and updating the campaign status. When dispatch completes, a notification is triggered based on the outcome.
## Best practices
* **Schedule large campaigns outside peak hours.** Throughput limits mean large sends take time to complete. Scheduling during off-peak periods ensures delivery completes before the start of your store's busy period.
* **Check credit balance before scheduling.** Credits are validated at launch, not at scheduling time. If your balance drops below the required amount between scheduling and send time, the campaign will be blocked. See [Compliance Checks](./compliance-checks).
* **Do not schedule too far in advance for time-sensitive offers.** Segment membership and consent status are recalculated at send time. A segment that looks right today may include or exclude different customers by the scheduled send date.
* **Monitor `PARTIALLY_SENT` campaigns.** A partial send means some customers did not receive the message. Review the failed message details and determine whether a follow-up send to the failed recipients is appropriate.
## Related guides
* [Campaign Analytics](./campaign-analytics) — Tracking delivery outcomes after dispatch
* [Compliance Checks](./compliance-checks) — Pre-launch validations that run before dispatch begins
* [Quality & Deliverability](/whatsapp/compliance/quality-deliverability) — How quality rating affects throughput
# Catalog Health
Source: https://docs.digifist.com/galantis/whatsapp/catalog/catalog-health
Monitoring sync status, identifying failed products, and maintaining a healthy Meta Catalog in Galantis.
Catalog health refers to the state of your product data pipeline — from Shopify through Galantis to Meta. A healthy catalog means product data in your WhatsApp messages is accurate, all product formats are functional, and no sync errors are silently causing product cards to display stale information or failing to push new products to Meta.
Catalog health is not a one-time concern. It requires periodic monitoring — particularly after bulk Shopify changes, after sale events that shift prices, and whenever product image assets are updated.
## What this covers
* The three per-product sync statuses and what each means
* Health metrics available in the Catalog module
* How to identify and resolve sync failures
* When to trigger a manual re-sync
* Monitoring the Meta Catalog token
## Per-product sync status
Every product in Galantis has a Meta sync status that reflects whether it has been successfully pushed to Meta:
| Status | Meaning | Action required |
| --------- | ----------------------------------------------------------------- | ---------------------------------------------------------------------- |
| `PENDING` | Queued for Meta upload — not yet pushed | None — the product is waiting to be processed by the next catalog sync |
| `SYNCED` | Successfully pushed to Meta — product data is live in the catalog | None — product is healthy |
| `FAILED` | Sync error — the product was not pushed to Meta | Review error details and resolve the issue |
Status is visible per product in **Catalog → \[Product Name]** and aggregated across all products in the main Catalog view.
## Catalog health metrics
The Catalog module surfaces three top-level health metrics:
**Sync success rate** — The percentage of total products that have `SYNCED` status. A healthy catalog should approach 100% for all non-excluded products. A declining sync success rate indicates accumulating failures that need attention.
**Product errors** — The count of products with `FAILED` status, broken down by error type. This is the primary actionable metric — each `FAILED` product represents a product that cannot appear in SPM or MPM messages until resolved.
**Message usage** — The number of SPM and MPM messages sent via campaigns and automations that referenced catalog products. This metric provides context for prioritization — a `FAILED` product referenced by an active high-volume automation is more urgent than a `FAILED` product in a draft template.
## Common failure causes
The most common cause of `FAILED` status. Meta requires product images to be JPEG or PNG format and at least 500×500px. Images that do not meet these requirements are rejected during the Meta push.
**How to resolve:**
1. Identify the affected product in **Catalog → \[Product Name] → Error Details**
2. Update the product image in Shopify to meet the format and size requirements
3. Save the product in Shopify — this triggers an automatic webhook update in Galantis
4. The next catalog sync cycle will re-attempt the Meta push with the updated image
If you have many products with image failures, perform a bulk image audit in Shopify before triggering a manual re-sync. Fixing images one at a time and re-syncing individually is less efficient than resolving all image issues first and syncing once.
If your Meta Catalog access token expires or is revoked in Meta Business Manager, all Meta push attempts fail simultaneously. This produces a sudden spike of `FAILED` status across many products at once rather than isolated individual failures.
**How to identify:** A sudden increase in `FAILED` status across products that were previously `SYNCED`, with no corresponding changes in Shopify, strongly indicates a token issue rather than a product data problem.
**How to resolve:**
1. Go to **Settings → WhatsApp Connection** and check the Meta Catalog token status
2. If the token is expired or invalid, reconnect by going through the Meta OAuth flow again
3. Once reconnected, trigger a manual Meta push or wait for the next catalog sync cycle — products that failed due to the token issue will be re-attempted automatically
Meta requires certain fields to be present for a product to be accepted into a catalog — notably, a title, a price, and at least one image. Products missing these fields will fail the Meta push.
**How to resolve:**
1. Open the `FAILED` product in **Catalog → \[Product Name] → Error Details** and check which field is flagged
2. Update the missing field in Shopify
3. The Shopify product update webhook fires automatically and refreshes the Galantis record
4. The next Meta sync attempt will include the now-complete product data
If a product is deleted from Shopify, Galantis receives the `products/delete` webhook and removes it from the Galantis catalog. However, if an active SPM or MPM template references that product, the template will fail for any recipients until the template is updated to reference a different product.
**How to identify:** Campaign analytics or automation activity logs show `FAILED` message sends with a product-not-found error type.
**How to resolve:**
1. Update the affected SPM or MPM template to reference an available, `SYNCED` product
2. Resubmit for Meta approval if required
3. Reactivate any automations that were using the updated template
## Triggering a manual re-sync
When sync errors have been resolved at the source — images fixed, fields updated, token refreshed — you can accelerate recovery by triggering a manual sync rather than waiting for the next automatic job run:
**For Shopify-side fixes** — if you updated product data in Shopify (images, titles, prices), the `products/update` webhook fires automatically and queues the product for re-sync. No manual action required in most cases.
**For Meta-side recovery after token issues** — after reconnecting the Meta Catalog token, trigger a manual full sync from **Catalog → Shopify Sync → Sync Now** to re-queue all `FAILED` products for the next Meta push cycle.
See [Shopify Sync](./shopify-sync) for full manual sync instructions.
## Monitoring cadence
Catalog health does not require daily review for most stores — the automatic sync handles ongoing changes reliably. We recommend checking catalog health:
* **After any bulk product operation in Shopify** — price changes, image updates, bulk tag edits, or CSV imports
* **Before launching a campaign that uses SPM or MPM formats** — verify that all referenced products have `SYNCED` status
* **After any change to your Meta Catalog token** — verify no mass failures appeared
* **Monthly** — a routine check of sync success rate and `FAILED` count ensures no silent accumulation of errors
## Best practices
* **Resolve `FAILED` products before activating catalog-dependent automations.** An SPM automation with a `FAILED` product will send messages that display a broken or missing product card until the issue is resolved.
* **Address image failures in Shopify, not in Galantis.** Galantis syncs images from Shopify — fixing the image at the Galantis level is not possible. Update the image in Shopify and the webhook will propagate the fix.
* **Set up a recurring catalog health check before major campaign periods.** Sale events, holiday campaigns, and product launches all involve catalog changes. Verifying catalog health before a send ensures the products customers see in their messages are accurate.
* **Exclude products that consistently fail** using `exclude_from_syncforce` if they cannot be fixed immediately. This removes them from the failure count and prevents them from blocking catalog push jobs while the underlying issue is resolved. See [Product Fields](./product-fields).
## Related guides
* [Shopify Sync](./shopify-sync) — How to trigger a manual full re-sync
* [Meta Catalog](./meta-catalog) — Managing the catalog token and connection
* [Variants & Pricing](./variants-pricing) — Variant-level data that affects individual product sync status
* [Support — Catalog Sync Errors](/whatsapp/support/troubleshooting/catalog-sync-errors) — Detailed troubleshooting for sync failures
# Catalog Message Types
Source: https://docs.digifist.com/galantis/whatsapp/catalog/catalog-message-types
The five WhatsApp message formats that use catalog data in Galantis — SPM, MPM, Whole Catalog, Single Rich Card, and Multi Rich Card.
WhatsApp supports several interactive message formats for showcasing products. Some formats pull live data directly from your synced Meta Catalog — prices, images, and variant options update automatically as your catalog changes. Others use fixed content defined at template creation time. Understanding which format uses which data source helps you choose the right format for each campaign or automation and manage the catalog dependencies each format introduces.
## What this covers
* All five message formats and their catalog dependency
* How catalog data is used within each format
* When each format is appropriate
* Format requirements at a glance
## Message formats
**Single Product Message (SPM)** displays one specific product from your Meta Catalog. The customer sees a product card with the product image, name, price, and variant options — they can select a variant and proceed to purchase without leaving WhatsApp.
**Catalog dependency:** Required — the product is pulled directly from your Meta Catalog. The product must have `SYNCED` status.
**How catalog data is used:**
* Product image, name, and price are pulled from the synced catalog record
* Variant options (`selected_options`) are passed as `PRODUCT_SECTIONS` data, powering the variant picker the customer sees
* `compare_at_price` is included when set, showing a crossed-out original price alongside the sale price
* Availability reflects the current `inventory_quantity` at the time the message is sent
**Best for:** Focused product promotions where one specific item is the message's purpose — a best-seller, a seasonal hero product, a back-in-stock alert for a specific item, or a personalized recommendation based on purchase history.
**Template structure:** `HEADER (PRODUCT)` + `BODY` + `FOOTER` + `BUTTONS` + `PRODUCT_SECTIONS`
If the product referenced in an SPM template loses `SYNCED` status — due to an image format failure, a catalog token issue, or a sync error — messages using this template will fail for all recipients until the sync issue is resolved. Monitor catalog health for SPM-referenced products before campaign launches.
**Multi-Product Message (MPM)** displays up to 30 products from your Meta Catalog in a scrollable list, organized into labeled sections. Customers can browse the list and tap any product to view details and select variants.
**Catalog dependency:** Required — all products in the message must have `SYNCED` status in your Meta Catalog.
**How catalog data is used:**
* Each product in the list pulls its image, name, price, and availability from the Meta Catalog
* Products are organized into `PRODUCT_SECTIONS` — each section has a label and a list of product entries
* Variant data is available when a customer taps to view a product's detail screen
**Best for:** Collection-based campaigns, curated product edits, and "shop the look" or "complete the set" messages where the goal is to give the customer a browsable selection rather than focus on one item.
**Template structure:** `HEADER (TEXT)` + `BODY` + `FOOTER` + `BUTTONS` + `PRODUCT_SECTIONS`
Organize MPM products into meaningful sections rather than one flat list. Sections like "New Arrivals", "Top Sellers", and "Under \$50" give customers a navigation context that improves browsing behavior compared to an unlabeled product dump.
**Whole Catalog** sends a message with a catalog browse button. When the customer taps it, WhatsApp opens a full catalog browser showing all products in your connected Meta Catalog.
**Catalog dependency:** Required — your entire Meta Catalog must be connected and in sync. The catalog browser reflects the current state of all synced products.
**How catalog data is used:**
* The catalog browser is powered entirely by Meta's native catalog UI — it pulls all products with `SYNCED` status from the connected catalog
* Product data displayed to the customer — images, names, prices, availability — reflects the Meta Catalog state at the time of browsing, not at the time the message was sent
* Customers see your full product range and can browse freely, select variants, and proceed to purchase
**Best for:** High-intent audiences who are likely to browse broadly — VIP customers, frequent purchasers, customers who visited your store multiple times without converting. Also appropriate for stores with large catalogs where pre-selecting products for MPM is impractical.
**Template structure:** `BODY` + `FOOTER` + `CATALOG button`
Unlike SPM and MPM where specific products are selected at template creation time, Whole Catalog always shows the current state of your Meta Catalog. A product added to your Shopify store and synced to Meta after the template was created will appear in the catalog browse automatically.
**Single Rich Card** is a promotional card with an image, body text, footer, and buttons. It does not pull from the Meta Catalog — all content is defined at template creation time and fixed.
**Catalog dependency:** None
**How catalog data is used:** Not applicable — product images are uploaded directly to the template, not sourced from the Meta Catalog. Pricing, availability, and variant data are not included automatically; they must be written into the body text manually or via variables.
**Best for:** Single-focus promotional messages where you want full control over the visual and copy — a limited-time offer, a brand announcement, a discount code delivery. The most versatile format for stores without a Meta Catalog connected.
**Template structure:** `HEADER (TEXT or IMAGE)` + `BODY` + `FOOTER` + `BUTTONS`
Single Rich Card is the right starting point for teams setting up their first templates. It requires no catalog infrastructure, approves reliably, and works for both Marketing and Utility category messages.
**Multi Rich Card (Carousel)** presents multiple cards in a horizontally swipeable carousel. Like Single Rich Card, all content is fixed at template creation time — it does not pull from the Meta Catalog.
**Catalog dependency:** None
**How catalog data is used:** Not applicable — each card's image, body, and buttons are uploaded and written at template creation. Product prices, availability, and variant options are not automatically included.
**Best for:** Multi-offer campaigns, content series, or product collections where the specific items and their copy are stable and curated — seasonal lookbooks, top-5 product features, or campaign-specific product selections that will not change.
**Template structure:** `BODY` + `CAROUSEL (multiple cards, each with IMAGE + BODY + BUTTONS)`
**Consideration:** Because carousel card content is fixed in the template, any price change or product update requires a template revision and resubmission. For frequently changing products, SPM or MPM with live catalog data is a lower-maintenance choice.
## Format comparison
| Format | Catalog required | Products shown | Content source | Best for |
| ---------------- | ---------------- | ------------------ | -------------------------- | ------------------------------------- |
| SPM | Yes | 1 specific product | Live Meta Catalog | Targeted product promotions |
| MPM | Yes | Up to 30 products | Live Meta Catalog | Collection and curated sends |
| Whole Catalog | Yes | Full catalog | Live Meta Catalog | Browse-driven, high-intent audiences |
| Single Rich Card | No | 0 — image only | Fixed at template creation | Single-focus promotions, any campaign |
| Multi Rich Card | No | Multiple (fixed) | Fixed at template creation | Curated multi-offer carousels |
## Catalog readiness checklist for product formats
Before using SPM, MPM, or Whole Catalog formats in a campaign or automation:
* [ ] Meta Catalog is connected under **Settings → WhatsApp Connection**
* [ ] All products to be referenced have `SYNCED` status in **Catalog**
* [ ] Product images are JPEG or PNG, minimum 500×500px
* [ ] Meta Catalog access token is valid — check **Settings → WhatsApp Connection**
* [ ] No `FAILED` products in the intended message's product selection
## Related guides
* [Meta Catalog](./meta-catalog) — Connecting and managing the Meta Catalog integration
* [Catalog Health](./catalog-health) — Monitoring SYNCED, PENDING, and FAILED status
* [Templates — Template Formats](/whatsapp/templates/template-formats) — Template structure for each format
* [Campaigns — Message Composition](/whatsapp/campaigns/message-composition) — Using these formats in campaigns
# Catalog
Source: https://docs.digifist.com/galantis/whatsapp/catalog/index
The commerce data layer of Galantis — syncing product and collection data from Shopify to Galantis and Meta for use in WhatsApp product messages.
The Catalog module manages the flow of product data from Shopify through Galantis and into Meta. It is the infrastructure that makes WhatsApp product messages possible — Single Product Messages, Multi-Product Messages, and Whole Catalog browsing all depend on a synced, healthy catalog. Without it, none of these message formats can function.
Catalog is not a feature you configure once and forget. Product data changes — prices update, variants go out of stock, new collections launch, images are replaced. The Catalog module keeps that data current automatically through Shopify webhooks and propagates changes to Meta when needed.
## What the Catalog module does
At its core, the Catalog module does three things:
1. **Syncs Shopify product and collection data into Galantis** — automatically via webhooks whenever products change, or manually on demand
2. **Stores and manages that data in Galantis** — making it available for automation conditions, segment rules, and message templates
3. **Pushes product data to Meta** — keeping your WhatsApp catalog in sync with your Shopify store so product messages display accurate prices, availability, and imagery
## When you need the Catalog module
The Catalog module is **required** if you plan to use any of the following:
* Single Product Messages (SPM)
* Multi-Product Messages (MPM)
* Whole Catalog messages
* Back-in-Stock automation flows that reference product data
The Catalog module is **not required** for:
* Standard campaign broadcasts using text, image, or video templates
* Automation flows that do not use product message formats
* Inbox conversations
* Back-in-Stock widget subscription capture (catalog is required for the notification template only)
## Guides in this section
Automatic webhook-based sync and manual full re-sync — how product data moves from Shopify into Galantis.
All product and collection fields synced from Shopify, their mapping, and the exclude flag.
How product variants, prices, inventory quantities, and option combinations are stored and kept current.
Connecting, creating, and syncing your Meta Catalog — the three available catalog flows.
SPM, MPM, Whole Catalog, Rich Card, and Carousel — message formats that use catalog data.
Sync success rates, product errors, and PENDING / SYNCED / FAILED status per product.
## Setup sequence
If you are configuring the Catalog module for the first time, follow this order:
Go to **Catalog → Shopify Sync** and click **Sync Now** to import your full product and collection catalog into Galantis. See [Shopify Sync](./shopify-sync).
Check that product data has imported correctly — titles, prices, variants, and images. Exclude any products that should not be pushed to Meta using the `exclude_from_syncforce` flag. See [Product Fields](./product-fields).
Link an existing Meta Catalog or create a new one directly from Galantis. See [Meta Catalog](./meta-catalog).
Trigger the initial Meta push and verify per-product sync status. Resolve any `FAILED` items before using product message formats. See [Catalog Health](./catalog-health).
## Related guides
* [Getting Started — First Catalog Sync](/whatsapp/getting-started/first-catalog-sync) — End-to-end walkthrough for first-time setup
* [Templates — Template Formats](/whatsapp/templates/template-formats) — How catalog data is used in SPM, MPM, and Whole Catalog templates
* [Back-in-Stock](/whatsapp/back-in-stock/index) — How catalog inventory data drives restock notifications
# Meta Catalog
Source: https://docs.digifist.com/galantis/whatsapp/catalog/meta-catalog
Connecting, creating, and syncing your Meta Catalog in Galantis — the three available catalog flows and how ongoing sync works.
A Meta Catalog is the product database that powers WhatsApp's native commerce features — product cards, catalog browse, and the buy interface customers see when they tap a product in a WhatsApp message. Galantis connects to Meta Catalog to push your Shopify product data into WhatsApp, keeping the two systems in sync automatically.
Connecting a Meta Catalog is required before any SPM, MPM, or Whole Catalog message format can be used. Without it, product-based templates cannot be activated.
## What this covers
* The three Meta Catalog flows available in Galantis
* How to connect or create a catalog
* How ongoing automatic sync works
* Per-product sync status tracking
* Error handling and recovery
## Three catalog flows
Galantis supports three paths for connecting your product data to Meta, depending on whether you already have a Meta Catalog configured.
**Import an existing Meta Catalog** — connect a catalog you have already configured in Meta Commerce Manager and sync it into Galantis.
Use this flow if:
* You already have a Meta Catalog set up and populated in Meta Commerce Manager
* You are migrating to Galantis from another tool that managed your Meta Catalog
* You want Galantis to manage sync going forward but the catalog structure already exists
**How it works:**
In Galantis, go to **Settings → WhatsApp Connection** and connect a Meta Catalog access token. This token is obtained from Meta Business Manager and grants Galantis permission to read and write to your catalog.
Galantis fetches your available Meta Catalogs and lets you select which one to connect.
Galantis imports the existing catalog structure and product data into Galantis records, reconciling them with your synced Shopify products.
Once imported, Galantis manages ongoing sync between Shopify product updates and the connected Meta Catalog automatically.
After importing, Galantis becomes the source of truth for catalog updates — it pushes changes from Shopify to Meta. Direct edits in Meta Commerce Manager will be overwritten the next time the catalog sync runs with updated Shopify data.
**Create a new Meta Catalog from Galantis** — build and push a catalog directly from your Shopify data, without needing to set anything up in Meta Commerce Manager first.
Use this flow if:
* You do not have an existing Meta Catalog
* You are setting up WhatsApp commerce for the first time
* You want the simplest possible setup path
**How it works:**
In Galantis, go to **Settings → WhatsApp Connection** and connect a Meta Catalog access token with catalog creation permissions.
In **Catalog → Meta Sync**, select the option to create a new catalog. Galantis creates the catalog structure in Meta on your behalf and associates it with your WhatsApp Business Account.
Galantis pushes all non-excluded Shopify products to the newly created Meta Catalog. Products with `PENDING` status are queued for upload.
Review the per-product status in **Catalog** — products move from `PENDING` to `SYNCED` or `FAILED` as the push completes.
**Automatic Meta sync** — once a catalog is connected (via either of the above flows), Galantis keeps Meta in sync automatically.
This job runs periodically and handles:
* Pushing product updates that arrived via Shopify webhook since the last sync
* Propagating price changes, inventory updates, and image changes to Meta
* Removing products from Meta that were deleted in Shopify
* Queuing products with `PENDING` status for their initial push
**Sync frequency:** The Meta catalog sync runs periodically for batch uploads.
The automatic sync means you generally do not need to manually trigger a Meta push after your initial setup. Price changes, new product additions, and inventory updates flow through automatically.
If you make bulk product changes in Shopify and need them reflected in Meta immediately, trigger a Meta push from **Catalog → Meta Sync**.
## Per-product Meta sync status
Every product in Galantis has a Meta sync status that reflects its current state in the push pipeline:
| Status | Description |
| --------- | --------------------------------------------------------------------- |
| `PENDING` | Queued for Meta upload — not yet pushed |
| `SYNCED` | Successfully pushed to Meta — product is live in the catalog |
| `FAILED` | Sync error — the product was not pushed to Meta; review error details |
Status is visible per product in **Catalog → \[Product Name]**. The overall catalog health view in **Catalog** shows aggregate counts across all three statuses. See [Catalog Health](./catalog-health) for how to interpret and act on these statuses.
## Meta Catalog access token
Connecting a Meta Catalog requires a catalog access token from Meta Business Manager. This token:
* Must have permissions to read and write to the target catalog
* Is stored encrypted per tenant in Galantis
* Can expire or be revoked if permissions change in Meta Business Manager
If catalog sync stops working or `FAILED` statuses appear unexpectedly across many products simultaneously, the first diagnostic step is to verify the Meta Catalog token is still valid under **Settings → WhatsApp Connection**. A revoked or expired token will cause all Meta push attempts to fail until the token is refreshed.
If your Meta Catalog access token expires, catalog sync will fail silently for all products until the token is renewed. Product data in Meta will become stale — prices, availability, and images will not reflect Shopify changes. Monitor catalog health periodically to catch token expiry issues early. See [Catalog Health](./catalog-health).
## Related guides
* [Shopify Sync](./shopify-sync) — How product data flows from Shopify into Galantis before being pushed to Meta
* [Catalog Health](./catalog-health) — Monitoring SYNCED, PENDING, and FAILED status across your catalog
* [Support — Catalog Sync Errors](/whatsapp/support/troubleshooting/catalog-sync-errors) — Resolving failed Meta pushes
* [Templates — Template Formats](/whatsapp/templates/template-formats) — How Meta Catalog data is used in SPM, MPM, and Whole Catalog templates
# Product Fields
Source: https://docs.digifist.com/galantis/whatsapp/catalog/product-fields
All product and collection fields synced from Shopify into Galantis — field mapping, storage, and the exclude_from_syncforce flag.
When Galantis syncs a product from Shopify, it maps the Shopify product data to a structured record stored in Galantis. This record is what powers WhatsApp product messages, automation condition evaluations, Back-in-Stock eligibility checks, and segment rules based on purchased collections or brands.
Understanding what is synced — and what each field is used for — helps diagnose issues, build accurate segment rules, and manage which products appear in your WhatsApp catalog.
## What this covers
* All product fields synced from Shopify and their purpose in Galantis
* How collection data is stored and used
* The `exclude_from_syncforce` flag and when to use it
* The full product JSON payload storage
## Product fields
| Field | Source | Purpose in Galantis |
| ------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------- |
| `title` | Shopify | Product name — displayed in SPM and MPM product cards, available as a template variable via `order.product_name` |
| `description` | Shopify | Full product description — stored and available for catalog display |
| `vendor` | Shopify | Brand name — used in segment rules (`Purchased brand`) and catalog filtering |
| `tags` | Shopify | Product tags — used in the `PRODUCT_IN_ORDER_HAS_TAG` automation condition |
| `images` | Shopify | Product images — displayed in product message formats and catalog browse; must meet Meta's format requirements for Meta sync |
Product tags deserve particular attention. They are the mechanism that connects Shopify's product taxonomy to Galantis automation logic — the `PRODUCT_IN_ORDER_HAS_TAG` condition in automation flows evaluates these tags. If product tags are not consistently applied in Shopify, condition-based automation branching on product category will not work reliably.
Product images must be JPEG or PNG format and at least 500×500px to pass Meta's validation during catalog push. Products with images that do not meet these requirements will fail on the Meta sync step. The images are stored correctly in Galantis regardless — the format requirement applies only to the Meta push. See [Catalog Health](./catalog-health).
| Field | Source | Purpose in Galantis |
| ------------------ | ------- | -------------------------------------------------------------------------------------------- |
| `price` | Shopify | Per-variant price — displayed in product message formats and catalog browse |
| `compare_at_price` | Shopify | Original or pre-sale price — displayed alongside `price` in product cards to show a discount |
| `availability` | Shopify | In-stock or out-of-stock status — determines Back-in-Stock widget eligibility per variant |
Price and availability data are among the most time-sensitive fields in the catalog. Both are updated automatically whenever a change is saved in Shopify. A price change takes effect in Galantis within seconds of the Shopify save.
Availability is derived from the variant-level `inventory_quantity` field — when `inventory_quantity` drops to `0`, the variant becomes eligible for Back-in-Stock subscriptions. When it returns to a positive value, the `BACK_IN_STOCK` trigger fires. See [Variants & Pricing](./variants-pricing) for the full variant-level data model.
| Field | Source | Purpose in Galantis |
| ------------- | ------- | ------------------------------------------------------------------------------------------------ |
| `collections` | Shopify | Collection memberships — used in segment rules (`Purchased collection`) and catalog organization |
| `variants` | Shopify | All variant options for the product — stored with individual pricing and inventory |
| `sku` | Shopify | Stock-keeping unit per variant — stored for catalog reference and product identification |
Collection memberships are synced from Shopify collection webhooks and kept current as products are added to or removed from collections in Shopify. This data feeds the `Purchased collection` segment rule — if a customer has purchased any product from a given collection, Galantis knows this from the order history joined against collection membership data.
| Field | Source | Purpose in Galantis |
| ------ | ------- | ------------------------------------------------------------------------ |
| `data` | Shopify | Full Shopify product JSON payload stored alongside the structured fields |
Galantis stores the complete Shopify product JSON payload alongside the structured fields. This serves as a source-of-truth backup — if a specific Shopify product attribute is not mapped to a dedicated Galantis field, it is still accessible from the full payload.
## The exclude\_from\_syncforce flag
The `exclude_from_syncforce` flag can be set on any individual product record in Galantis. When set, the product is excluded from being pushed to Meta during catalog sync operations.
**What it does:**
* Prevents the product from being included in Meta Catalog pushes (both initial push and incremental sync updates)
* The product remains in Galantis — it is still synced from Shopify, still appears in your Galantis catalog, and still available for segment rules and automation conditions
* The product will not appear in SPM, MPM, or Whole Catalog messages sent via WhatsApp
**What it does not do:**
* It does not remove the product from Shopify
* It does not prevent the product from being synced from Shopify into Galantis
* It does not affect Back-in-Stock widget eligibility for the product's variants
**When to use it:**
* Products that are not ready for customer-facing WhatsApp commerce (draft products, internal SKUs, gift cards)
* Products with images that fail Meta's format requirements and cannot be fixed immediately — exclude them to prevent them from blocking the broader catalog push
* Products that are available on your Shopify store but should not be surfaced in WhatsApp messages for business reasons (wholesale-only items, B2B products)
**How to set it:**
Navigate to **Catalog → \[Product Name]** and toggle the exclude flag on the product record. The flag takes effect on the next Meta sync operation.
## Collection fields
Collections are synced into Galantis as separate records with their own webhook pipeline:
| Field | Source | Purpose |
| ---------- | ------- | ------------------------------------------------- |
| `title` | Shopify | Collection name |
| `products` | Shopify | Products associated with this collection |
| `handle` | Shopify | URL handle — used for collection-level deep links |
Collection data is used primarily for segment rule evaluation (`Purchased collection` condition) and for organizing product selections in MPM templates into labeled sections.
## Related guides
* [Shopify Sync](./shopify-sync) — How and when these fields are synced from Shopify
* [Variants & Pricing](./variants-pricing) — Variant-level field detail beyond the product-level fields above
* [Meta Catalog](./meta-catalog) — How synced fields are mapped when pushing to Meta
* [Catalog Health](./catalog-health) — How field-level issues (e.g., image format) affect sync status
* [Automations — Conditions](/whatsapp/automations/conditions) — How `tags` and `collections` are used in condition evaluation
# Shopify Sync
Source: https://docs.digifist.com/galantis/whatsapp/catalog/shopify-sync
How Galantis syncs product and collection data from Shopify — automatic webhook-based sync and manual full re-sync.
Galantis keeps your product and collection data current through two sync mechanisms: an automatic webhook-based system that fires within seconds of changes in Shopify, and a manual full sync you can trigger on demand. The automatic sync is the default and recommended method — once your initial import is complete, Galantis handles the rest without intervention.
## What this covers
* How automatic webhook-based sync works
* When and how to trigger a manual sync
* Which Shopify events trigger which sync jobs
* Sync timing and what to expect
## Automatic sync
Automatic sync is event-driven. Whenever a product or collection is created, updated, or deleted in Shopify, Shopify sends a webhook to Galantis. Galantis processes the webhook through a dedicated job and updates the corresponding record in Galantis within seconds.
This is the default and recommended sync method. It requires no configuration after the initial app installation — webhook registration happens automatically when Galantis is installed.
### Product sync events
| Shopify event | What is updated in Galantis |
| --------------- | ----------------------------------------------------------------------- |
| Product created | Creates a new product record in Galantis |
| Product updated | Updates title, description, price, images, tags, variants, availability |
| Product deleted | Removes the product record from Galantis |
### Collection sync events
| Shopify event | What is updated in Galantis |
| ------------------ | ----------------------------------------------- |
| Collection created | Creates a new collection record in Galantis |
| Collection updated | Updates collection name, products in collection |
| Collection deleted | Removes the collection record from Galantis |
### What automatic sync covers
Every product field that matters for WhatsApp messaging is kept current by automatic sync: title, description, price, compare-at price, availability, images, tags, collection memberships, variants, SKUs, and vendor. See [Product Fields](./product-fields) for the full field mapping.
Price changes and inventory changes — including stock going to zero and back — are processed automatically and reflected in Galantis within seconds of the Shopify save.
Automatic sync reflects changes made in Shopify — it does not sync changes made directly in Meta Commerce Manager. If you edit product data in Meta outside of Galantis, those changes will be overwritten the next time the Shopify product is updated and the webhook fires.
## Manual sync
Manual sync triggers a full re-import of your entire Shopify product and collection catalog. It processes every product and collection in your store in a single batch operation.
**When to use manual sync:**
* **Initial setup** — the first sync after installing Galantis, to populate the catalog database with all existing products
* **After bulk edits in Shopify** — if you use a bulk product editor or CSV import tool in Shopify, individual product webhooks may not fire for all changed products; a manual sync ensures everything is current
* **After resolving sync errors** — if a series of webhook-based syncs failed and your Galantis catalog has fallen behind, manual sync recovers the full state
* **After reconnecting a Meta Catalog** — if the Meta Catalog connection was interrupted and product data needs to be re-verified
**How to trigger a manual sync:**
Go to **Catalog → Shopify Sync** in the Galantis dashboard.
Click **Sync Now** to begin the full import. The sync processes all products and collections in your Shopify store.
The sync runs as a background job. Progress and any per-product errors are visible in the sync status view as the job completes.
Manual sync on a large catalog can take time to complete. Products and collections are processed sequentially, and a store with thousands of products may take several minutes. Do not trigger multiple manual syncs simultaneously — allow the current sync to complete before initiating another.
## Sync timing
| Sync type | Typical latency | Triggered by |
| -------------------- | -------------------------- | ----------------------------------------------------------- |
| Automatic (webhook) | Seconds after Shopify save | Shopify product/collection create, update, or delete events |
| Manual (full import) | Minutes for large catalogs | Merchant-triggered from Catalog → Shopify Sync |
## What is not covered by automatic sync
* **Abandoned checkout product data** — checkout-level product data is polled separately for the abandoned checkout automation trigger, not via the catalog sync
* **Meta Catalog push** — automatic Shopify sync updates Galantis records but does not automatically push all changes to Meta. Meta sync has its own configuration. See [Meta Catalog](./meta-catalog)
* **Products excluded via `exclude_from_syncforce`** — excluded products are not pushed to Meta, but they are still synced into Galantis from Shopify. The flag only controls Meta propagation, not Galantis-side sync
## Related guides
* [Product Fields](./product-fields) — All fields synced from Shopify and how they are stored
* [Meta Catalog](./meta-catalog) — How synced Shopify data is pushed to Meta
* [Catalog Health](./catalog-health) — Monitoring sync status and resolving errors
* [Support — Catalog Sync Errors](/whatsapp/support/troubleshooting/catalog-sync-errors) — Troubleshooting failed syncs
# Variants & Pricing
Source: https://docs.digifist.com/galantis/whatsapp/catalog/variants-pricing
How product variants, inventory quantities, prices, and option combinations are stored in Galantis and kept current from Shopify.
In Galantis, every product variant is stored with its own price, inventory quantity, SKU, images, and option combination. Variant-level data is what makes Back-in-Stock subscriptions work at the size and color level, what determines whether a product appears as in-stock in WhatsApp product messages, and what feeds automation conditions that evaluate product-level inventory.
## What this covers
* How variants are stored in Galantis
* All variant-level fields and their purpose
* How inventory quantity drives Back-in-Stock eligibility
* How price updates are handled
* How `selected_options` represents variant combinations
## Variant data model
Each variant record in Galantis stores the following fields:
| Field | Source | Purpose |
| -------------------- | ------- | ------------------------------------------------------------------------------------------------------------- |
| `price` | Shopify | Per-variant price — displayed in SPM and MPM product cards, updated on each product update webhook |
| `compare_at_price` | Shopify | Pre-sale or original price — used to display a crossed-out price alongside the current price in product cards |
| `inventory_quantity` | Shopify | Current stock level — the primary field for Back-in-Stock eligibility and availability display |
| `sku` | Shopify | Stock-keeping unit — product identification per variant |
| `image` | Shopify | Variant-specific image — overrides the parent product image in product cards when set |
| `selected_options` | Shopify | The option combination for this variant (e.g., `Size: M, Color: Blue`) |
## How inventory quantity works in Galantis
`inventory_quantity` is the most operationally significant variant field. Its value drives two distinct behaviors:
### Back-in-Stock eligibility
When `inventory_quantity` reaches `0` for a specific variant, that variant becomes eligible for Back-in-Stock subscriptions. The storefront widget appears on the product page for that variant, and customers can submit their WhatsApp number to subscribe.
When `inventory_quantity` changes from `0` to any positive value on a variant with active subscribers, the `BACK_IN_STOCK` automation trigger fires for each subscriber. See [Back-in-Stock — Notification Logic](/whatsapp/back-in-stock/notification-logic) for the full pipeline.
### Availability in WhatsApp product messages
In SPM and MPM templates, variant availability is reflected in the product card shown to the customer. Variants with `inventory_quantity = 0` are marked as unavailable. This data is kept current via automatic Shopify webhook processing within seconds of any inventory change.
Availability in WhatsApp product messages reflects the state of the Galantis catalog record at the time the message is sent, not a live Shopify query. For most stores this is effectively real-time given the seconds-level webhook latency — but in edge cases where a webhook fails or is delayed, a product card may show availability that differs from the live Shopify state. See [Catalog Health](./catalog-health) for monitoring and error recovery.
## Price updates
Price changes in Shopify — including sale prices, compare-at prices, and variant-level price adjustments — are synced to Galantis within seconds of being saved in Shopify.
The updated `price` and `compare_at_price` values are then propagated to Meta on the next catalog sync, ensuring product cards in WhatsApp messages display current pricing.
**Price update flow:**
```
Shopify price change saved
→ products/update webhook fires
→ Price updated in Galantis
→ Meta Catalog updated with new price
→ WhatsApp product messages show current price
```
The time between a Shopify price change and that change appearing in a WhatsApp product message is typically seconds to minutes, depending on the Meta sync job interval.
## selected\_options
`selected_options` stores the specific combination of option values that defines a variant. It is a structured array — for example:
```json theme={null}
[
{ "name": "Size", "value": "M" },
{ "name": "Color", "value": "Blue" }
]
```
This data is used in WhatsApp product messages to display variant options to the customer — when a customer taps a product in an SPM or MPM card, they can select from the available variant options before adding to cart.
`selected_options` is also what Galantis uses to identify which specific variant a Back-in-Stock subscriber signed up for. A customer who subscribed to "Size: M, Color: Blue" will only receive a notification when that specific combination is restocked — not when a different size or color of the same product becomes available.
## Variants in product messages
When a product is displayed in an SPM template, the customer sees the product card with the option to select a variant before proceeding. Galantis passes all active variants for the product to Meta as `PRODUCT_SECTIONS` data in the template, letting WhatsApp's native commerce UI handle variant selection.
For MPM templates, variant data is included for each of the up to 30 products in the message. Customers can tap any product in the list and select their preferred variant from the product detail view.
## Best practices
* **Keep Shopify inventory data accurate.** Galantis relies entirely on Shopify inventory values — if Shopify shows `inventory_quantity > 0` for an out-of-stock variant due to a Shopify inventory management misconfiguration, Galantis will not trigger Back-in-Stock notifications when the product is actually restocked.
* **Use variant-specific images where available.** A product with multiple color variants benefits from variant-level images in WhatsApp product cards — customers seeing the correct color image have higher conversion intent than those seeing a generic product shot.
* **Monitor price sync after sale events.** After a Shopify sale ends and prices revert, verify that the Meta Catalog has received the updated pricing. Check **Catalog → \[Product]** for `SYNCED` status with a recent timestamp.
## Related guides
* [Product Fields](./product-fields) — Product-level fields that accompany variant data
* [Meta Catalog](./meta-catalog) — How variant data is pushed to Meta for product messages
* [Back-in-Stock — Notification Logic](/whatsapp/back-in-stock/notification-logic) — How `inventory_quantity` drives restock notifications
* [Back-in-Stock — Product & Inventory Rules](/whatsapp/back-in-stock/product-inventory-rules) — Per-variant subscription behavior
# Conversation Window
Source: https://docs.digifist.com/galantis/whatsapp/compliance/conversation-window
The 24-hour customer service window — when free-form messages are allowed, when a template is required, and how free entry-point conversations open it without cost.
WhatsApp's 24-hour customer service window decides whether you can send a free-form message or whether an approved template is required. The rule is simple: a customer messages you, the window opens for 24 hours, and within that window you can reply with anything (text, images, documents, voice). Outside the window, only approved templates can be sent. Understanding this rule directly affects how you configure automations, respond in the Inbox, and time your campaigns.
The 24-hour window is separate from the **conversation categories** (Marketing, Utility, Authentication, Service) that Meta uses for billing on its own side. In Galantis, every delivered template consumes 1 Conversation credit at a flat rate, regardless of category — see [Billing — conversations](/galantis/whatsapp/billing/conversations).
## How the window works
The window opens (or resets) every time the customer sends you an inbound message.
| Event | Effect on the window |
| ---------------------------------------------------------- | -------------------------------------------- |
| Customer sends an inbound message | Window opens or resets to a fresh 24 hours |
| 24 hours pass with no new inbound message | Window closes |
| Agent or automation sends a message **within** the window | Permitted — free-form (no template required) |
| Agent or automation sends a message **outside** the window | Approved template required |
A customer who messages you daily effectively keeps the window open continuously. A customer who hasn't messaged in over a day requires a template to re-open the conversation.
## What's allowed inside the window
Within an active 24-hour window, agents and automation replies can send **session messages** — free-form text, images, documents, audio, or video — without any template approval. This is the most flexible messaging mode and is the entire point of the customer service window.
Session messages are how human-supported customer service feels natural on WhatsApp.
## What's required outside the window
Once the window has closed, the only messages that can be sent are **pre-approved WhatsApp templates**. This applies to:
* **All campaign broadcasts** — campaigns are always proactive outbound, never inside a window
* **All automation-triggered messages** — automations fire on Shopify events (new order, abandoned checkout) or platform events, not customer inbound messages
* **Inbox agent replies** when no active window exists for that customer
The Inbox UI shows the window state on every conversation. If the window is closed, the reply box switches from free-form to a template picker — you can't accidentally send a session message when a template is needed.
## Free entry-point conversations
Two scenarios open a **free** 24-hour service window with Meta — meaning Meta doesn't charge for the conversation on its side (Galantis credit deduction still applies for any template sent outside that window).
A customer clicks a Click-to-WhatsApp ad on Facebook or Instagram and is taken into a WhatsApp conversation with your number. The resulting 24-hour window is a free entry-point conversation on Meta's billing.
A customer initiates a conversation by clicking the Galantis chat widget on your storefront. The resulting 24-hour window is treated as customer-initiated and qualifies as a free entry-point conversation.
Why this matters in practice:
* **Inbound is cheap**: Investing in click-to-WhatsApp ads and the storefront widget converts ad clicks into chats with no Meta conversation cost for the first 24 hours.
* **Reply in time**: Respond inside the 24-hour window with session messages — no template approval bottleneck, no Meta charge for opening the conversation.
* **Capture consent**: A customer messaging you first isn't automatic marketing consent. If you want to send them campaigns later, capture explicit opt-in during or after the conversation. See [Opt-in & consent](/galantis/whatsapp/compliance/opt-in-consent).
## How Galantis tracks the window
Galantis tracks the window state per customer-conversation pair. The Inbox UI surfaces it directly; under the hood, every outbound send checks the timestamp of the customer's most recent inbound message:
```mermaid theme={null}
flowchart TD
A[Outbound send requested] --> B{Customer messaged us in last 24h?}
B -->|Yes| C[Window open — session message allowed]
B -->|No| D[Window closed — template required]
D --> E{Sender is a campaign or automation?}
E -->|Yes| F[Send approved template]
E -->|No, Inbox agent| G[Force template picker in UI]
```
The same logic governs billing: a delivered template counts as 1 Conversation credit regardless of whether it opens a new window or extends an existing one. See [Billing — conversations](/galantis/whatsapp/billing/conversations).
## Impact on Inbox agents
When an agent opens a conversation:
* **Window active** → reply box accepts free-form messages, images, voice notes, documents
* **Window closed** → reply box switches to a template picker; the agent selects an approved template to re-open the conversation
The Inbox interface reflects the current state per conversation. Agents don't manually check timestamps; the interface guides correct behavior. See [Inbox — conversation lifecycle](/galantis/whatsapp/inbox/conversation-lifecycle).
## Impact on automations
**Automation flows always send templates**, regardless of whether a window is open. This is by design — automations fire on Shopify or platform events (new order, abandoned checkout, restock), not in response to a customer message, so they're always treated as proactive outbound.
If you want to incorporate a customer reply into an automation's logic, use a `USER_REPLY_STATUS` condition node to branch the flow based on whether the customer responded to a previous message — see [Automations — conditions](/galantis/whatsapp/automations/conditions).
## Edge cases
Their reply opens a new 24-hour window. You can now respond with session messages in the Inbox until the window closes again.
Each inbound resets the 24-hour clock. Effectively the window stays open as long as the customer keeps engaging.
The window is based on real (UTC) time, not the customer's local time. A reply 23 hours after their message is still inside the window; a reply 25 hours after is outside.
Allowed but typically unnecessary — session messages are free-form and flexible. Some agents use templates inside the window for consistency on transactional acknowledgements (order status, refund confirmation).
***
The mechanics of each message type and when to use which.
Consent rules that apply alongside the conversation window.
How conversation statuses interact with the window in the agent Inbox.
How delivered templates consume credits regardless of conversation category.
# GDPR & Data Privacy
Source: https://docs.digifist.com/galantis/whatsapp/compliance/gdpr-data-privacy
How Galantis handles data deletion requests, the controller / processor relationship for WhatsApp data, cross-border transfers, and how other privacy regimes (LGPD, CCPA, UK GDPR) map onto the same framework.
Galantis processes personal data synced from Shopify — names, phone numbers, emails, purchase history, consent records — to power your WhatsApp marketing. That makes you a **data controller** for your customers' data, Galantis a **data processor** acting on your instructions, and Meta a separate controller for the WhatsApp messages and metadata that pass through its infrastructure. This page explains what that means in practice and how Galantis handles deletion, access, and cross-border data flows under GDPR and related regulations.
This page is informational, not legal advice. Your store may have additional obligations depending on jurisdiction and business model. When in doubt, consult a qualified data-protection lawyer.
## The controller / processor relationship
Three parties handle customer data in a Galantis-on-Shopify setup. Their roles matter because regulators (and customers exercising their rights) need to know who's responsible for what.
| Party | Role | Responsibility |
| ---------------------- | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **You (the merchant)** | Data controller for your customers | Decide why and how customer data is processed: what campaigns to send, what consent to capture, what segments to build |
| **Galantis** | Data processor on your behalf | Process customer data only on your instructions: sync from Shopify, send through Meta's API, store consent and message history |
| **Meta** | Independent controller for WhatsApp data | Operate the WhatsApp Business Platform; retains message metadata per its own [Privacy Policy](https://www.whatsapp.com/legal/privacy-policy) |
| **Shopify** | Data processor on your behalf (for store data) | Provides the order, customer, and consent webhooks Galantis consumes |
Galantis's role as a processor is governed by a **Data Processing Agreement (DPA)** that comes into force when you install the app. The DPA covers what data we process, on what legal basis, with what security measures, and how sub-processors are managed.
Contact your Galantis account manager or [support](/galantis/whatsapp/support) if you need a counter-signed copy of the DPA for your records or for your own customer-facing privacy notice.
## Data deletion requests
Shopify is the intermediary for GDPR compliance requests. When a deletion request is submitted — either by a customer or by you on behalf of your store — Shopify fires a webhook to every installed app, including Galantis.
Galantis handles two webhook topics:
| Webhook | Trigger | What Galantis does |
| ------------------ | ------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| `customers/redact` | A specific customer requests deletion of their personal data | The customer's `marketing_state` is set to `REDACTED`; personal identifiers are scrubbed; message history is anonymised |
| `shop/redact` | A merchant uninstalls Galantis and requests full shop data removal (typically 48 hours after uninstall) | All customer records, message history, and configuration for that workspace are erased |
### The REDACTED state
When a `customers/redact` webhook arrives, Galantis moves the affected customer's `marketing_state` to `REDACTED`. From that moment:
* They're removed from all campaign audience calculations
* They're skipped in all automation message actions
* They don't receive Back-in-Stock notifications, even if they had an active subscription
* They cannot be re-added to lists or segments for messaging
**`REDACTED` is permanent within Galantis.** Unlike `UNSUBSCRIBED`, which can be reversed by a new explicit opt-in, `REDACTED` cannot be reversed through normal platform actions. Re-engaging a redacted customer requires a fresh data-collection event with full compliance — typically treated as a new customer record.
### Verifying a deletion
A customer's `marketing_state` is visible in **Audience → Contacts → \[Customer Name]**. A `REDACTED` status confirms the deletion request was processed by Galantis. If you need a formal confirmation for the customer or for an audit log, support can issue a deletion receipt with the date, source webhook, and the data scrubbed.
## Other data subject rights
GDPR (and similar regimes) grants customers several rights beyond deletion. Here's how each is handled in a Galantis-on-Shopify setup:
Customers can request a copy of the personal data you hold about them. In Galantis, this includes their contact profile, consent history, message history, and any segment membership. Export this from **Audience → Contacts → \[Customer Name] → Export**. Combine with the equivalent export from Shopify for a complete view.
Customers can request correction of inaccurate data. Edit the customer profile directly in **Audience → Contacts → \[Customer Name]**. Note: phone numbers used for WhatsApp routing are validated against Meta — invalid numbers won't accept messages even if you save them.
Covered by the `customers/redact` flow above. Customers can also request deletion directly through Shopify's customer account or via your store's privacy page.
A machine-readable export of a customer's data is available via the **Export** action on the customer profile. The export is JSON-formatted and includes all fields covered under the right to access.
A customer can request you stop processing their data without deleting it. In practice, set their `marketing_state` to `UNSUBSCRIBED` to halt all marketing sends while keeping the record for legitimate purposes like order history.
Customers can object to direct marketing. The customer's STOP reply on WhatsApp, or an opt-out via Shopify's marketing preferences, sets `marketing_state` to `UNSUBSCRIBED` and stops marketing sends immediately.
## Cross-border data transfers
WhatsApp Business Platform infrastructure is operated by Meta primarily from the United States. Sending a WhatsApp message to a customer in the EU means EU personal data crosses to US infrastructure.
For GDPR compliance, this transfer relies on:
* **Standard Contractual Clauses (SCCs)** — the European Commission's approved framework for EU → US data transfers, embedded in Meta's terms and in the Galantis DPA
* **Supplementary measures** — encryption in transit (TLS) and at rest, access controls, and audit logging
* **Transparency** — informing your customers in your privacy notice that WhatsApp messages may transit via Meta's US infrastructure
If you sell to EU customers, your store's privacy policy should mention that opting into WhatsApp marketing involves processing by Meta in the US, with reference to Meta's [Privacy Policy](https://www.whatsapp.com/legal/privacy-policy).
## Data retention
Galantis retains your store's data as long as the app is installed, plus a short grace period after uninstall to handle accidental re-installs. After the `shop/redact` webhook fires (typically 48 hours post-uninstall), all data is erased per our DPA.
Meta has its own retention for WhatsApp messages and metadata, governed by its [Privacy Policy](https://www.whatsapp.com/legal/privacy-policy). Galantis cannot delete data Meta retains independently — but Meta also honors data deletion requests submitted through its own channels.
## Other privacy regimes
GDPR is the most comprehensive framework, but customers in other regions are protected by similar regulations. The Galantis flow described above satisfies the deletion-and-access core of each:
Lei Geral de Proteção de Dados — closely modeled on GDPR. Same data-subject rights, similar consent rules. The `customers/redact` flow handles deletion requests from Brazilian customers identically.
Post-Brexit, the UK retained GDPR with minor adjustments. Functionally identical handling: same DPA, same SCCs framework for transfers, same flow for deletion.
California's framework centers on the right to know, delete, and opt out of sale or sharing of personal information. Customer deletion via the standard `customers/redact` flow covers the right to delete. Galantis does not sell or share customer data with third parties for cross-context behavioral advertising.
Australia's Privacy Act, Singapore's PDPA, Turkey's KVKK, South Africa's POPIA, and others follow similar principles. The GDPR-aligned approach — explicit consent, audit trail, easy withdrawal, prompt deletion — satisfies the substantive requirements of most regimes.
## What you should document on your side
Even with Galantis handling enforcement automatically, your store still needs visible documentation of how WhatsApp data is handled:
* **Privacy notice update**: mention WhatsApp as a marketing channel, that Meta processes the messages on its infrastructure (US-hosted), and link to Meta's privacy policy
* **Opt-in language at point of capture**: specific enough to be valid under GDPR ("Receive WhatsApp messages about orders and offers from \[Store]" — not "Receive marketing")
* **DPA on file**: keep a counter-signed copy of the Galantis DPA accessible
* **Records of consent**: Galantis stores these automatically — see [Opt-in & consent](/galantis/whatsapp/compliance/opt-in-consent#proof-of-consent--keep-your-audit-trail)
* **Data subject request log**: keep a log of access / deletion / portability requests and your response time (typically within 30 days under GDPR)
***
Full reference for consent states and how they're enforced across the platform.
Managing consent at the audience level — bulk export, audit, and compliance reporting.
Meta's policy for what they retain and how they handle data subject rights on their side.
Shopify's documentation on the data deletion webhooks Galantis consumes.
# Compliance
Source: https://docs.digifist.com/galantis/whatsapp/compliance/index
WhatsApp messaging policies, consent rules, conversation-window mechanics, phone-number quality, and data privacy — the cross-cutting rules every Galantis feature respects.
WhatsApp's Business Platform is a permission-based channel. Every campaign, automation, inbox reply, and Back-in-Stock notification from Galantis runs through the same compliance pipeline before a message reaches a customer: explicit opt-in, the right conversation window for the message type, an approved template if needed, and clean phone-number quality. Get these five right and the platform stays open. Get them wrong and Meta restricts your account.
Compliance is not optional and it is not a Galantis policy choice — it's Meta's enforcement, baked into the WhatsApp Business Platform itself. Templates can be paused, throughput can be cut, and phone numbers can be suspended. The guides below explain how Galantis automates each rule so you don't have to police it yourself.
## The five pillars
Marketing requires explicit opt-in. Galantis tracks consent state per customer and refuses sends to anyone who hasn't subscribed.
The 24-hour customer service window decides whether free-form messages are allowed or a template is required.
What each message type is, when each is required, and how to avoid send failures from picking the wrong one.
Phone number quality rating, messaging tiers (1.000 → unlimited per day), and how to keep your number in the green.
Data deletion via Shopify webhooks, controller/processor relationship, cross-border transfers, and regional regulations (GDPR, LGPD, CCPA).
## What every merchant should know on day one
Meta's [Business Messaging Policy](https://business.whatsapp.com/policy) is unambiguous: "You may only contact people on WhatsApp if (a) they have given you their mobile phone number; and (b) you have received opt-in permission." Galantis enforces this — see [Opt-in & consent](/galantis/whatsapp/compliance/opt-in-consent) for how it's captured and tracked.
The customer service window opens when a customer messages you. Inside, you can reply freely. Outside, every outbound message must be a Meta-approved template. See [Conversation window](/galantis/whatsapp/compliance/conversation-window).
Submitting a marketing message as a Utility template — to bypass marketing restrictions or to save on Meta's per-message cost — is a Meta policy violation. Templates get rejected, and repeat violations downgrade your phone number's quality. See [Templates vs session messages](/galantis/whatsapp/compliance/templates-vs-session).
Block rate, report rate, and customer feedback drive a Green / Yellow / Red rating. Yellow throttles you; Red can suspend your number. See [Quality & deliverability](/galantis/whatsapp/compliance/quality-deliverability).
Shopify forwards GDPR `customers/redact` and `shop/redact` webhooks to Galantis. Affected records are moved to a `REDACTED` state and removed from all future sends. See [GDPR & data privacy](/galantis/whatsapp/compliance/gdpr-data-privacy).
## Read this section before going live
A campaign that targets non-opted-in customers will not send. An automation that fires outside the conversation window must use a pre-approved template. A customer who replies STOP is excluded from every future send. Reading these five guides before configuring your first campaign saves real troubleshooting time later — and it's how merchants avoid the slow drip of quality-rating damage that takes months to recover from.
## Meta's official policies
The canonical rulebook for what you can and can't do on the WhatsApp Business Platform.
What products and services are prohibited from being promoted or sold via WhatsApp.
# Opt-in & Consent
Source: https://docs.digifist.com/galantis/whatsapp/compliance/opt-in-consent
How Galantis captures, tracks, and enforces customer marketing consent — the foundation Meta requires before any marketing message can be sent.
WhatsApp's Business Platform is a permission-based channel. Meta's [Business Messaging Policy](https://business.whatsapp.com/policy) requires explicit opt-in before any marketing message reaches a customer: *"You may only contact people on WhatsApp if (a) they have given you their mobile phone number; and (b) you have received opt-in permission."*
Galantis enforces this at the platform level. Every campaign, automation, and Back-in-Stock notification validates consent before a send is queued — customers without `SUBSCRIBED` status are excluded automatically. You can't accidentally message a non-opted-in customer through Galantis.
Sending marketing messages to non-opted-in customers is a Meta policy violation. It drives high block rates, damages your phone number's quality rating, and can result in throttling or suspension. Manual imports of unconsented "customer lists" are the most common cause of this — see [Manual import](#manual-import) for the rules.
## Consent states
Galantis tracks consent per customer using the `marketing_state` field. Every customer has exactly one state at any time:
| State | Meaning | Can receive marketing? |
| ---------------- | ----------------------------------------------------------------- | --------------------------- |
| `SUBSCRIBED` | Customer has explicitly opted in | ✅ Yes |
| `PENDING` | Consent captured, awaiting confirmation (e.g. double opt-in flow) | ❌ No |
| `NOT_SUBSCRIBED` | No opt-in on record | ❌ No |
| `UNSUBSCRIBED` | Previously opted in, now opted out | ❌ No |
| `UNKNOWN` | No consent information available | ❌ No |
| `INVALID` | Bad or unverifiable data | ❌ No |
| `REDACTED` | GDPR / data deletion applied | ❌ No (permanently excluded) |
Only `SUBSCRIBED` customers are eligible for marketing-category sends. Campaigns and automations filter the audience automatically — there's no manual override.
**Utility, authentication, and service messages** to existing customers don't require marketing opt-in but still need the customer to have provided their phone number for a legitimate business reason (e.g. checkout, shipping confirmation). See [Templates vs session messages](/galantis/whatsapp/compliance/templates-vs-session) for which message categories require what consent.
## How consent is collected
Galantis supports four collection methods. Each results in a `SUBSCRIBED` or `PENDING` state being recorded with a timestamp and source — the **proof of consent** you'll want if Meta or a regulator ever asks.
An opt-in checkbox at checkout. When the customer checks the box and the order completes, Shopify fires the `customers/marketing_consent_updated` webhook and Galantis records the consent with `source: shopify_checkout`, the timestamp, and the order ID.
Most stores rely on this as their primary capture method. The checkbox text and position are configured in your Shopify checkout settings.
Use plain, specific opt-in language ("I want to receive WhatsApp messages about my orders and offers from \[Store]") rather than a generic "marketing updates." Specific language drives lower block rates after the first send.
When a customer submits their WhatsApp number through the Back-in-Stock subscription widget, the act of submission constitutes explicit consent for restock notifications and (optionally, if your widget config asks) general marketing. Galantis records `source: back_in_stock_widget`, the timestamp, and the product they subscribed to.
Back-in-Stock captures consent from high-intent customers — they're actively asking to be contacted.
When a customer starts a conversation from your storefront chat widget, the inbound message itself establishes a service-window context. This is not the same as marketing opt-in — a customer who messages you about a shipping question hasn't agreed to receive promotional messages. The 24-hour service window lets you reply, but marketing messages still require separate explicit opt-in.
Galantis records `source: storefront_widget` and the conversation reference.
Customers can be imported manually into Galantis with explicit consent confirmation at the time of import — for example, consent that was collected through an in-store sign-up form, a printed flyer with QR code, or a third-party form.
Manual import as `SUBSCRIBED` requires verifiable proof of opt-in. Importing customers without a valid opt-in record (purchased lists, scraped numbers, "they bought from us so they must want marketing") is a Meta policy violation and almost always results in phone-number quality damage within days.
Required fields on import: source description, opt-in date, and a brief reference to the consent record (form ID, location, etc.). These are stored alongside the customer for audit purposes.
## Collecting WhatsApp consent at checkout
WhatsApp marketing requires customers to opt in. Until Shopify's native WhatsApp consent is available, you can collect consent by repurposing the checkout **SMS marketing opt-in** checkbox and relabeling it to clearly mention WhatsApp.
In Shopify admin, go to **Settings → Checkout → Marketing opt-in** and find the **SMS** option. You can edit the label under **Online Store → Themes → Theme content → Checkout marketing → Accept SMS checkbox label**.
Set the SMS marketing opt-in to **Checkout only** so the checkbox appears.
Change the label so it clearly refers to WhatsApp, not SMS. Keep it short, and translate it into your store's language. Example:
*Send me order updates and offers on WhatsApp*
The label must clearly say WhatsApp so customers know what they are opting in to. Mentioning offers keeps the consent valid for marketing. Shopify still records this as SMS marketing consent in its data model; that is expected with this interim setup.
This is a temporary approach. Shopify is adding native WhatsApp consent through its API. Once it is available, switch to that instead of repurposing the SMS checkbox.
## Proof of consent — keep your audit trail
If Meta investigates a quality issue, or a regulator asks under GDPR / LGPD / CCPA, you'll need to show how each customer consented. Galantis retains:
* **Consent source** (Shopify checkout, BIS widget, chat widget, manual import)
* **Timestamp** of opt-in
* **Reference identifier** (Shopify order ID, BIS subscription ID, chat thread ID, manual-import reference)
* **Opt-in language shown** to the customer at the time (where applicable, captured automatically for Shopify checkout)
Access this per-customer in **Audience → Contacts → \[Customer Name] → Consent history**. It's exportable from the same screen for legal or audit responses.
## Where consent is enforced
Consent validation runs automatically in three places:
The campaign send job filters the final audience to `SUBSCRIBED` only. Customers in any other state are excluded from the send, even if they appear in a selected list or segment.
Before an automation's message action dispatches, Galantis validates the customer's state. `UNSUBSCRIBED` and `REDACTED` customers are skipped and the skip is recorded in the automation's activity log.
Restock notifications are sent only to subscribers whose state is `SUBSCRIBED` (or who subscribed specifically via the BIS widget, even without broader marketing opt-in).
## Opt-outs
When a customer replies **STOP** (or a localized equivalent like "PARE", "ARRÊT", "STOPPEN") to any WhatsApp message, Meta and Galantis both immediately mark them as opted-out. Their `marketing_state` becomes `UNSUBSCRIBED`. From that moment:
* They're excluded from all campaign sends
* They're skipped in every automation message action
* They don't receive Back-in-Stock notifications, even on active subscriptions
**Re-subscription requires a new explicit opt-in event from the customer** — re-submitting through the BIS widget, completing checkout with the opt-in box again, or a clearly logged in-store sign-up. Galantis does not allow a manual override from `UNSUBSCRIBED` back to `SUBSCRIBED` — this is intentional, to prevent accidental re-engagement of opted-out customers.
## Regional regulatory overlays
Meta's opt-in rule is a global baseline. On top of that, regional regulations add specific requirements:
Marketing consent must be **freely given, specific, informed, and unambiguous**. Pre-ticked checkboxes are not valid. Consent must be granular (the customer should know they're opting in to WhatsApp specifically, not "marketing in general"). Customers have a right to withdraw consent at any time as easily as they gave it — Galantis's STOP handling satisfies this, but your own opt-in flow must not bury withdrawal options.
Lei Geral de Proteção de Dados follows GDPR closely. Explicit purpose, granular consent, easy withdrawal. Records of consent and purpose must be maintained.
California's framework focuses on the right to know, delete, and opt out of sale or sharing of personal information. While not strictly a consent regime for marketing in the way GDPR is, California residents can request deletion via Galantis's standard GDPR flow — see [GDPR & data privacy](/galantis/whatsapp/compliance/gdpr-data-privacy).
Similar rules apply in many other jurisdictions: PDPA (Singapore, Thailand), POPIA (South Africa), PIPL (China — note WhatsApp itself is restricted there), KVKK (Turkey). When in doubt, the GDPR-aligned approach (explicit, specific, withdrawable opt-in with audit trail) covers most other regimes.
## Best practices
* **Use specific language** at the opt-in point — "Receive WhatsApp messages about orders and offers" beats "Receive marketing communications"
* **Capture separate opt-ins per category** where possible (transactional updates vs promotional offers). Meta's policy explicitly recommends this for lower block rates.
* **Stay close to the opt-in event**: contacts who opt in and receive their first message within 24-48 hours engage at much higher rates than contacts who opt in then hear nothing for weeks
* **Honor STOP everywhere**: never re-engage `UNSUBSCRIBED` customers through other channels or by re-importing them
* **Keep the consent log** — export it before any major audit or Meta investigation
***
How the `REDACTED` state is applied and what other data rights customers have.
How sending to non-opted-in contacts damages your phone number rating.
Managing consent at the audience level — bulk export, audit, and consent history.
The canonical rulebook.
# Quality & Deliverability
Source: https://docs.digifist.com/galantis/whatsapp/compliance/quality-deliverability
WhatsApp's quality rating (High / Medium / Low / Flagged), the four messaging tiers (1.000 → unlimited per 24 hours), how to move up, and how to recover a damaged phone number.
Meta continuously rates every WhatsApp Business phone number based on how customers respond to your messages. A high quality rating unlocks higher daily messaging tiers — eventually unlimited — while a low quality rating throttles or suspends your number. Quality is not a one-time setup; it's the direct, ongoing result of how relevant, well-timed, and consent-respecting your messaging is.
This page covers how Meta calculates quality, what the four messaging tiers mean for your throughput, and the concrete practices that keep your number in the green.
## Phone number quality rating
Meta assigns each phone number a quality rating, visible in **Meta Business Manager → WhatsApp Manager → Phone numbers**:
| Quality | Meaning | Impact |
| ------------------------ | ------------------------------------------------------- | ------------------------------------------------------------------------------- |
| **High** (Green) | Customers respond positively, low block rate | Full throughput at your current tier; eligible for tier upgrades |
| **Medium** (Yellow) | Mixed signals; some blocks or low engagement | Warning state — no immediate throttling but continued degradation will escalate |
| **Low** (Red) | High block rate, customer reports, or policy violations | Daily throughput limit reduced; templates may be paused; tier downgrade likely |
| **Flagged / Restricted** | Severe or repeated violations | Messaging paused on this number; templates suspended; manual review required |
Meta doesn't publish the exact formula, but the [Messaging Policy](https://business.whatsapp.com/policy) confirms the inputs:
* **Block rate** — how often recipients block your number
* **Report rate** — how often messages are reported as spam
* **Engagement signals** — read rates, response rates, conversation rate
* **Template rejection patterns** — frequent rejections during review signal policy mismatch
## Messaging tiers
Meta caps how many **unique customers** you can initiate conversations with in a rolling 24-hour window, based on your tier. Your tier scales up automatically as you send high-quality conversations to qualifying numbers.
| Tier | Unique-customer cap per 24h | Typical use |
| ---------- | --------------------------- | ----------------------------------------------- |
| **Tier 1** | 1.000 | New WABA, just verified |
| **Tier 2** | 10.000 | After consistent high-quality sending at Tier 1 |
| **Tier 3** | 100.000 | Established sender with sustained high quality |
| **Tier 4** | Unlimited | Largest, highest-trust senders |
The tier cap is on **unique customers contacted in 24 hours**, not total messages. Multiple messages to the same customer don't count separately toward the cap. Replying inside an active conversation window also doesn't count.
### How to move up a tier
Meta's escalation rules require both volume and quality at the same time:
Your phone number must hold Green / High quality throughout the qualification window. A drop to Yellow during the window resets the qualification clock.
To qualify for the next tier, you need to send to a specific volume of unique customers within the past week — roughly the lower bound of the next tier (e.g. to move to Tier 2, sustain near Tier 1's 1.000-customer cap with high quality).
Tier increases are evaluated automatically by Meta. The upgrade typically appears within 24–48 hours of meeting the criteria. The new cap takes effect immediately.
You can verify your business in Meta Business Manager to unlock additional trust signals that help tier progression. See [Meta's verification process](https://www.facebook.com/business/help/2058515294227817) for details.
### How to move down a tier
A quality drop to Low (Red) typically results in:
* Immediate throughput reduction on your current tier (e.g. Tier 3 may be capped at Tier 2 levels)
* Tier downgrade if quality stays Low for \~7 days
* Template suspensions on the templates that drove the quality issues
Recovery is possible but slow — Meta requires sustained high-quality sending after the offending behavior stops. Plan to send only your best-performing, most-targeted templates during recovery; one bad campaign can extend the recovery period by days.
## How to protect your quality rating
These practices have the largest measurable impact on quality, in order of effect:
Sending to non-opted-in contacts is the fastest path to high block rates. Galantis enforces this for [Marketing-category sends](/galantis/whatsapp/compliance/opt-in-consent), but imported lists need careful review — never import a list as `SUBSCRIBED` without verifiable proof of opt-in.
A Utility template that delivers marketing content gets flagged by Meta's reviewers and, if approved by accident, by customers as spam. Use Marketing for promotional content even if Meta's per-message cost is higher — the quality hit from mis-categorization is more expensive long-term.
Messages that address the customer by name and reference their specific order or product are perceived as relevant; generic blasts read as spam. Galantis supports `{{1}}` `{{2}}` variables in every template — use them.
Configure per-automation [frequency caps](/galantis/whatsapp/automations/frequency-caps) so a single customer isn't hit by multiple automations and campaigns in the same week. Over-messaging is one of the top three drivers of blocks.
When a customer replies STOP, their state moves to `UNSUBSCRIBED` and they're excluded from every future send. Never attempt to re-engage opted-out customers through new lists, manual imports, or alternative templates — Meta tracks this as a deliberate violation.
Template buttons that link to a different page than the body implies, headers that promise content the body doesn't deliver, or misleading variables all generate complaints. Truthful templates correlate strongly with green quality ratings.
A brand-new WABA suddenly sending to 1.000 customers on day one is more likely to generate blocks than a gradual ramp from 100 to 500 to 1.000 over a week. Tier-up signals come from sustained quality, not maximum volume.
## Common violations to avoid
These are the most frequent causes of quality degradation and template rejection:
* **Marketing to non-opted-in customers** — `NOT_SUBSCRIBED`, `UNKNOWN`, or `UNSUBSCRIBED` states
* **Mis-categorized templates** — Utility templates with promotional CTAs or offer language
* **Over-messaging** — multiple campaigns or automation sequences hitting the same customers within a short period without frequency caps
* **Misleading buttons or variables** — a button URL that goes somewhere different from what the template text implies
* **Imported lists without proof of consent** — purchased lists, scraped numbers, or "they bought from us once so they must want marketing"
* **Re-engaging opted-out customers** — re-importing UNSUBSCRIBED customers under new lists is treated as a deliberate workaround
## Monitoring quality from Galantis
Galantis surfaces the message-level signals that move quality before Meta's rating catches up to them:
Per-campaign and per-automation delivered / read / failed rates. Sudden drops in read rate are an early warning of quality degradation.
Daily new opt-outs by campaign and automation. A spike correlates strongly with the next quality downgrade.
Templates pending, approved, or rejected — including rejection reasons that point at category mismatches.
Meta's authoritative rating, viewed in WhatsApp Manager. Galantis links out — this lives in Meta, not in your Shopify dashboard.
## Recovering from a damaged number
If your number drops to Yellow or Red:
1. **Stop the offending sends immediately.** Pause campaigns and automations that triggered the drop — don't try to "send something better to recover."
2. **Audit what happened.** Review the last 7–14 days of sends, opt-outs, and template approvals. Identify the campaign or automation that drove block / report spikes.
3. **Tighten consent.** Re-verify that everyone you're sending to is genuinely opted in. Remove any imported lists you can't prove consent for.
4. **Resume with your best performers.** Send only your highest-engagement templates to your most engaged audience segments. Build up volume gradually.
5. **Monitor daily.** Track quality in Meta Business Manager and read / opt-out rates in Galantis. Recovery is measurable in days to weeks, not hours.
If a number is fully flagged or restricted, recovery may require a Meta appeal — see Meta's [policy enforcement documentation](https://business.whatsapp.com/policy) and contact Galantis support for guidance.
***
How Galantis enforces consent — the single biggest input to quality.
Template-specific quality signals and optimization.
Configuring per-automation and per-customer send limits.
Authoritative phone number quality view in Meta Business Manager.
# Templates vs Session Messages
Source: https://docs.digifist.com/galantis/whatsapp/compliance/templates-vs-session
When a pre-approved template is required and when a free-form session message can be used — and how the four conversation categories (Marketing, Utility, Authentication, Service) affect both.
WhatsApp defines two types of outbound messages: **template messages** (pre-approved structured messages) and **session messages** (free-form messages inside an active 24-hour conversation window). Which type is required depends entirely on whether the window is open. Get this wrong and the message fails to send — there's no graceful fallback.
This page covers the mechanics of each message type, when each is mandatory, and how the four conversation categories (Marketing, Utility, Authentication, Service) shape what content you can put in a template.
## Quick reference
| | Template message | Session message |
| -------------------------------- | ----------------------------------------------- | ----------------------------------------------- |
| **Requires Meta approval** | ✅ Yes | ❌ No — free-form |
| **When it can be sent** | Any time, inside or outside the window | Only inside an active 24-hour window |
| **Content** | Fixed structure with optional dynamic variables | Free-form text, images, documents, audio, video |
| **Use in campaigns** | Required | Not allowed |
| **Use in automations** | Required | Not allowed |
| **Use in Inbox (window open)** | Optional — session messages preferred | Preferred |
| **Use in Inbox (window closed)** | Required | Not allowed |
## Template messages
Template messages are pre-approved by Meta before they can be sent. They have a fixed structure — header (text, image, video, document, or location), body (with optional dynamic variables), footer, and buttons (quick replies, URLs, or phone numbers) — with variables that are populated at send time from customer or order data.
Templates are required for:
* **All campaign broadcasts** — campaigns are always proactive outbound
* **All automation-triggered messages** — automations fire on Shopify or platform events, not customer messages
* **Any proactive outbound message** when no active conversation window exists
* **Inbox agent replies** when the 24-hour window has closed
Templates are created and submitted via **Templates → New template** in the Galantis app. Approval typically takes minutes to a few hours; some categories (Authentication) get reviewed faster than others. A template in `DRAFT`, `PENDING`, or `REJECTED` status cannot be sent.
**Match the template category to the actual content.** Submitting a marketing message as a Utility template — to bypass marketing restrictions or to save on Meta's per-message cost — is a Meta policy violation. Templates get rejected during review, and repeat violations downgrade your phone number's quality. See [Template categories](/galantis/whatsapp/templates/template-categories) for the rules of each category.
## The four conversation categories
Every template you submit must be categorized as one of Meta's four [conversation categories](https://whatsappbusiness.com/products/conversation-categories/marketing/):
Promotional and transactional-with-promotional content. Discounts, product launches, abandoned-cart recoveries, re-engagement. **Requires explicit marketing opt-in.** Highest Meta per-message cost.
Transactional, informational, service messages about a customer's existing relationship with your store. Order confirmations, shipping updates, return status. **No marketing opt-in required** (but the customer must have provided their number).
One-time passcodes (OTP) and verification messages. Login codes, account verification, password reset. Strict format requirements; lowest Meta per-message cost.
Free-form replies inside the 24-hour customer service window. Doesn't require an approved template — this is the session-message mode.
In Galantis, **every delivered template consumes exactly 1 Conversation credit**, regardless of category — see [Billing — conversations](/galantis/whatsapp/billing/conversations). Meta's per-conversation cost on its own invoice varies by category and destination country; that's a separate Meta charge, not a Galantis credit. See [Meta rate card](/galantis/whatsapp/billing/meta-rate-card).
## Session messages
Session messages are free-form and require no approval. They can only be sent inside an active 24-hour [conversation window](/galantis/whatsapp/compliance/conversation-window) — meaning the customer must have sent an inbound message within the last 24 hours.
Session messages are available to:
* **Inbox agents** replying to an active inbound conversation
* (Automations and campaigns never use session messages — they always send templates regardless of window state)
Inside an open window, session messages support:
* Free-form text up to 4,096 characters
* Images, videos, documents, audio messages, voice notes
* Contact cards and locations
* Interactive components (quick replies, list messages)
This is what makes WhatsApp feel like genuine customer support — agents reply naturally without picking from a fixed list of pre-approved phrases.
## Practical implications
**For campaign builders** — every campaign requires a template. There is no session-message equivalent for broadcast sends. Plan template creation and approval time into your campaign schedule: 1–2 days lead time is safe for Marketing templates, 1–2 hours typically for Utility, and minutes for Authentication.
**For automation builders** — every Action node sends a template. When building flows, ensure the template assigned to each Action node has `APPROVED` status before activating the automation. Automations referencing unapproved templates are flagged in the validator and can't be activated until resolved.
**For Inbox agents** — the Inbox interface adapts to the window state. With an active window, agents type freely. Once the window closes, the reply box switches to a template picker so agents pick an approved template to re-open the conversation. No manual time-tracking is needed.
## Why category accuracy matters
Submitting the wrong category isn't just a paperwork issue — it cascades into real problems:
* **Higher rejection rate at submission**: Meta's reviewers actively check that content matches the declared category. A promotional message submitted as Utility is the most common rejection reason.
* **Quality damage if approved by accident**: If a mis-categorized template slips through and customers report it as unwanted marketing, your phone number's quality rating takes a hit. See [Quality & deliverability](/galantis/whatsapp/compliance/quality-deliverability).
* **Policy strikes**: Repeated mis-categorization is treated as a deliberate workaround and can lead to messaging restrictions or account-level enforcement.
The shortest path through these problems: be honest about what each template is. If it includes a discount, CTA, or offer — Marketing. If it's a status update with no promotion — Utility. If it's a one-time code — Authentication. See [Template categories](/galantis/whatsapp/templates/template-categories) for full guidance.
***
How the 24-hour window opens, resets, and closes.
Detailed rules for what content fits in Marketing, Utility, and Authentication.
Marketing requires opt-in; Utility doesn't — the consent rules in detail.
How to build, submit, and manage templates in Galantis.
# Developer Reference
Source: https://docs.digifist.com/galantis/whatsapp/developer-reference/index
Technical reference for Galantis integrations — WhatsApp Cloud API endpoints and Shopify and Meta webhook payload reference.
The Developer Reference covers the external API and webhook interfaces that Galantis integrates with. It is intended for engineers and technical teams who need to understand which Meta Cloud API endpoints Galantis uses, and the full payload structure for every Shopify and Meta webhook the platform registers and receives.
## What this section covers
All Meta Cloud API endpoints Galantis calls — message sending, template management, media upload, and catalog.
Complete payload reference for all registered Shopify and Meta webhooks.
## Related sections
For merchant-facing integration behavior — how data flows between Shopify, Galantis, and Meta, how webhooks drive automation triggers, and how to manage the Shopify and Meta connections — see the [Integrations](/whatsapp/integrations/index) section.
# Webhooks Reference
Source: https://docs.digifist.com/galantis/whatsapp/developer-reference/webhooks-reference
Complete payload reference for all Shopify and Meta webhooks registered and received by Galantis.
This page is the authoritative payload reference for every webhook Galantis registers with Shopify and every webhook event it receives from Meta. It covers the topic, the expected payload structure, and what the webhook drives in Galantis.
For the processing behavior and downstream effects of each webhook, see [Integrations — Shopify Webhooks](/whatsapp/integrations/shopify/webhooks) and [Integrations — Meta Webhooks](/whatsapp/integrations/meta-whatsapp/meta-webhooks). This page focuses on payload structure for developer reference.
## Security
**Shopify webhooks** — All incoming Shopify webhooks are validated via HMAC signature verification using the `X-Shopify-Hmac-Sha256` header before processing. Requests with invalid or missing signatures are rejected with a `401` response and never reach the handler.
**Meta webhooks** — All incoming Meta webhooks are validated via signature verification using the `X-Hub-Signature-256` header before processing. Invalid signatures are rejected.
Both verifications use the app secret for their respective platform. Webhook payloads are never processed without a valid signature.
***
## Shopify webhooks
### Customer webhooks
**`customers/create`**
```json theme={null}
{
"id": 123456789,
"email": "customer@example.com",
"first_name": "Jane",
"last_name": "Smith",
"phone": "+521234567890",
"tags": "vip, newsletter",
"accepts_marketing": true,
"email_marketing_consent": {
"state": "subscribed",
"opt_in_level": "single_opt_in"
},
"sms_marketing_consent": {
"state": "subscribed",
"opt_in_level": "single_opt_in"
},
"locale": "es",
"created_at": "2025-01-15T10:00:00-05:00",
"updated_at": "2025-01-15T10:00:00-05:00"
}
```
***
**`customers/update`**
Same structure as `customers/create`. All fields are included in the payload — Galantis diffs the incoming data against the stored record to identify changes.
***
**`customers/delete`**
```json theme={null}
{
"id": 123456789
}
```
Only the customer ID is included. Galantis uses the ID to locate and remove the corresponding contact record.
***
**`customers/marketing_consent_updated`**
```json theme={null}
{
"id": 123456789,
"email_marketing_consent": {
"state": "subscribed",
"opt_in_level": "single_opt_in",
"consent_updated_at": "2025-01-15T10:05:00-05:00"
},
"sms_marketing_consent": {
"state": "subscribed",
"opt_in_level": "single_opt_in",
"consent_updated_at": "2025-01-15T10:05:00-05:00"
},
"phone": "+521234567890",
"updated_at": "2025-01-15T10:05:00-05:00"
}
```
Galantis maps the SMS/phone marketing consent state to the corresponding internal consent status on the contact record.
***
**`customer_tags/added`**
```json theme={null}
{
"customer_id": 123456789,
"tags_added": ["vip", "loyalty-gold"]
}
```
***
**`customer_tags/removed`**
```json theme={null}
{
"customer_id": 123456789,
"tags_removed": ["loyalty-silver"]
}
```
***
### Order webhooks
**`orders/create`**
```json theme={null}
{
"id": 987654321,
"order_number": 1042,
"customer": {
"id": 123456789,
"phone": "+521234567890"
},
"total_price": "149.00",
"currency": "MXN",
"line_items": [
{
"id": 111111,
"title": "Running Shoes",
"quantity": 1,
"price": "149.00",
"product_id": 555555,
"variant_id": 666666,
"vendor": "NikeMX",
"properties": []
}
],
"tags": "",
"fulfillment_status": null,
"financial_status": "paid",
"created_at": "2025-01-15T11:00:00-05:00"
}
```
***
**`orders/cancelled`**
Same structure as `orders/create` with `cancelled_at` and `cancel_reason` fields added:
```json theme={null}
{
"id": 987654321,
"order_number": 1042,
"customer": { "id": 123456789 },
"total_price": "149.00",
"cancelled_at": "2025-01-16T09:00:00-05:00",
"cancel_reason": "customer"
}
```
***
**`orders/updated`** (used for shipping)
```json theme={null}
{
"id": 987654321,
"order_number": 1042,
"customer": { "id": 123456789 },
"fulfillment_status": "fulfilled",
"fulfillments": [
{
"id": 222222,
"status": "success",
"tracking_company": "DHL",
"tracking_number": "1234567890",
"tracking_url": "https://track.dhl.com/...",
"created_at": "2025-01-16T14:00:00-05:00"
}
]
}
```
Galantis interprets `orders/updated` payloads to drive the relevant automation triggers (for example, `ORDER_SHIPPED` when fulfillment data indicates a successful shipment). See [Automations — triggers](/galantis/whatsapp/automations/triggers) for the available triggers.
***
### Product and collection webhooks
**`products/create`**
```json theme={null}
{
"id": 555555,
"title": "Running Shoes",
"body_html": "
Full product description...
",
"vendor": "NikeMX",
"tags": "shoes, running, sport",
"images": [
{ "id": 777777, "src": "https://cdn.shopify.com/...", "width": 1000, "height": 1000 }
],
"variants": [
{
"id": 666666,
"title": "Size 42 / Blue",
"price": "149.00",
"compare_at_price": "180.00",
"sku": "RUN-42-BLU",
"inventory_quantity": 15,
"option1": "42",
"option2": "Blue",
"image_id": 777777
}
],
"options": [
{ "name": "Size", "values": ["40", "41", "42", "43"] },
{ "name": "Color", "values": ["Blue", "Black", "White"] }
],
"status": "active",
"created_at": "2025-01-15T09:00:00-05:00"
}
```
***
**`products/update`**
Same structure as `products/create`. Galantis processes the full payload — updated fields overwrite stored values, and `inventory_quantity` changes are checked for the 0→>0 Back-in-Stock restock pattern.
***
**`products/delete`**
```json theme={null}
{
"id": 555555
}
```
***
**`collections/create`**, **`collections/update`**
```json theme={null}
{
"id": 888888,
"title": "Running Gear",
"handle": "running-gear",
"products_count": 24,
"updated_at": "2025-01-15T12:00:00-05:00"
}
```
***
**`collections/delete`**
```json theme={null}
{
"id": 888888
}
```
***
### Billing and app lifecycle webhooks
**`app_subscriptions/update`**
```json theme={null}
{
"app_subscription": {
"admin_graphql_api_id": "gid://shopify/AppSubscription/123",
"name": "Galantis Pro Plan",
"status": "ACTIVE",
"created_at": "2025-01-01T00:00:00Z",
"updated_at": "2025-01-15T00:00:00Z",
"currency": "USD"
}
}
```
***
**`app/uninstalled`**
Handler: Tenant deactivation
```json theme={null}
{
"id": 12345678,
"myshopify_domain": "your-store.myshopify.com"
}
```
***
### GDPR webhooks
**`customers/redact`**
```json theme={null}
{
"shop_id": 12345678,
"shop_domain": "your-store.myshopify.com",
"customer": {
"id": 123456789,
"email": "customer@example.com",
"phone": "+521234567890"
},
"orders_to_redact": [987654321, 987654322]
}
```
***
**`shop/redact`**
```json theme={null}
{
"shop_id": 12345678,
"shop_domain": "your-store.myshopify.com"
}
```
***
## Meta webhooks
**`messages` (inbound)**
```json theme={null}
{
"object": "whatsapp_business_account",
"entry": [{
"id": "{waba_id}",
"changes": [{
"value": {
"messaging_product": "whatsapp",
"metadata": {
"display_phone_number": "521234567890",
"phone_number_id": "{phone_number_id}"
},
"contacts": [{
"profile": { "name": "Jane Smith" },
"wa_id": "521234567890"
}],
"messages": [{
"from": "521234567890",
"id": "wamid.{message_id}",
"timestamp": "1705320000",
"type": "text",
"text": { "body": "Hello, I have a question about my order" }
}]
},
"field": "messages"
}]
}]
}
```
For `QUICK_REPLY` button responses, the `messages[0].type` is `"interactive"` and the payload includes:
```json theme={null}
"interactive": {
"type": "button_reply",
"button_reply": {
"id": "{button_id}",
"title": "{button_label}"
}
}
```
***
**`message_status` (status update)**
```json theme={null}
{
"object": "whatsapp_business_account",
"entry": [{
"id": "{waba_id}",
"changes": [{
"value": {
"messaging_product": "whatsapp",
"metadata": {
"display_phone_number": "521234567890",
"phone_number_id": "{phone_number_id}"
},
"statuses": [{
"id": "wamid.{message_id}",
"status": "delivered",
"timestamp": "1705320030",
"recipient_id": "521234567890"
}]
},
"field": "messages"
}]
}]
}
```
`"status"` values: `"sent"`, `"delivered"`, `"read"`, `"played"`, `"failed"`.
For `"failed"` status, an `"errors"` array is included:
```json theme={null}
"errors": [{
"code": 131047,
"title": "Re-engagement message",
"message": "Message failed to send because more than 24 hours have passed since the customer last replied to this number.",
"error_data": { "details": "..." }
}]
```
***
**`message_template_status_update`**
```json theme={null}
{
"object": "whatsapp_business_account",
"entry": [{
"id": "{waba_id}",
"changes": [{
"value": {
"event": "APPROVED",
"message_template_id": 123456,
"message_template_name": "order_confirmation_es",
"message_template_language": "es",
"reason": null
},
"field": "message_template_status_update"
}]
}]
}
```
`"event"` values: `"APPROVED"`, `"REJECTED"`, `"PAUSED"`, `"DISABLED"`.
For `"REJECTED"`, the `"reason"` field contains Meta's rejection explanation.
***
## Related guides
* [Integrations — Shopify webhooks](/galantis/whatsapp/integrations/shopify/webhooks) — Processing behavior and downstream effects
* [Integrations — Meta webhooks](/galantis/whatsapp/integrations/meta-whatsapp/meta-webhooks) — Processing behavior for Meta webhook events
* [Automations — triggers](/galantis/whatsapp/automations/triggers) — Which webhook events drive which automation triggers
# WhatsApp API
Source: https://docs.digifist.com/galantis/whatsapp/developer-reference/whatsapp-api
Meta Cloud API endpoints used by Galantis — message sending, template management, media upload, and catalog operations.
Galantis communicates with Meta through the WhatsApp Cloud API (Meta Graph API v23.0). This page documents every endpoint Galantis calls, the operation each performs, and relevant implementation notes.
## What this covers
* All Meta Cloud API endpoints Galantis uses
* Request patterns per endpoint category
* Rate limiting and throughput considerations
* Media upload protocol
## Base URL
All Meta Graph API calls use:
```
https://graph.facebook.com/v23.0/
```
The version segment (`v23.0`) is the Graph API version Galantis targets. Meta increments API versions periodically — Galantis pins to a specific version to ensure consistent behavior across all API calls.
## Message API
**Send a WhatsApp message**
```
POST https://graph.facebook.com/v23.0/{phone_number_id}/messages
```
Used for all outbound message sends — campaigns, automation Action Nodes, and Inbox agent template replies.
The `{phone_number_id}` path parameter identifies which of the workspace's connected phone numbers the message is sent from. For workspaces with multiple phone numbers, each send operation specifies the correct `phone_number_id` for the intended sender.
**Request body structure (template message):**
```json theme={null}
{
"messaging_product": "whatsapp",
"to": "{customer_whatsapp_number}",
"type": "template",
"template": {
"name": "{template_name}",
"language": {
"code": "{language_code}"
},
"components": [
{
"type": "body",
"parameters": [
{ "type": "text", "text": "{variable_value_1}" },
{ "type": "text", "text": "{variable_value_2}" }
]
}
]
}
}
```
Variable values are populated at send time — each `{{N}}` placeholder is resolved to its mapped customer, order, or static value before the request is constructed.
**Request body structure (session message — free-form text):**
```json theme={null}
{
"messaging_product": "whatsapp",
"to": "{customer_whatsapp_number}",
"type": "text",
"text": {
"body": "{message_text}"
}
}
```
Session messages are only sent within an active 24-hour conversation window. See [Compliance — Conversation Window](/whatsapp/compliance/conversation-window).
**Response:** Meta returns a message ID on success. This ID is stored in Galantis and used to match incoming status update webhooks back to the original send.
## Template API
**Create a message template**
```
POST https://graph.facebook.com/v23.0/message_templates
```
Called when a merchant submits a template from **Templates → New Template** in the Galantis dashboard. The full template structure — category, language, header, body, footer, and buttons — is serialized and sent to Meta for review.
**Fetch template list and status**
```
GET https://graph.facebook.com/v23.0/message_templates
```
Called to sync current template approval statuses from Meta into Galantis. Used to reconcile local template records with Meta's current state — particularly useful after a reconnection or during initial setup when template status may have changed while the connection was inactive.
Template status changes in normal operation arrive via the `message_template_status_update` webhook rather than through polling, so this endpoint is used primarily for reconciliation rather than routine status tracking.
**Delete a template**
```
DELETE https://graph.facebook.com/v23.0/message_templates
```
Called when a merchant deletes a template from the Galantis dashboard. Removes the template from Meta's system in addition to the local record.
## Media Upload API
**Upload media (resumable protocol)**
```
POST https://graph.facebook.com/v23.0/{app_id}/uploads
```
Used when a merchant uploads an image, video, or document for use as a template header. Meta's media upload uses a resumable protocol — large files are uploaded in chunks, and the upload can be resumed if interrupted.
The upload process:
1. Galantis initiates the upload session with the file size and MIME type
2. Meta returns an upload session ID
3. Galantis uploads the file data (in chunks for large files)
4. Meta returns a media handle on completion
5. The media handle is stored on the template header component and submitted with the template
Media handles are referenced in template submissions and remain valid as long as the template exists and the WABA connection is active.
**Supported media types for template headers:**
| Header type | Accepted formats | Notes |
| ----------- | ---------------- | ------------------------------------ |
| Image | JPEG, PNG | Minimum 500×500px for catalog images |
| Video | MP4 | |
| Document | PDF | Standard PDF format |
## Catalog API
**Push products to Meta Catalog**
```
POST https://graph.facebook.com/v23.0/{catalog_id}/products
```
Called to push product data from Galantis into the connected Meta Catalog. The `{catalog_id}` path parameter identifies the specific Meta Catalog associated with the workspace.
Product data is sent as a batch — multiple products are pushed in a single request where possible, reducing API call overhead for large catalogs.
The request payload maps Galantis product variant fields to Meta's product schema:
* `title` → product name
* `description` → product description
* `price` → product price (formatted per Meta's currency requirements)
* `availability` → derived from `inventory_quantity`
* `image_link` → product image URL
* Variant options → mapped to Meta's item group and variant structure
After a successful push, the product's sync status in Galantis is updated from `PENDING` to `SYNCED`. On failure, the status moves to `FAILED` with the error response stored for diagnostic review.
## Rate limiting and throughput
**Message API throughput** — WhatsApp enforces per-phone-number message sending limits that scale with the phone number's quality tier and business verification level. Galantis processes recipients in batches that respect these limits. Rate limit errors from the Message API cause the affected batch to be retried.
**Template API rate limits** — Template creation and status fetching are subject to standard Graph API rate limits. These are unlikely to be encountered in normal usage — template operations are infrequent relative to message sends.
**Catalog API rate limits** — Bulk product pushes are subject to Catalog API rate limits. Galantis processes products in batches sized to avoid exceeding these limits.
## Related guides
* [Webhooks Reference](./webhooks-reference) — Meta webhooks that deliver status callbacks for Message API sends
* [Templates](/whatsapp/templates/index) — How template submissions map to Template API calls
* [Catalog — Meta Catalog](/whatsapp/catalog/meta-catalog) — How catalog data is pushed to Meta
# AI Flow Builder
Source: https://docs.digifist.com/galantis/whatsapp/galantis-ai/ai-flow-builder
How Galantis AI assists during automation flow creation — trigger suggestions, action sequences, node configuration, and the LarAgent framework.
The AI Flow Builder is Galantis AI's active assistance mode — it engages while you are building a flow on the canvas, suggesting appropriate node configurations based on your stated goal and highlighting issues as they appear. It is powered by the LarAgent framework and operates as an intelligent layer on top of the standard visual flow editor.
## What this covers
* How AI assistance activates during flow building
* Trigger and action suggestions
* How node-level highlighting works
* Optimization suggestions surfaced during building
* The LarAgent framework
* What AI assistance does and does not control
## How AI assistance works during building
Galantis AI monitors the state of the flow canvas as you build. It does not require you to prompt it or switch to a separate interface — assistance surfaces contextually based on what nodes are placed and how they are configured.
AI assistance operates in two modes during building:
**Goal-based suggestions** — When you start a new automation, Galantis AI can accept a description of what you want the flow to accomplish and suggest a starting structure: the most appropriate trigger, a recommended delay, and an action sequence that fits the use case. This is most useful when you know the outcome you want but are less certain which trigger or condition structure achieves it.
**Inline configuration assistance** — As you place nodes and configure them, Galantis AI monitors for incomplete or potentially problematic configurations and surfaces targeted suggestions at the node level. It does not wait for you to finish the entire flow before offering input.
## Trigger and action suggestions
When Galantis AI suggests a flow structure based on a goal, it maps the described use case to the available trigger types and action sequences in Galantis. Examples of how goals map to suggestions:
| Goal described | Suggested trigger | Suggested structure |
| ------------------------------------- | ----------------------- | -------------------------------------------------------------------------- |
| Recover abandoned checkouts | `ABANDONED_CHECKOUT` | Delay 30 min → Condition (Order Value) → Action (VIP or standard template) |
| Welcome new customers | `CUSTOMER_CREATED` | Delay 10 min → Action (welcome template) |
| Re-engage lapsed buyers | `USER_ADDED_TO_SEGMENT` | Delay 1 hour → Action (win-back template) |
| Notify subscribers when stock returns | `BACK_IN_STOCK` | Action (restock notification template) |
| Cross-sell after purchase | `ORDER_PLACED` | Condition (Product tag) → Delay 3 days → Action (recommendation template) |
Suggestions are starting points — you can accept them as-is, modify the suggested structure, or discard them and build manually. Accepting a suggestion places the recommended nodes on the canvas in the suggested configuration, which you then adjust and connect to your specific templates and settings.
## Node-level highlighting
When Galantis AI detects an issue or opportunity at a specific node, it highlights that node visually on the canvas and surfaces a description in the node's settings panel. Highlights fall into two categories:
**Error highlights** — Configuration issues that will block activation. These are also caught by the formal validation step, but surfacing them during building means you can resolve issues as you go rather than encountering a list of errors at the end. Error-highlighted nodes show the specific problem — a missing template assignment, an unconnected branch, or a condition with incomplete logic.
**Advisory highlights** — Optimization suggestions that will not block activation but represent a meaningful improvement opportunity. These are discussed in more detail below.
## Optimization suggestions
Beyond errors, Galantis AI surfaces optimization suggestions on flows that are structurally valid but could perform better. These suggestions draw on automation best practices:
**Missing delay after trigger** — An automation that sends a message immediately on trigger — with no delay node — is flagged. For most use cases (abandoned checkout, new customer welcome, post-purchase), immediate dispatch produces a worse customer experience than a short delay. Galantis AI surfaces this when no delay exists between the trigger and the first action.
Galantis AI also highlights incomplete or conflicting node configurations as optimization suggestions beyond blocking errors.
## The LarAgent framework
Galantis AI is powered by LarAgent — the AI framework underlying the flow builder's intelligent assistance capabilities. LarAgent handles the interpretation of flow state, the mapping of merchant goals to node structures, and the evaluation logic behind both error detection and optimization suggestions.
LarAgent operates on the structured JSON representation of the flow — the same `nodes` and `edges` arrays that define the flow canvas. It evaluates the graph structure, node configurations, and their relationships to identify issues and generate suggestions.
## What AI assistance does and does not control
Understanding the boundaries of AI assistance prevents confusion about what Galantis AI changes versus what remains in merchant control:
**Galantis AI does:**
* Suggest trigger types and flow structures based on described goals
* Highlight nodes with configuration errors during building
* Surface optimization advisory suggestions on valid flows
* Run formal validation checks before activation
* Identify unapproved templates assigned to Action Nodes
**Galantis AI does not:**
* Create or submit templates — template creation and approval remain manual processes in the Templates module
* Automatically fix errors — it identifies and describes them, but all changes are made by the merchant on the canvas
* Send messages autonomously — all message dispatch happens through the same automation execution engine used by manually built flows
* Override merchant configuration — AI suggestions are suggestions, not enforced changes. A merchant can dismiss any advisory highlight and activate a flow that does not follow the suggested structure
## Related guides
* [Flow Validation](./flow-validation) — The formal validation checks run before activation
* [Automations — Flow Builder](/whatsapp/automations/flow-builder) — The underlying canvas, node types, and flow structure
* [Automations — Triggers](/whatsapp/automations/triggers) — All available trigger types Galantis AI can suggest
* [Automations — Recipes](/whatsapp/automations/recipes/index) — Pre-built flow examples that reflect the structures Galantis AI recommends
# Flow Validation
Source: https://docs.digifist.com/galantis/whatsapp/galantis-ai/flow-validation
The validation checks Galantis AI runs before an automation can be activated — what is evaluated, what each result means, and how to resolve issues.
Flow validation is a mandatory step that runs before any automation can be activated. It evaluates the assembled flow against a set of structural, compliance, and configuration checks and returns either a clean result — the flow can proceed to activation — or a set of flagged issues that must be resolved first.
Validation produces two types of results: **blocking checks** that must pass before activation is permitted, and **advisory checks** that surface recommendations without preventing activation.
## What this covers
* When validation runs
* Blocking checks and advisory checks
* All validation checks and what they look for
* How to read and resolve validation results
## When validation runs
Validation runs automatically when you attempt to activate an automation. It also runs continuously in the background during flow building — issues detected during building are surfaced as inline node highlights without blocking the canvas. The formal validation gate only applies at the moment of activation.
A flow can be saved in any incomplete state as a draft — validation does not prevent saving. It only prevents the transition from inactive to active.
## Check types
**Blocking checks** — Structural and compliance conditions that must pass for the flow to be activatable. A flow with any blocking failure cannot be activated until the issue is resolved.
**Advisory checks** — Logical completeness and optimization quality checks. Advisory results surface recommendations without preventing activation. A flow with unresolved advisory suggestions can still be activated.
## Validation checks
**Check:** Every Action Node in the flow must reference a template with `APPROVED` status.
**Type:** Blocking
**What is checked:** Galantis inspects every Action Node's template assignment and verifies the current status of each referenced template. If any Action Node references a template in `DRAFT`, `PENDING_APPROVAL`, or `REJECTED` status, the flow fails this check.
**Why it blocks:** WhatsApp does not accept message sends using unapproved templates. Activating a flow with an unapproved template would result in every customer who reaches that Action Node receiving a failed message send — the flow would appear active but would not function.
**How to resolve:**
* Open **Templates** and check the status of the template assigned to the flagged Action Node
* If `PENDING_APPROVAL` — wait for Meta's review to complete. Approval typically takes minutes to a few hours
* If `DRAFT` — submit the template for Meta review
* If `REJECTED` — review the rejection reason, fix the template content, and resubmit
Once the template reaches `APPROVED` status, return to the flow and attempt activation again — no changes to the flow itself are required.
A template that was `APPROVED` when the automation was built can be paused by Meta after activation. The template approval check runs at activation time — it does not continuously monitor template status after the flow is live. If a template is paused post-activation, the flow will remain active but affected Action Nodes will fail for customers who reach them.
**Check:** Every node in the flow must be connected — no orphaned nodes, no dead-end paths.
**Type:** Blocking
**What is checked:** Galantis validates that the flow graph has no disconnected nodes — every node placed on the canvas must have at least one incoming edge (except the TriggerNode, which has none by design) and at least one outgoing edge (except terminal Action Nodes and explicit exit points).
Specifically:
* Every node is reachable from the TriggerNode via a connected edge path
* No node sits on the canvas without being connected to the flow
**Why it blocks:** An orphaned node indicates an incomplete flow — either a node was placed and never connected, or a connection was deleted without removing the node. Customers enrolled in the flow would never reach disconnected nodes, making them dead configuration that implies intent but delivers nothing.
**How to resolve:** Open the canvas and look for any nodes without connecting edges. Either connect them into the flow at the appropriate position, or delete them if they were placed in error. The canvas highlights disconnected nodes when validation fails.
**Check:** Every Condition Node must have both its YES branch and NO branch connected to a subsequent node.
**Type:** Blocking
**What is checked:** Galantis inspects every Condition Node in the flow and confirms that both output paths — the YES branch and the NO branch — connect to at least one subsequent node. A condition with one connected branch and one dead-end branch fails this check.
**Why it blocks:** A condition branch that leads nowhere means customers routed down that path have no further nodes to execute — they are enrolled and then silently dropped from the flow. This is almost always a configuration error rather than an intentional design choice.
**How to resolve:**
* Identify the Condition Node with an unconnected branch — it will be highlighted on the canvas
* Connect the open branch to an Action Node, Delay Node, or another Condition Node
* If the intent is genuinely to do nothing on one path — for example, a YES branch sends a message but the NO branch should exit silently — connect the NO branch to an explicit exit node or a final Action Node appropriate for that path
If one branch of a condition should result in no action — for example, "if the customer has already ordered, exit the flow" — connect that branch to a terminal point rather than leaving it unconnected. This makes the intent explicit and passes the validation check.
**Check:** Every Condition Node must have its logic fully configured — no empty fields, no partially defined rules.
**Type:** Blocking
**What is checked:** Galantis inspects the condition logic defined in each Condition Node and verifies that every rule has a complete configuration: a condition type selected, an operator chosen, and a value provided. A condition node that was placed but not configured — or where a rule was started but not completed — fails this check.
**Common incomplete states:**
* A condition type selected but no operator or value set
* An AND/OR group with an empty rule slot
* A condition using a dynamic value source that has not been selected
**How to resolve:** Open each flagged Condition Node and complete all rule fields. Every rule in every group must have a fully specified condition type, operator, and value before the flow can activate.
**Check:** The automation must have a frequency cap configured.
**Type:** Blocking
**What is checked:** Galantis verifies that a frequency cap is set on the automation. An automation with no frequency cap configured fails this check.
**Why it blocks:** A flow without a frequency cap has no protection against a customer being enrolled and messaged multiple times in rapid succession if the trigger fires repeatedly. This is a guardrail against accidental over-messaging, which damages phone number quality and customer trust.
**How to resolve:** Open the automation settings and configure a frequency cap appropriate for the trigger type and use case. See [Automations — Frequency Caps](/whatsapp/automations/frequency-caps) for guidance on which cap to choose.
**Check:** Galantis AI evaluates the flow's logical quality against automation best practices and surfaces advisory recommendations.
**Type:** Advisory — non-blocking
Advisory checks do not prevent activation. They surface as highlighted suggestions that can be reviewed, acted on, or dismissed. A flow with unresolved advisory suggestions can still be activated.
**Common advisories:**
**Missing delay after trigger** — No Delay Node between the TriggerNode and the first Action Node. Immediate dispatch is flagged as an advisory because most use cases benefit from a short delay. Exception: the Back-in-Stock notification flow intentionally omits a delay — this advisory can be dismissed in that context.
**Identical templates on both condition branches** — Both the YES and NO paths of a Condition Node reference the same template. The condition adds no differentiation value and is likely a configuration oversight.
**High-frequency trigger with `EVER` cap** — A trigger like `ORDER_PLACED` or `CUSTOMER_CREATED` paired with an `EVER` frequency cap flags the question of whether once-per-customer-lifetime enrollment is genuinely intended. If so, the advisory can be dismissed. If not, the cap should be adjusted.
**Broad trigger with no conditions** — A trigger that fires for all customers (e.g., `CUSTOMER_CREATED`, `ORDER_PLACED`) with no Condition Node before the first Action Node sends the same message to every enrollee without differentiation. Galantis AI flags this as an opportunity to add targeting.
**How to resolve or dismiss:** Review each advisory by opening the flagged node on the canvas. If the suggestion is valid, make the recommended change. If the advisory does not apply to your specific flow design, dismiss it and proceed to activation.
## Validation result summary
| Check | Type | Blocks activation |
| -------------------------------------- | -------- | ----------------- |
| Template approval status | Blocking | Yes |
| Node connections | Blocking | Yes |
| Condition branch completeness | Blocking | Yes |
| Condition logic completeness | Blocking | Yes |
| Frequency cap configured | Blocking | Yes |
| Missing delay after trigger | Advisory | No |
| Identical templates on both branches | Advisory | No |
| High-frequency trigger with `EVER` cap | Advisory | No |
| Broad trigger with no conditions | Advisory | No |
## How to read validation results
When validation runs at activation time, results are surfaced in two ways:
**Inline on the canvas** — Nodes with blocking errors are highlighted in a distinct error state. Clicking a highlighted node opens its settings panel, which shows the specific issue and the resolution path.
**Validation summary panel** — A summary of all blocking errors and advisory suggestions appears as a list. Blocking errors must be resolved before the activation button becomes available. Advisory suggestions are listed separately and can be individually dismissed.
Work through blocking errors one at a time, starting with the simplest to resolve (unconnected nodes, missing frequency caps) before addressing more complex issues (template approval status, incomplete condition logic).
## Related guides
* [AI Flow Builder](./ai-flow-builder) — How inline validation highlights surface during building, before the formal activation check
* [Automations — Flow Builder](/whatsapp/automations/flow-builder) — The full validation check reference from the flow builder perspective
* [Templates — Approval Lifecycle](/whatsapp/templates/approval-lifecycle) — Resolving template status issues that block activation
* [Automations — Frequency Caps](/whatsapp/automations/frequency-caps) — Configuring the frequency cap required by validation
# Galantis AI
Source: https://docs.digifist.com/galantis/whatsapp/galantis-ai/index
AI-powered assistance for building, validating, and optimizing WhatsApp automation flows — built into the Galantis flow editor.
Galantis AI is an intelligent layer built directly into the automation flow builder. It helps merchants design automation flows faster, catch configuration errors before activation, and surface optimization opportunities that would otherwise require expert knowledge of WhatsApp automation best practices.
It is not a separate product or a chatbot interface. Galantis AI operates inside the visual flow canvas — suggesting, validating, and flagging as you build, without requiring any additional setup or configuration beyond using the flow builder itself.
## What Galantis AI does
Galantis AI contributes to three distinct stages of automation development:
**Building** — When you describe a goal or begin placing nodes, Galantis AI suggests appropriate triggers, conditions, and action sequences based on what you are trying to accomplish. This is most useful for merchants who are new to automation flows or who are building a flow type they have not configured before.
**Validating** — Before a flow can be activated, Galantis AI runs structural and compliance checks against the assembled flow. It identifies incomplete configurations, missing connections, unapproved templates, and logic gaps that would cause the flow to malfunction or fail to activate. Validation is not optional — it gates activation.
**Optimizing** — Beyond blocking errors, Galantis AI surfaces advisory suggestions for flows that are technically valid but could perform better. A missing delay in an abandonment recovery flow, a condition branch that sends the same template to both YES and NO paths, or a frequency cap that seems too permissive for the trigger type — these are the kinds of recommendations Galantis AI surfaces.
## Guides in this section
How Galantis AI assists during flow creation — suggestions, node types, and the LarAgent framework.
The validation checks Galantis AI runs before activation — what is evaluated and how to resolve issues.
## Relationship to the Flow Builder
Galantis AI is an enhancement to the standard flow builder — not a replacement for it. Every automation you build with AI assistance uses the same node types, trigger options, and configuration settings as a manually built flow. The underlying structure is identical.
This means flows built with AI suggestions can be fully edited, extended, and adjusted manually at any point. There is no locked-in AI structure — the canvas is always editable.
See [Automations — Flow Builder](/whatsapp/automations/flow-builder) for the full reference on node types, canvas behavior, and flow structure.
# Before You Start & Troubleshooting
Source: https://docs.digifist.com/galantis/whatsapp/getting-started/before-you-start
A quick checklist to prepare for connecting WhatsApp, plus fixes for the stumbling blocks merchants hit most during setup.
## Before you connect
Have these ready so the connection goes through in one sitting:
Be logged in to the Facebook account that manages your Business Manager, with your 2FA device on hand.
The same card you use for Meta Ads works. Meta charges per conversation.
Legal business name, address, VAT number and a website on your own .com domain.
A new dedicated number (recommended), or your existing WhatsApp Business app number for coexistence.
Setting up on a screen-share call with our team? Share your **whole desktop**, not just a browser tab. Meta's signup opens in a separate pop-up window that a single shared tab will hide.
## Common stumbling blocks
Meta's Embedded Signup opens as a separate pop-up. If you are screen-sharing, switch to sharing your entire desktop so we can see it. On your own, just bring that window to the front.
Use the browser where you are already signed in to Business Manager, and keep your 2FA device ready, since Facebook often sends a confirmation to your phone. Switching browsers (for example to Safari) can help if one keeps rejecting the login.
Select **USD**. The per-message pricing is the same; only the billing currency differs.
During verification, Meta auto-suggests businesses with names similar to yours. They are not related to you, so ignore them and enter your own business details.
Choose **verification by phone call** instead of SMS. Meta calls the number and reads out the code, so make sure someone can answer it. VoIP and toll-free numbers are often not accepted; use a regular mobile or landline.
Display-name approval for marketing messages usually clears in 1 to 2 business days. You can already send utility messages (like order confirmations) as soon as the number is verified.
## After connecting: warm up first
A new number needs warming up. WhatsApp is strict about spam and will restrict a number that sends marketing too fast.
Start with transactional messages so the number builds a healthy reputation.
Add abandoned-checkout recovery once the number is warm.
Scale into broadcasts and new-collection launches from there.
Do not send a marketing campaign on a brand-new number, even for a launch. Let it warm up first, or you risk getting the number banned.
# Choose a Phone Number
Source: https://docs.digifist.com/galantis/whatsapp/getting-started/choose-phone-number
Pick the right WhatsApp Business phone number for your store: dedicated new number (recommended), an existing number, or your WhatsApp Business app number with coexistence — all handled inside the connection modal.
The phone number you connect to Galantis becomes your store's WhatsApp identity. Customers see it on every campaign, automation, and inbox conversation. Picking the right number on day one prevents quality issues, brand confusion, and migration hassle later.
You have three legitimate paths. **We strongly recommend a new dedicated number** — but the other two work, and Meta's connection modal (Embedded Signup) handles all of them from inside the Galantis app.
You don't need to prepare anything in Meta Business Manager before installing Galantis. The connection modal lets you add a new number, pick an existing WABA number, or connect a WhatsApp Business app number with coexistence — all in one flow.
## Why a dedicated number is the best choice
A dedicated number is one that **only** powers your business WhatsApp on Galantis. Not your owner's personal WhatsApp, not your store's customer-service WhatsApp Business app, not a shared team phone.
Meta tracks message quality per phone number. A dedicated number means your marketing volume won't bring down a number you use for support — and vice versa.
Customers know exactly which number is "the store." No accidental personal replies, no confusion when a team member leaves.
A fresh number goes through Meta's verification once, with no surprises from prior usage. The display-name approval is clean.
When you later add a second number (different brand, region, or use case), the original stays clean. See [Multiple phone numbers](/galantis/whatsapp/integrations/meta-whatsapp/multiple-phone-numbers).
## Your three options
Get a fresh SIM or business line that has never been used on consumer WhatsApp, WhatsApp Business app, or another WABA. You add it inside the connection modal — Meta sends a verification code to that number to confirm ownership.
**Best for:** every store that doesn't already have a customer-facing WhatsApp number it can't change.
Most mobile or landline numbers from a major carrier work. Some VoIP and toll-free numbers are not supported by Meta — check before purchasing a number specifically for WhatsApp.
Meta verifies the number by sending a one-time code via SMS or voice call to confirm ownership.
In the Galantis app, click **Connect WhatsApp**. In the Embedded Signup modal, choose "Add a new phone number" and follow the prompts. See [Connect WhatsApp](/galantis/whatsapp/getting-started/whatsapp-connection).
If you already own a business number that has **never** been registered on consumer WhatsApp or the WhatsApp Business app, you can use it directly. The flow is the same as adding a new number — the modal sends a verification code and registers the number to your WABA.
**Best for:** stores that already have a published business line they want to keep using.
This path is for a number that has **never** been on WhatsApp — it registers directly on the Cloud API. If your number is currently on the **WhatsApp Business app** and you want to keep using the app, use the coexistence flow in the next tab instead.
If your number is currently on the **WhatsApp Business app**, you can connect it to Galantis with **coexistence**: you keep using the WhatsApp Business app exactly as you do today, while Galantis sends campaigns, automations and order updates on the same number. No migration, and you do not lose the app.
On the connect screen, choose **Continue setup**, then continue into Meta's Embedded Signup and select your existing WhatsApp Business app number.
Meta shows a screen titled "Transfer your contacts and chat history". Your business profile, your contacts and the **last 6 months of chat history** are shared with the connected account, so your recent conversations carry over.
On the phone that holds the number, scan the on-screen QR code with the **WhatsApp Business app**. Then look for a message from the official Facebook Business Account, tap **Connect**, and confirm sharing your chats. The account links in about 45 seconds.
Back in the browser, complete the remaining steps (region, payment method, business verification) on the Galantis page.
You keep replying to customers in the WhatsApp Business app as usual. New conversations also appear in the Galantis Inbox, and Galantis runs campaigns and automations on the number.
Coexistence depends on Meta eligibility: a recent WhatsApp Business app version, the number already active on that app, and regional availability. If your number is not eligible, connect a new dedicated number for Galantis and keep your existing number on the WhatsApp Business app.
## Phone number requirements
Whichever path you choose, the number must be:
* **Owned by your business** — you can receive an SMS or voice call to confirm verification
* **Not currently active on consumer WhatsApp** — if it is, sign out from consumer WhatsApp on that device first; the Embedded Signup modal will explain the next step if there's a conflict
* **From a Meta-supported number type** — most mobile and landline numbers work; some VoIP / toll-free numbers don't. See [Meta's phone number requirements](https://developers.facebook.com/docs/whatsapp/cloud-api/get-started)
## What's a display name?
The **display name** is the human-readable name shown to recipients alongside your number — for example, "Sahara Style" rather than just `+1 555 0142`. You set it during the Embedded Signup flow.
* Pick a name that matches your brand and your Meta Business name
* Avoid promotional language, all-caps shouting, or third-party brand names
* Meta reviews display names — approval is typically quick but can take 1–2 business days
For Meta's current display name rules and prohibited terms, see [Meta's WhatsApp Business Display Name guidelines](https://developers.facebook.com/docs/whatsapp/embedded-signup/onboard-clients).
## Quick decision guide
Lowest friction, cleanest quality rating, easiest to change later if your strategy evolves. Pick a fresh number, give it a clear display name aligned with your brand, and connect it through the modal.
## FAQ
Yes — you can add a second number and route campaigns / automations / inbox to it, then deactivate the original. The original number's quality rating doesn't transfer. See [Multiple phone numbers](/galantis/whatsapp/integrations/meta-whatsapp/multiple-phone-numbers).
Technically possible, but strongly discouraged. Personal WhatsApp activity affects the number's quality rating, your owner's private chats live next to business chats on the same number, and removing the owner from the team later becomes painful.
No. Connecting a WhatsApp Business app number uses **coexistence**, so you keep the app and keep replying to customers there. During setup Meta shares your business profile, contacts, and the last 6 months of chat history with the connected account, and new conversations also appear in the Galantis Inbox.
The SMS / voice-call verification is instant. The display-name review by Meta typically clears in 1–2 business days. You can start sending utility messages immediately after verification; marketing-category messages require display-name approval.
Yes. A landline is verified **by phone call** rather than SMS — Meta calls the number and reads out the code, so make sure someone can answer it. VoIP and toll-free numbers are often not accepted; use a regular mobile or landline.
Meta supports phone numbers from most countries, but a small list of regions is restricted. If verification fails because of country support, the Embedded Signup modal will explain — and Galantis support can suggest alternatives.
***
Get the app installed on your store, then connect WhatsApp.
Walk through the Embedded Signup modal step by step.
# Choose Your Connection
Source: https://docs.digifist.com/galantis/whatsapp/getting-started/choose-your-connection
The two ways to connect WhatsApp to Galantis — the full WhatsApp Platform for campaigns and automations, or a simple click-to-chat button — and which one to pick so you don't have to reconnect later.
When you connect WhatsApp during onboarding, you choose between two paths. They look similar, but they unlock very different things. Picking the right one on day one saves you from reconnecting later.
The chat-button-only option adds a clickable WhatsApp button to your store, but it **cannot send campaigns, automations, or templates**. If you installed Galantis to recover abandoned carts or run WhatsApp marketing, choose the full WhatsApp Platform connection.
## The two options at a glance
| | Full WhatsApp Platform | Chat button only |
| ------------------------------------------------------------------ | -------------------------------------------------------- | ------------------------- |
| Clickable WhatsApp button on your store | Yes | Yes |
| Campaigns and broadcasts | Yes | No |
| Automations (abandoned checkout, back-in-stock, welcome, win-back) | Yes | No |
| Message templates | Yes | No |
| Catalog and product messages | Yes | No |
| Shared Inbox with full Shopify context | Yes | Inbound only |
| What it connects | WhatsApp Business Platform (Cloud API) via Meta | A wa.me link only |
| Setup | Meta Embedded Signup, register a number, about 5 minutes | Instant, just your number |
| Cost | Paid plan plus Meta conversation charges | Free |
## Which one is right for you?
Choose this if you want to send campaigns, recover abandoned carts, or run any automation. This is the full Galantis product.
Choose this only if you just want a clickable WhatsApp button on your storefront and do not need campaigns or automations.
## Full WhatsApp Platform (recommended)
This connects your store to the **WhatsApp Business Platform (Cloud API)** through Meta's official Embedded Signup, right inside Galantis. On the connect screen, choose **"Continue setup"**. It unlocks everything Galantis is built for:
* **Campaigns** to segmented audiences with approved templates
* **Automations** that fire on Shopify events: abandoned checkout, new order, new customer, product restock
* **Message templates** and **catalog / product messages**
* The **shared Inbox** with full Shopify customer context
You will need a phone number to register. A new dedicated number is recommended for the cleanest quality rating.
Already using the WhatsApp Business app? You can keep it. See [Choose a Phone Number](/galantis/whatsapp/getting-started/choose-phone-number) for connecting your existing number with coexistence.
Walk through Meta's Embedded Signup modal step by step.
Use a new number, an existing one, or your WhatsApp Business app number with coexistence.
Marketing-category messages require Meta to approve your display name, which usually clears in 1 to 2 business days. You can send utility messages as soon as your number is verified.
## Chat button only
This adds a click-to-chat (wa.me) button to your storefront so customers can start a WhatsApp conversation with you. On the connect screen, this is the **"Use my number only"** option. It does **not** connect the WhatsApp Business Platform, so the marketing and automation features stay locked.
With the chat button only, you cannot:
* Send campaigns or broadcasts
* Run any automation (abandoned cart, back-in-stock, welcome, win-back)
* Use message templates
* Send catalog or product messages
You receive inbound chats only.
**When this is enough:** a store that only wants a simple "message us on WhatsApp" button and has no plans to send marketing or automated messages.
**Upgrading later:** you can switch to the full platform at any time from [Connect WhatsApp](/galantis/whatsapp/getting-started/whatsapp-connection). Your store keeps running while you connect.
## FAQ
Yes. Open **Connect WhatsApp** and run the full setup whenever you are ready. Nothing you have already configured is lost.
Campaigns, automations, and templates run on the WhatsApp Business Platform (Cloud API) through Meta. The chat-button option does not set that up. WhatsApp also requires pre-approved templates and customer opt-in before any marketing message can be sent. See [Opt-in & Consent](/galantis/whatsapp/compliance/opt-in-consent) and [Templates](/galantis/whatsapp/templates/index).
For the full platform, a new dedicated number is recommended for the cleanest quality rating and easiest scaling. See [Choose a Phone Number](/galantis/whatsapp/getting-started/choose-phone-number).
***
Get the app installed on your store, then connect WhatsApp.
Connect the full WhatsApp Platform through Meta's Embedded Signup.
# First Automation
Source: https://docs.digifist.com/galantis/whatsapp/getting-started/first-automation
Build and activate your first event-triggered WhatsApp automation flow.
Automations are event-driven flows that send WhatsApp messages automatically when a defined trigger occurs in Shopify or Galantis. Once active, they run without manual intervention — responding to real customer behavior in real time.
This guide walks you through building a simple automation using the visual flow builder.
## What this covers
* Choosing a trigger
* Adding a delay and an action node
* Selecting an approved template
* Activating the automation
## Before you begin
Confirm the following are ready:
* Your WhatsApp Business Account is connected — see [WhatsApp Connection](./whatsapp-connection)
* You have at least one `APPROVED` message template — see [First Campaign](./first-campaign) for how to create and submit a template
Automations can only send approved WhatsApp templates. An automation with an unapproved template will be flagged and cannot be activated.
## Building your first automation
In the Galantis dashboard, go to **Automations** and click **New Automation**.
Select the event that starts the flow. Common starting points for a first automation:
* **Abandoned Checkout** — fires when a customer starts checkout but doesn't complete it (polled every 10 minutes)
* **New Customer Created** — fires when a new customer registers on your Shopify store
* **New Order Placed** — fires immediately when an order is created
Each trigger has an option to **include existing users** — this retroactively enrolls customers who already match the trigger condition at the time of activation.
Connect a Delay node after the trigger. Set a wait time — for example, 30 minutes for an abandoned checkout recovery, or 10 minutes for a new customer welcome. This gives customers time to complete an action before receiving a message.
Connect an Action node after the delay. Select **WhatsApp Message** and choose an approved template. Map template variables to customer or order data fields.
Configure how often this automation can fire per customer (e.g., once per 24 hours, once ever). Add exclusion rules to skip specific lists or segments if needed.
Review the flow, confirm there are no validation warnings, and toggle the automation to **Active**.
## Example: New Customer Welcome
This is a simple and effective first automation:
```
Trigger: New Customer Created
→ Delay: 10 minutes
→ Action: Send welcome template with first-order discount
```
The delay prevents the message from arriving at the exact same moment as the Shopify registration confirmation email, improving the experience.
## Checking automation activity
After activating, go to **Automations → \[Automation Name] → Activity** to see a log of every customer enrolled, which nodes they passed through, and the status of each step (`COMPLETED`, `PENDING`, `FAILED`, `SKIPPED`).
## Related guides
* [Automations](/whatsapp/automations/index) — Full reference for triggers, conditions, actions, and frequency caps
* [Automation Recipes](/whatsapp/automations/recipes/index) — Pre-built flow examples for common use cases
* [Templates](/whatsapp/templates/index) — Creating and managing approved templates
# First Back-in-Stock
Source: https://docs.digifist.com/galantis/whatsapp/getting-started/first-back-in-stock
Install the Back-in-Stock widget, capture your first subscription, and test a restock notification.
The Back-in-Stock module captures customer WhatsApp numbers when a product variant is out of stock and automatically sends a notification when inventory is replenished. The widget is injected directly into your Shopify storefront — no manual theme editing is required.
This guide walks you through customizing the widget, verifying it on your storefront, submitting a test subscription, and confirming the restock notification fires correctly.
## What this covers
* Customizing the widget appearance
* Verifying the widget appears on out-of-stock product pages
* Submitting a test subscription
* Triggering a test restock notification
## Before you begin
Your WhatsApp Business Account must be connected before restock notifications can be sent. The widget itself can be installed and tested for subscription capture independently, but notifications require an active WhatsApp connection.
## Setting up the widget
In the Galantis dashboard, go to **Back-in-Stock → Settings**.
Configure the widget to match your brand. Key settings include button position (right, left, or custom), button background color, CTA label text, headline text shown in the subscription modal, and form background colors.
Visit a product page on your Shopify store where at least one variant is out of stock. The subscription button should appear automatically. If it does not appear, confirm Galantis has `write_script_tags` permission in Shopify and clear your browser cache.
Enter your own WhatsApp number in the widget form and submit. A subscription record will be created in Galantis with `ACTIVE` status.
## Testing the restock notification
In your Shopify admin, find the product and variant you subscribed to in the previous step.
Change the variant's inventory from `0` to any positive number and save. This triggers a `products/update` webhook from Shopify.
Galantis detects the inventory change, fires the `BACK_IN_STOCK` automation trigger, and sends a WhatsApp notification to all `ACTIVE` subscribers for that variant. Check your WhatsApp — you should receive the restock message within a few seconds.
In **Back-in-Stock → Subscriptions**, confirm the test subscription moved from `ACTIVE` to `NOTIFIED`. Notified subscriptions do not receive a second notification for the same restock event.
## Subscription status reference
| Status | Description |
| ----------- | ----------------------------------------------------------- |
| `PENDING` | Newly submitted, awaiting activation |
| `ACTIVE` | Enrolled — will receive notification when restocked |
| `NOTIFIED` | Notification sent — subscription expires after notification |
| `CANCELLED` | Customer unsubscribed |
Only customers with `SUBSCRIBED` or better marketing consent status receive restock notifications. Customers with `UNSUBSCRIBED` or `REDACTED` status are automatically excluded, even if they have an `ACTIVE` subscription record.
## Related guides
* [Back-in-Stock](/whatsapp/back-in-stock/index) — Full module reference including widget design options, inventory rules, and analytics
* [WhatsApp Connection](./whatsapp-connection) — Required for sending restock notifications
# First Campaign
Source: https://docs.digifist.com/galantis/whatsapp/getting-started/first-campaign
Create a WhatsApp message template, get it approved, and send your first campaign broadcast.
Campaigns are one-time WhatsApp broadcasts sent to a targeted audience. Before you can send a campaign, you need at least one approved message template — Meta must review and approve all templates before they can be used in outbound messages.
This guide walks you through creating a template, waiting for approval, and launching your first campaign.
## What this covers
* Creating and submitting a message template for Meta approval
* Setting up a new campaign
* Selecting an audience
* Scheduling or sending immediately
## Before you begin
Confirm the following are ready:
* Your WhatsApp Business Account is connected — see [WhatsApp Connection](./whatsapp-connection)
* You have at least one Customer List or Segment with `SUBSCRIBED` customers
Only customers with `SUBSCRIBED` marketing consent status are included in campaign sends. Customers who have not opted in are automatically excluded.
## Step 1 — Create and submit a template
In the Galantis dashboard, go to **Templates** and click **New Template**.
Add a header (optional), body text, footer (optional), and buttons (optional). Use `{{1}}`, `{{2}}` placeholders in the body for dynamic content such as customer name or order details.
Select **Marketing** for promotions, offers, and product announcements. Select **Utility** for transactional messages such as order confirmations or shipping updates. The category must accurately reflect the message content.
Save and submit the template. Status will change to `PENDING_APPROVAL`. Approval typically takes minutes to a few hours.
Templates in `DRAFT` or `REJECTED` status cannot be used in campaigns. Wait for `APPROVED` status before proceeding. If a template is rejected, review the rejection reason in **Templates → \[Template Name] → Status**, fix the issue, and resubmit.
## Step 2 — Create the campaign
Once your template is approved, go to **Campaigns** and click **New Campaign**.
Choose the approved template from the list. Map any template variables (e.g., `{{1}}` → `customer.first_name`) to the correct customer or order data fields.
Select one or more Customer Lists or Segments to include. You can also add exclusion rules to remove specific groups (e.g., customers who purchased in the last 7 days). Use **Estimate Reach** to preview your final audience count before sending.
Choose **Send now** to dispatch immediately, or set a future date and time to schedule the campaign.
## Checking campaign results
After sending, track performance in **Campaigns → \[Campaign Name]**:
| Metric | Description |
| ------------- | ------------------------------------------------- |
| **Sent** | Messages dispatched to the WhatsApp API |
| **Delivered** | Confirmed delivered to the customer's device |
| **Read** | Customer opened the message |
| **Failed** | Delivery failed — check per-message error details |
## Related guides
* [WhatsApp Connection](./whatsapp-connection) — Required before sending any campaign
* [Templates](/whatsapp/templates/index) — Full reference for template components and formats
* [Campaigns](/whatsapp/campaigns/index) — Audience targeting, scheduling, and analytics
# First Catalog Sync
Source: https://docs.digifist.com/galantis/whatsapp/getting-started/first-catalog-sync
Sync your Shopify products and collections into Galantis and optionally push them to Meta.
The Catalog module keeps your Shopify product data in sync with Galantis and Meta, making it available for product message templates — Single Product Messages (SPM), Multi-Product Messages (MPM), and Whole Catalog messages. Without a synced catalog, these message formats cannot function.
This guide walks you through your first manual sync, reviewing product data, and optionally connecting Meta for product messages.
## What this covers
* Triggering a full Shopify catalog sync
* Reviewing synced products and excluding items if needed
* Connecting Meta and pushing products for product messages
* Understanding sync status per product
## Before you begin
Your WhatsApp Business Account must be connected before setting up a Meta Catalog push. A catalog connection is only required if you plan to use product message formats — standard campaigns and automations do not require it.
## Syncing your Shopify catalog
In the Galantis dashboard, go to **Catalog → Shopify Sync**.
Click **Sync Now** to import all your Shopify products and collections into Galantis. This is a one-time full import — after this, Galantis keeps product data current automatically via Shopify webhooks.
Once the sync completes, browse the product list. Check that titles, prices, variants, and images have imported correctly.
If specific products should not be synced to Meta, flag them with the `exclude_from_syncforce` option on the individual product record. This does not remove them from Galantis — it only prevents them from being pushed to Meta.
## Pushing products to Meta (optional)
This step is only required if you plan to use SPM, MPM, or Whole Catalog message formats.
Go to **Catalog → Meta Sync**. You have two options:
* **Import an existing Meta Catalog** — connect a catalog you have already configured in Meta Commerce Manager.
* **Create a new Meta Catalog from Galantis** — build and push directly from your Shopify data, without setting anything up in Meta Commerce Manager.
Once connected, trigger a Meta push. Products that are successfully pushed will show a `SYNCED` status.
Review the status column per product. Address any `FAILED` items by checking the error details and resolving the issue (for example, images that do not meet Meta's size requirements).
## Sync status reference
| Status | Description |
| --------- | --------------------------------------------- |
| `PENDING` | Queued for Meta upload |
| `SYNCED` | Successfully pushed to Meta |
| `FAILED` | Sync error — review error details per product |
## How ongoing sync works
After your first manual sync, Galantis keeps product data current automatically. Shopify triggers a webhook whenever a product is created, updated, or deleted — Galantis processes these in near real time. You only need to run a manual sync again after bulk edits or if you need to recover from a sync error.
Product images must be JPEG or PNG format and at least 500×500px to pass Meta's validation. Images that do not meet this requirement will cause the product to show a `FAILED` status on the Meta push.
## Related guides
* [Catalog](/whatsapp/catalog/index) — Full reference for sync configuration, product fields, and catalog health
* [WhatsApp Connection](./whatsapp-connection) — Required for Meta Catalog integration
* [First Campaign](./first-campaign) — Use catalog products in campaign messages
# Getting Started
Source: https://docs.digifist.com/galantis/whatsapp/getting-started/index
Go from a fresh Shopify store to a fully operational Galantis WhatsApp setup — typically 5 minutes from install to a connected dashboard if you already have a WhatsApp Business Account.
Galantis WhatsApp turns your Shopify store into a measurable WhatsApp revenue channel — campaigns, automations, a shared inbox, and product messaging, all powered by Meta's WhatsApp Business Platform (Cloud API). This Getting Started section walks you through every step from "I just heard about Galantis" to "I sent my first campaign."
If you already have a WhatsApp Business Account, **the connection itself takes about 5 minutes** after install — Meta's Embedded Signup modal handles every step inside the Galantis app.
There are two ways to connect: the **full WhatsApp Platform** (campaigns and automations) or a **simple chat button**. If you are not sure which you need, read [Choose Your Connection](/galantis/whatsapp/getting-started/choose-your-connection) first.
**Marketing requires opt-in.** Before you can send WhatsApp marketing messages to customers, they must have explicitly opted in. Galantis enforces this on every send. Plan how you'll capture consent (checkout checkbox, account preferences, Back-in-Stock subscribe) before you go live. See [Opt-in & consent](/galantis/whatsapp/compliance/opt-in-consent).
## The three phases
Prep your accounts, install Galantis on Shopify, and connect WhatsApp through Meta's Embedded Signup modal.
Create a template, run your first campaign, build your first automation, and (optionally) sync your catalog and Back-in-Stock widget.
Watch the analytics, tune templates, scale up with more automations and additional numbers as the channel grows.
## Phase 1 — Set up
The four accounts you need: Shopify, Meta Business, a phone number, and a Meta payment method.
Three paths — new dedicated (recommended), existing number, or migrate from the WhatsApp Business app.
One click from the [Galantis App Store listing](https://apps.shopify.com/galantis-whatsapp). Grant permissions, land in the in-app wizard.
Meta's Embedded Signup modal walks you through WABA setup, phone registration, and display-name approval — all inline in Galantis.
## Phase 2 — Send your first message
Build a template, get it approved by Meta, send your first WhatsApp broadcast to an opted-in audience.
Set up an event-triggered flow — for example, a New Customer Welcome that fires when a Shopify order is placed.
Sync Shopify products to Galantis and push them to Meta. Required if you plan to send product messages.
Install the storefront widget and test a restock notification end to end.
## Phase 3 — Iterate
Plans, Conversation credits, add-ons, and how Galantis vs Meta charges work.
Phone number quality rating, template approval signals, and how to keep your number in green status.
## Have questions before you start?
Reach the Galantis support team for setup questions, migration help, or anything the docs don't cover.
APIs, webhooks, and the technical details for teams integrating Galantis with their own systems.
# Requirements
Source: https://docs.digifist.com/galantis/whatsapp/getting-started/requirements
Accounts and platforms you need before installing Galantis WhatsApp on your Shopify store.
Before you install Galantis, make sure you have the four accounts below in place. The setup itself is fast — connecting WhatsApp to your Shopify store typically takes around 5 minutes after install — but each platform has its own one-time signup and verification you should clear first.
You do **not** need a pre-existing WhatsApp Business Account (WABA) before installing Galantis. The connection modal can create one for you. See [Connect WhatsApp](/galantis/whatsapp/getting-started/whatsapp-connection).
## What you need
Any plan that allows installing third-party apps from the Shopify App Store. Both new stores and established stores work.
A Meta Business account that you (or someone on your team) administrates. If you don't have one, the Embedded Signup modal will help you create one.
A number for your WhatsApp Business identity. Dedicated new numbers are strongly recommended — see [Choose a phone number](/galantis/whatsapp/getting-started/choose-phone-number).
Meta bills WhatsApp messaging directly. Add a valid payment method in Meta Business Manager before going live with real campaigns.
## Detailed checklist
### 1. Shopify store
Galantis installs as a standard Shopify app. There's no minimum plan, but you'll need at least Shopify's basic permissions to install apps and grant the data scopes Galantis requests (orders, customers, products). See [Shopify installation](/galantis/whatsapp/getting-started/shopify-installation) for the exact permissions and what each one enables.
### 2. Meta Business account
A Meta Business account (sometimes called a Business Portfolio) is the umbrella that holds your WhatsApp Business Account, ad accounts, catalogs, and Pages. If you already run Facebook or Instagram ads for the store, you almost certainly have one. If not, the [Embedded Signup](/galantis/whatsapp/getting-started/whatsapp-connection) flow inside Galantis lets you create one without leaving the app.
### 3. Phone number for WhatsApp
This is the identity customers will see and message. The default and recommended choice is a fresh dedicated number — but you can also use an existing number, or migrate one from the WhatsApp Business app, all from inside the Embedded Signup modal. [Choose a phone number](/galantis/whatsapp/getting-started/choose-phone-number) walks through the three options.
### 4. Payment method in Meta
Galantis charges through Shopify Billing for plans, Conversation tiers, and add-ons. **Meta charges separately** for the underlying WhatsApp messaging — billed in Meta Business Manager. Without a Meta payment method, you can still install Galantis and explore the dashboard, but you cannot send real WhatsApp messages.
* Add or update payment methods in **Meta Business Manager → Billing**
* This is independent of any Facebook/Instagram ads payment method, although you can reuse the same card
* See [Meta rate card](/galantis/whatsapp/billing/meta-rate-card) for what Meta charges per message
**Opt-in required for marketing messages.** Before you can send WhatsApp marketing to a customer, they must have explicitly opted in to receive WhatsApp messages from your store. See [Opt-in & consent](/galantis/whatsapp/compliance/opt-in-consent) for the consent capture methods Galantis supports. Marketing without consent is a Meta policy violation and risks template rejection or account restriction.
## Policies to read once
WhatsApp has two policies every store on the platform must follow:
The rules for what you can message customers, how often, and with what kind of content.
Restrictions on what products and services can be sold or promoted on WhatsApp.
Galantis enforces template approval and opt-in capture at the product level, but the policies apply to **your business** — review them before launching.
## Summary checklist
* Shopify store with permissions to install apps
* Meta Business account (or willingness to create one in the modal)
* Phone number for WhatsApp — [pick one](/galantis/whatsapp/getting-started/choose-phone-number)
* Payment method on file in Meta Business Manager
* Plan to capture opt-in before sending marketing messages
***
Three legitimate paths — dedicated, existing, or migrate from the WhatsApp Business app.
The actual install flow from the Shopify App Store.
# Install on Shopify
Source: https://docs.digifist.com/galantis/whatsapp/getting-started/shopify-installation
Install Galantis WhatsApp from the Shopify App Store, grant the required permissions, and launch into the in-app onboarding wizard.
Galantis WhatsApp is a public Shopify app. Installation is the standard Shopify flow — review permissions, click install, and you land back in your Shopify admin with the Galantis app launched. The whole step usually takes under 2 minutes.
There are two ways to connect: the **full WhatsApp Platform** (campaigns and automations) or a **simple chat button**. If you are not sure which you need, read [Choose Your Connection](/galantis/whatsapp/getting-started/choose-your-connection) first.
Open the official Shopify App Store listing and click **Install**. You'll be prompted to sign in to Shopify if you aren't already.
## What happens during install
Use the install card above or visit [apps.shopify.com/galantis-whatsapp](https://apps.shopify.com/galantis-whatsapp) directly. Sign in to the Shopify account that owns the store you want to install on.
Shopify displays the data scopes Galantis requests — customers, orders, products, checkouts, script tags. Each one powers a specific Galantis feature. See [Required permissions](#required-permissions) below for what each scope unlocks.
Shopify provisions the install, grants the permissions, and redirects you to the Galantis app inside your Shopify admin.
Once you land in Galantis, the onboarding wizard appears on the dashboard. Its first step launches **Meta's Embedded Signup modal** to connect WhatsApp — see [Connect WhatsApp](/galantis/whatsapp/getting-started/whatsapp-connection) for the modal walkthrough. From install to a connected dashboard typically takes about 5 minutes for merchants who already have a WhatsApp Business Account.
## Required permissions
Galantis requests these Shopify permissions during installation. Each one is tied to a specific feature — denying any disables the feature that depends on it.
**Read and write customers** — Syncs customer contact profiles and marketing consent state into Galantis. Consent status (`marketing_state`) is pulled from Shopify and kept in sync via webhook so opt-ins captured at checkout or in your customer account appear immediately in Galantis audiences.
**Read and write orders** — Required for order-based automation triggers (New Order Placed, Order Cancelled, Order Shipped), revenue analytics, and customer segment rules based on purchase history.
**Read products and collections** — Required for the Catalog module. Product and collection data is synced into Galantis and optionally pushed to Meta for product message templates and catalog campaigns.
**Read checkouts** — Required for the Abandoned Checkout automation trigger. Galantis polls for incomplete checkouts every 10 minutes and matches them to opt-in customers.
**Read and write script tags** — Required to inject the storefront chat widget (Inbox) and the Back-in-Stock subscription widget into your Shopify theme. No manual theme code editing is needed.
All permissions are required for the platform to function end to end. You can install Galantis with a subset and still explore the dashboard, but features tied to denied scopes will be inactive until you re-authorize. See the [Shopify permissions reference](/galantis/whatsapp/integrations/shopify/permissions) for the full breakdown.
## What the in-app onboarding wizard does
After install, the wizard guides you through:
1. **Connect WhatsApp** — launches Meta's [Embedded Signup modal](/galantis/whatsapp/getting-started/whatsapp-connection) to attach (or migrate, or create) your WABA and phone number
2. **Sync your Shopify catalog** — optional during onboarding, can be skipped and configured later — see [First catalog sync](/galantis/whatsapp/getting-started/first-catalog-sync)
3. **Invite team members** — optional; roles and seats can be configured later under **Settings → Team**
Skip steps you're not ready for. The wizard remembers progress and you can resume from the dashboard.
## Uninstalling Galantis
If you ever need to uninstall: in your Shopify admin, go to **Settings → Apps and sales channels**, find Galantis WhatsApp, and click **Uninstall**. Shopify revokes all granted permissions automatically. Your Galantis workspace data is retained according to standard retention policy in case you reinstall later.
***
The Embedded Signup walkthrough — the natural next step after installing.
Deep reference for every scope, what it enables, and what breaks if it's missing.
# Connect WhatsApp
Source: https://docs.digifist.com/galantis/whatsapp/getting-started/whatsapp-connection
Walk through Meta's official Embedded Signup modal inside Galantis to create or attach your WhatsApp Business Account and register a phone number — usually 5 minutes from install to dashboard.
After installing Galantis on Shopify, the next step is connecting WhatsApp. Galantis launches **Meta's official Embedded Signup** modal inside the app — a Facebook-hosted pop-up that handles every step of attaching a WhatsApp Business Account (WABA): logging into Meta, picking or creating your Meta Business, registering a phone number, choosing a display name, and verifying ownership. You stay inside the Galantis app the whole time.
If you already have a WABA — including a number from the WhatsApp Business mobile app — the same modal lets you connect or migrate it in the same flow. No separate Meta dashboard visit, no manual token handling.
There are two ways to connect: the **full WhatsApp Platform** (campaigns and automations) or a **simple chat button**. If you are not sure which you need, read [Choose Your Connection](/galantis/whatsapp/getting-started/choose-your-connection) first.
## What is Embedded Signup?
Embedded Signup is Meta's recommended onboarding flow for Tech Provider apps like Galantis. Instead of asking you to set things up in Meta Business Manager and copy access tokens, the modal walks you through everything in one place and returns the credentials Galantis needs automatically. From your point of view, it's a single pop-up with 5–7 steps.
You don't need a pre-existing WABA or Meta access token. The modal creates them for you if needed — or attaches your existing ones if you have them.
## Before you start
* Have your Facebook or Meta Business credentials ready (the email and password you use to log into Meta Business Manager)
* Decide which phone number you'll connect — see [Choose a phone number](/galantis/whatsapp/getting-started/choose-phone-number)
* Make sure the number can receive an SMS or voice call for verification
* If you're migrating from the WhatsApp Business mobile app, keep the device with the app available — Meta may ask you to confirm the migration there
## Pick your starting point
You're setting up your first WhatsApp Business Account. The modal will create your WABA, attach a phone number, and verify it — all in one pass.
On the in-app onboarding screen (or under **Settings → WhatsApp Connection** afterward), click **Connect WhatsApp**. Meta's Embedded Signup modal opens inside the app.
Use the Facebook account that administrates (or will administrate) your Meta Business. If you're not signed in, the modal shows the standard Facebook login screen.
Select an existing Meta Business if you already have one (for example, for Facebook/Instagram ads). Otherwise create one in the modal — give it your store name and confirm your country.
Confirm the name of your WABA. This is internal — customers don't see it; they see your phone number's display name.
Enter the number you decided on in [Choose a phone number](/galantis/whatsapp/getting-started/choose-phone-number). Meta will send a 6-digit code via SMS or voice call — enter it in the modal to confirm ownership.
Pick the name customers will see in WhatsApp alongside your number — typically your store or brand name. Meta reviews display names; approval is usually quick but can take 1–2 business days. See [Meta's guidelines](https://developers.facebook.com/docs/whatsapp/embedded-signup/onboard-clients) for naming rules.
The modal closes and Galantis receives the credentials. You land in the Galantis dashboard, ready to set up your first campaign.
Your Meta Business already has a WABA with one or more registered phone numbers. The modal will let you attach the existing WABA to Galantis without re-creating anything.
The Embedded Signup modal opens.
Use the account that has admin access to your existing WABA. Select your Meta Business when prompted.
The modal lists the WABAs you have permission to manage. Pick the one you want to use with Galantis.
Pick a number that's already registered to your WABA, or add a new one in the same flow. New numbers go through SMS/voice verification.
Galantis receives the credentials. The connected WABA + number appear on your Galantis dashboard.
You can connect multiple numbers per workspace — useful for separating brands, regions, or marketing vs. transactional sends. See [Multiple phone numbers](/galantis/whatsapp/integrations/meta-whatsapp/multiple-phone-numbers).
Your store's WhatsApp Business mobile app number can move to the Cloud API and into Galantis directly from the Embedded Signup modal — no separate uninstall, no manual cooldown. Meta handles the migration inside the flow.
Meta may prompt you to confirm the migration in the app to make sure the number's owner approves the switch.
The Embedded Signup modal opens.
Use the Meta Business account associated with the number (or that you want to associate with it).
The modal recognizes numbers registered to the WhatsApp Business app and offers to move them to the Cloud API. Confirm in the modal — and in the app if Meta asks.
You can keep your existing display name or pick a new one. Meta reviews any changes.
Galantis receives the migrated number's credentials. The number now sends through the Cloud API; the WhatsApp Business app's role on this number ends. Past chat history stays on the device's local backup; new conversations land in the Galantis Inbox.
After migration, the number is on Cloud API only — the WhatsApp Business app can no longer use it. Plan with your team if anyone was using the app to reply to customers manually.
## How to know it worked
Once the modal closes successfully, three things confirm the connection:
The Galantis dashboard shows your connected WABA name, phone number, and display name under **Settings → WhatsApp Connection**.
The number shows a "Verified" or "Pending verification" badge. Marketing-category messages require display-name approval (1–2 days); utility-category messages are sendable immediately.
From **Templates**, send a test utility template to your own phone. A delivered message is the cleanest proof the connection works end-to-end.
## Adding more numbers later
You can attach additional phone numbers to the same WABA after the initial connection — useful as your store scales to multiple brands, regions, or message types. Open **Settings → WhatsApp Connection → Add number** to re-launch the Embedded Signup modal for the additional number.
See [Multiple phone numbers](/galantis/whatsapp/integrations/meta-whatsapp/multiple-phone-numbers) for when and why to use more than one.
## Troubleshooting
Check your browser's pop-up blocker — the Embedded Signup modal is a Facebook-hosted pop-up. Allow pop-ups for the Galantis app domain and try again. If you're using strict privacy extensions, temporarily disable them for this session.
Make sure the number is correct including country code, and that it can receive international SMS or calls. Retry in the modal — Meta sends a new code each time. If the number is a VoIP or toll-free number, it may not be supported; check Meta's [phone number requirements](https://developers.facebook.com/docs/whatsapp/cloud-api/get-started).
Meta rejects names that contain URLs, email addresses, promotional language ("Best", "Cheap", "Sale"), all-caps shouting, or that don't match your brand. Resubmit with a clear brand-aligned name. See Meta's [display name guidelines](https://developers.facebook.com/docs/whatsapp/embedded-signup/onboard-clients).
The modal will explain the specific reason — usually an owner mismatch (the Meta Business doing the migration is different from the one that originally registered the number) or a Meta-side hold. Contact Galantis support with the modal's error message and we'll guide the next step.
See the [Technical reference: connecting WABA](/galantis/whatsapp/integrations/meta-whatsapp/connecting-waba) for token expiry handling, reconnection, and how the Cloud API access token is stored and refreshed.
## Connect your product catalog
To send product carousels and show product details in automations, connect a **Meta product catalog** in Galantis. This is separate from syncing your Shopify store; WhatsApp product messages need a Meta catalog.
In Galantis, go to **Settings → Connections** and find the **Product catalog** section.
Click **Connect Meta catalog**. Then either select an existing catalog from your Meta Business account, or create a new one by entering a catalog name. Both directions work: Galantis can use a catalog you already have in Meta, or submit a new catalog to Meta for you.
Pick which catalog powers product messages: single product message (SPM), multi-product message (MPM), or the whole catalog.
The catalog is required for dynamic product carousels and product information in automations.
If your catalog does not appear, your Meta permissions may have expired, or you created the catalog after your last Meta login. Reconnect Meta to load the latest catalogs.
***
With a connected number, create a template and send your first WhatsApp broadcast.
OAuth scopes, token storage, reconnection, and what Galantis does behind the scenes.
# Assignment & Routing
Source: https://docs.digifist.com/galantis/whatsapp/inbox/assignment-routing
How conversations are assigned to agents in the Galantis Inbox — manual assignment, auto-assignment, and the My Tickets view.
The Galantis Inbox supports manual and automatic conversation assignment. Assigning conversations to specific agents keeps accountability clear, prevents multiple agents from working the same thread simultaneously, and makes it easy for each team member to focus on their own queue through the My Tickets view.
## What this covers
* Manual assignment by admins or agents
* Auto-assignment on first reply
* The My Tickets view
* Current routing limitations
## Manual assignment
Any conversation can be manually assigned to a specific team member by an agent or admin using the assignment control in the conversation view. The assigned agent is updated immediately.
Use manual assignment when:
* A conversation requires a specific agent's expertise (e.g., a product specialist or senior support agent)
* An admin is triaging incoming conversations and distributing them across the team
* A conversation needs to be reassigned from one agent to another
## Auto-assignment
When an agent sends the first reply in a conversation that has no assigned agent, they are automatically assigned to that conversation. This ensures conversations do not remain unowned after an agent begins working on them, without requiring an explicit assignment step.
Auto-assignment applies only to the **first reply** in an unassigned conversation. If a conversation already has an assigned agent, sending a reply does not change the assignment.
## My Tickets view
Agents can filter the Inbox to display only conversations assigned to them using the **My Tickets** view. This is the primary working view for most support agents — it removes unassigned or other-agent conversations from the queue and keeps focus on the agent's own workload.
Admins and roles with broader access can switch between **My Tickets** and an all-conversations view to monitor overall inbox volume or pick up unassigned threads.
## Routing limitations
Round-robin routing — automatically distributing new conversations evenly across available agents — is not currently supported natively in Galantis. Conversation distribution is managed through manual assignment or auto-assignment on first reply.
For teams with high inbound volume, the recommended workflow is:
1. A designated team lead or admin monitors unassigned conversations
2. The lead manually assigns conversations to available agents based on capacity
3. Agents work their assigned queue through the My Tickets view
## Related guides
* [Roles & Permissions](./roles-permissions) — Which roles can assign and reassign conversations
* [Conversation Lifecycle](./conversation-lifecycle) — How conversation statuses interact with assignment
* [Inbox Analytics](./inbox-analytics) — Tracking assignment and response performance per agent
# Conversation Lifecycle
Source: https://docs.digifist.com/galantis/whatsapp/inbox/conversation-lifecycle
How conversations move through OPEN, PENDING, and RESOLVED statuses in the Galantis Inbox.
Every conversation in the Galantis Inbox has a status that reflects its current state in the support workflow. Statuses help agents prioritize work, track which conversations need attention, and close out resolved threads. Understanding how statuses work — and how they transition — is essential for running an organized and responsive inbox.
## What this covers
* The three conversation statuses and what each means
* How agents transition conversations between statuses
* How conversations reopen automatically
* The relationship between conversation status and the WhatsApp 24-hour window
## Conversation statuses
| Status | Meaning |
| ---------- | ---------------------------------------------------------------------- |
| `OPEN` | Active conversation — requires agent attention or action |
| `PENDING` | Waiting on a customer reply or an internal action before the next step |
| `RESOLVED` | Conversation is closed — no further action needed |
### OPEN
A conversation is `OPEN` when it requires attention. All new inbound messages arrive as `OPEN`. This is the default working state — agents pick up `OPEN` conversations to reply, investigate, or escalate.
### PENDING
`PENDING` indicates the conversation is in a waiting state. Use this status when you have replied and are waiting for the customer to respond, or when a task needs to be completed internally before the conversation can move forward.
`PENDING` is a holding state, not a closed one. Conversations in `PENDING` remain visible and can be actioned at any time.
### RESOLVED
`RESOLVED` closes the conversation. Use this when the customer's issue or question has been fully handled and no further action is expected. Resolved conversations are removed from the active queue but remain accessible in conversation history.
Resolving a conversation does not affect the WhatsApp 24-hour window. If the window is still active when a conversation is resolved, it will remain active until 24 hours after the customer's last inbound message.
## Transitioning between statuses
Agents transition conversations manually using the status controls in the conversation view. Any agent with access to the Inbox can update the status of a conversation assigned to them. Admins can update the status of any conversation.
Typical workflow:
1. New inbound message arrives → conversation is `OPEN`
2. Agent replies and is waiting for customer response → agent moves to `PENDING`
3. Customer replies → conversation moves back to `OPEN` automatically
4. Issue resolved → agent moves to `RESOLVED`
## Automatic reopening
When a customer sends a new inbound message to a conversation that is `RESOLVED`, the conversation reopens automatically to `OPEN`. This ensures no customer message is missed because a thread was previously closed.
The reopened conversation retains the full message history from previous sessions, giving agents the context they need without starting a new thread.
## Relationship with the WhatsApp conversation window
The conversation lifecycle status in Galantis and the WhatsApp 24-hour window are separate concepts that run in parallel:
* **Galantis status** reflects the internal workflow state managed by your team.
* **WhatsApp window** reflects Meta's policy on what type of message can be sent.
A conversation can be `RESOLVED` in Galantis while the WhatsApp window is still open. Equally, a conversation can be `OPEN` in Galantis while the WhatsApp window has closed — meaning an agent cannot send a free-form message until the customer writes again or an approved template is used.
See [Conversation Window](/whatsapp/compliance/conversation-window) for how the 24-hour window affects what agents can send at any given point.
## Related guides
* [Assignment & Routing](./assignment-routing) — How conversations are assigned to agents
* [Conversation Window](/whatsapp/compliance/conversation-window) — The WhatsApp 24-hour window rule
* [Templates vs Session Messages](/whatsapp/compliance/templates-vs-session) — What agents can send depending on window state
# Inbox Analytics
Source: https://docs.digifist.com/galantis/whatsapp/inbox/inbox-analytics
Track response time, conversation volume, and agent performance across your Galantis Inbox.
Inbox analytics give you visibility into how effectively your team is handling customer conversations. The metrics track both the speed and volume of your support operation — helping you identify bottlenecks, measure individual agent performance, and understand conversation patterns over time.
## What this covers
* Available Inbox metrics and what each measures
* How to interpret response time and resolution data
* Agent-level performance breakdown
## Available metrics
**First response time**: The average time between a conversation arriving as `OPEN` and the first agent reply being sent.
This is the primary speed metric for the Inbox. A low first response time indicates that conversations are being picked up quickly. A high first response time may indicate understaffing, routing inefficiency, or agents being overloaded with concurrent conversations.
Monitor this metric alongside conversation volume — a rising response time during a high-volume period is expected, but a consistently high response time during normal volume suggests a structural issue.
**Inbound conversation volume**: The total number of new conversations opened during a selected time period.
Volume data helps with staffing decisions and capacity planning. Tracking volume over time reveals patterns — peak days, seasonal spikes, or the impact of a campaign sending on inbound message rates.
Campaign sends frequently generate inbound replies. If you run a large broadcast, expect a corresponding spike in Inbox volume for the following 24–48 hours and staff accordingly.
**Messages sent per agent**: The total number of messages sent by each agent during a selected period.
**Conversations resolved per agent**: The number of conversations each agent moved to `RESOLVED` status during a selected period.
These metrics provide a per-agent breakdown of workload and output. Use them to identify high-performing agents, spot agents who may be struggling, and distribute workload more evenly through assignment routing.
Messages sent and conversations resolved measure different things. An agent can send many messages while resolving few conversations — this may indicate complex or escalated cases, not low performance. Always interpret agent metrics in context.
**Average resolution time**: The average time from a conversation opening (`OPEN`) to being marked `RESOLVED`.
Resolution time reflects the full lifecycle of a conversation, from first contact to close. It is a more complete picture of support efficiency than response time alone — a fast first response followed by a long unresolved thread still represents a poor customer experience.
A high average resolution time may point to: conversations being left in `PENDING` without follow-up, complex issues requiring multiple back-and-forth messages, or agents not closing resolved conversations promptly.
## Best practices
* **Track first response time as your primary health metric.** It is the metric most directly in your team's control and most directly experienced by the customer.
* **Compare volume to resolution time.** If volume increases and resolution time holds steady, your team is scaling well. If resolution time rises with volume, capacity may need adjustment.
* **Review agent performance in aggregate, not in isolation.** Individual message counts vary based on conversation complexity. Look for meaningful outliers rather than minor differences.
* **Account for campaign sends when reviewing volume data.** Spikes in inbound conversations shortly after a broadcast are expected — do not interpret them as anomalies.
## Related guides
* [Assignment & Routing](./assignment-routing) — How conversation distribution affects agent metrics
* [Conversation Lifecycle](./conversation-lifecycle) — How status transitions relate to resolution time measurement
* [Inbox Add-on Billing](/whatsapp/billing/add-ons/inbox) — How billable conversations are tracked alongside analytics
# Inbox
Source: https://docs.digifist.com/galantis/whatsapp/inbox/index
Centralized WhatsApp conversation management for your Shopify store — with agent assignment, customer context, and full conversation lifecycle control.
The Inbox is the operational hub for all customer WhatsApp conversations in Galantis. Every inbound message from a customer — whether they reached out through the storefront chat widget, replied to a campaign, or responded to an automation — arrives here in a single unified view.
Unlike a standard support inbox, the Galantis Inbox surfaces full Shopify customer context alongside every conversation: order history, lifetime value, consent status, and browsing data are visible to agents without leaving the thread. This makes the Inbox useful for both support and pre- or post-purchase sales conversations.
## What this section covers
* Installing and configuring the storefront chat widget
* Customizing widget appearance and branding
* Managing conversation statuses and lifecycle
* Agent assignment and routing behavior
* Roles, permissions, and team access controls
* Inbox analytics and performance metrics
## How the Inbox works
The Inbox operates on WhatsApp's 24-hour conversation window model. When a customer sends a message, a window opens and agents can reply freely with session messages. Once the window closes, agents must use an approved template to re-engage. See [Conversation Window](/whatsapp/compliance/conversation-window) for the full rule set.
Conversations are assigned to agents manually or automatically on first reply. Agents see only conversations relevant to them through the **My Tickets** view, while admins have visibility across all conversations.
## Guides in this section
Install the chat widget on your Shopify storefront via script tag injection.
Customize button style, position, colors, and greeting message.
Understand OPEN, PENDING, and RESOLVED statuses and how transitions work.
Manual and automatic conversation assignment for your support team.
Role-based access control for every team member in your workspace.
Response time, conversation volume, and agent performance metrics.
## Billing
The Inbox is billed per agent seat: **\$19 per seat per month**, including 500 Inbox Threads per seat. **Scale and Enterprise plans include 1 seat** in the plan price; Free, Starter, and Growth plans get 50 threads per month for evaluation but need to add an Additional Agent (\$19) to actively run inbox support. Threads beyond the included amount are billed as tiered overage (\$5 / \$4 / \$3 per 500-thread block depending on monthly volume). See [Inbox Add-on Billing](/galantis/whatsapp/billing/add-ons/inbox) for the full pricing breakdown.
# Roles & Permissions
Source: https://docs.digifist.com/galantis/whatsapp/inbox/roles-permissions
Role-based access control for every team member in your Galantis workspace.
Galantis uses a role-based permission system to control what each team member can see and do across the platform. Every user in your workspace is assigned a role, and each role maps to a specific set of granular permissions. Roles are assigned when inviting a team member and can be updated at any time by an Owner or Admin.
## What this covers
* All available roles and their access levels
* How roles relate to Inbox access specifically
* Where to manage team member roles
## Roles
**Owner**
Full access to every feature and setting in the workspace, including billing management. Only one Owner role exists per workspace. The Owner is the merchant who installed the app.
***
**Admin**
Full access to all platform features except billing management. Use this role for trusted team leads who need to configure campaigns, automations, templates, and the Inbox without access to subscription or payment settings.
**Marketing Manager**
Access to Campaigns, Automations, Templates, and Audience. This role covers the full marketing workflow — building automations, creating and submitting templates, managing segments and lists, and launching campaigns.
***
**Campaign Operator**
Can create and send campaigns. Does not have access to automation building, template creation, or audience management beyond selecting from existing lists and segments.
***
**Content Creator**
Can create and edit templates only. Use this role for team members responsible for copywriting and template submission who should not have access to campaign sending or automation configuration.
**Analyst**
Read-only access to analytics across the platform. Can view campaign performance, automation activity, and inbox metrics. Cannot create, edit, or send anything.
***
**Data Analyst**
Read-only access to customer data and reports. Can view contact profiles, segment membership, and audience data. Cannot access campaign or automation analytics.
**Support Agent**
Access to the Inbox only. Can view, assign, and reply to conversations. Has no access to campaigns, automations, templates, audience, or analytics.
This is the correct role for dedicated support team members whose work is limited to handling customer conversations. Each Support Agent seat is billed at **\$19 per seat per month** (Scale and Enterprise plans include 1 seat in the plan price) — see [Inbox Add-on Billing](/galantis/whatsapp/billing/add-ons/inbox).
***
**Viewer**
Read-only access across the entire platform. Cannot take any action. Use this role for stakeholders who need visibility into the workspace without the ability to modify anything.
## Role summary
| Role | Campaigns | Automations | Templates | Audience | Inbox | Analytics | Billing |
| --------------------- | --------- | ----------- | ----------- | --------- | --------- | --------- | ------- |
| **Owner** | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| **Admin** | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — |
| **Marketing Manager** | ✓ | ✓ | ✓ | ✓ | — | ✓ | — |
| **Campaign Operator** | Send only | — | — | View only | — | — | — |
| **Content Creator** | — | — | Create/edit | — | — | — | — |
| **Analyst** | Read only | Read only | Read only | Read only | Read only | Read only | — |
| **Data Analyst** | — | — | — | Read only | — | Read only | — |
| **Support Agent** | — | — | — | — | ✓ | — | — |
| **Viewer** | Read only | Read only | Read only | Read only | Read only | Read only | — |
Galantis uses over 90 granular permissions to control access across the platform. The table above represents the functional access level per role. If you need a custom permission configuration that does not map to an existing role, contact Galantis support.
## Managing team members
Team members are invited and assigned roles under **Settings → Team**. Roles can be changed at any time by an Owner or Admin. Changing a role takes effect immediately — there is no pending or confirmation step.
## Best practices
* **Assign the most restrictive role that covers the team member's responsibilities.** A marketing manager who only sends campaigns does not need the Marketing Manager role — Campaign Operator is sufficient.
* **Reserve Owner access carefully.** The Owner role cannot be duplicated. If the Owner account becomes inaccessible, escalate to Galantis support for workspace recovery options.
* **Use Support Agent for all inbox-only team members.** This role is purpose-built for support workflows and prevents accidental access to campaign or automation configuration.
* **Review team roles periodically.** When team members change responsibilities or leave, update or remove their access promptly.
## Related guides
* [Assignment & Routing](./assignment-routing) — How agent assignment works in practice
* [Inbox Add-on Billing](/whatsapp/billing/add-ons/inbox) — Per-seat billing for Support Agent roles
# Storefront Widget
Source: https://docs.digifist.com/galantis/whatsapp/inbox/storefront-widget
Install the Galantis chat widget on your Shopify storefront to capture inbound WhatsApp conversations.
The storefront widget adds a WhatsApp chat button to your Shopify store. When a customer taps it, they are connected to your WhatsApp Business number and a conversation is created in the Galantis Inbox. Galantis injects the widget via a Shopify script tag — no manual theme editing is required.
## What this covers
* Installation steps and how script injection works
* Placement options
* How to verify the widget is live on your storefront
* Troubleshooting widget display issues
## How installation works
Galantis uses Shopify's script tag system to inject the chat widget into your storefront automatically. When you configure the widget in the dashboard, Galantis writes a script tag to your store using the `write_script_tags` Shopify permission. The widget loads on every page that matches your display rules without any changes to your theme code.
The `write_script_tags` Shopify permission must be granted for widget injection to work. This permission is requested during the initial app installation. If the widget is not appearing, verify this permission is active under your Shopify app settings.
## Installation steps
In the Galantis dashboard, go to **Inbox → Widget Settings**.
Set the button position, label text, colors, and greeting message. See [Widget Appearance](./widget-appearance) for the full settings reference.
Saving the configuration triggers Galantis to write or update the script tag in your Shopify store. No further action is required to deploy the widget.
Visit your store in a browser. The chat button should appear in the configured position. Test by tapping the button — it should open WhatsApp pre-populated with your business number.
## Placement options
The widget button can be positioned in three ways:
**Bottom-right** — Default position. Works well for most store layouts and does not conflict with common Shopify theme elements.
**Bottom-left** — Use when your theme places other fixed elements (such as cookie banners or cart drawers) at the bottom-right.
**Custom** — Set a precise position using CSS offset values. Useful when neither default position works with your theme's layout.
## Display rules
You can control which pages the widget appears on. Common configurations include:
* Show on all pages
* Show only on product pages
* Hide on the checkout page
Display rules are configured under **Inbox → Widget Settings**.
## Verifying the widget
After saving your settings, confirm the widget is working correctly:
1. Open your storefront in a browser (not the Shopify theme preview).
2. The chat button should appear in the position you configured.
3. Tap the button — it should launch WhatsApp with your business number pre-filled.
4. Send a test message — it should appear as a new conversation in **Inbox**.
## Troubleshooting
If the widget does not appear on your storefront:
* Confirm Galantis has `write_script_tags` permission in **Shopify Admin → Apps → \[Galantis] → Permissions**.
* Clear your browser cache and reload the storefront page.
* Check your browser console for JavaScript errors that may indicate a script loading conflict.
* Confirm the page you are viewing matches your configured display rules.
The Shopify theme preview editor may not execute third-party script tags. Always verify the widget on your live storefront URL, not inside the Shopify Customizer preview.
## Related guides
* [Widget Appearance](./widget-appearance) — Branding and visual configuration options
* [Conversation Lifecycle](./conversation-lifecycle) — What happens after a customer sends a message
* [Requirements](/whatsapp/getting-started/requirements) — Shopify permission prerequisites
# Widget Appearance
Source: https://docs.digifist.com/galantis/whatsapp/inbox/widget-appearance
Customize the storefront chat widget button, modal, and greeting message to match your brand.
The chat widget's appearance is fully configurable from the Galantis dashboard. Every visual element — button position, color, font, label text, and the greeting shown to customers — is controlled through **Inbox → Widget Settings** and applied automatically to your storefront when saved.
## What these settings control
* Button position and type
* Button colors, font, and CTA text
* Greeting message shown before the customer sends their first message
* Display rules for which pages show the widget
## How to access
Go to **Inbox → Widget Settings**.
Configure the appearance options described below.
Changes are applied to your storefront immediately after saving.
## Settings
**Button position**: Controls where the chat button appears on the page.
* **Right** — Bottom-right corner. Default and recommended for most themes.
* **Left** — Bottom-left corner. Use when right-side elements conflict with the button.
* **Custom** — Precise placement via CSS offset. Use when neither default position fits your layout.
***
**Button type**: Determines the visual style of the button.
* **Pre-designed** — Uses Galantis's built-in button styles. Quickest to set up and optimized for visibility.
* **Custom** — Fully custom button design. Recommended for stores with strict brand guidelines.
***
**Button background color**: Sets the fill color of the chat button. Enter a hex value to match your brand color.
***
**Button font**: Sets the typeface used for the button label. Enter a custom font family name. Ensure the font is loaded by your Shopify theme — the widget inherits fonts available on the page.
***
**Button text**: The CTA label displayed on or beside the button. Keep this short and action-oriented. Common values: `Chat with us`, `Need help?`, `Talk to us`.
Short, direct labels perform better than long phrases. The button is a small element — labels beyond 20 characters are likely to be truncated on mobile.
**Greeting message**: The opening message shown to the customer inside the chat widget before they send their first message. This is not a WhatsApp message — it is displayed within the widget UI as a prompt to encourage the customer to start a conversation.
Use the greeting to set expectations: let the customer know who they are messaging and roughly when to expect a reply.
Example values:
* `Hi! 👋 Chat with us on WhatsApp — we usually reply within a few minutes.`
* `Have a question? We're here to help.`
The greeting message is not sent as a WhatsApp message and does not consume a conversation credit. It is purely a UI element within the widget.
**Display rules**: Controls which pages on your storefront show the chat widget. By default, the widget appears on all pages.
Configure display rules to show or hide the widget on specific pages — for example, hiding it on the checkout page to avoid distraction during purchase, or showing it only on product pages where pre-purchase questions are most likely.
## Best practices
* **Match your brand color exactly.** The chat button is a persistent element on every page. A color that clashes with your theme will feel inconsistent and may reduce click rates.
* **Test on mobile.** Button position and label length behave differently on small screens. Verify your configuration on a real mobile device, not just a desktop browser resize.
* **Keep greeting messages concise.** One or two sentences is sufficient. The goal is to invite the customer to write — not to front-load information before they have asked a question.
* **Use custom position with care.** CSS offset values interact with your theme's layout and may conflict with other fixed elements. Test after any theme update that changes footer or fixed-bar positioning.
* **Align button font with your theme.** If your theme uses a custom font, enter the same font family name in the button font setting to ensure typographic consistency.
## Related guides
* [Storefront Widget](./storefront-widget) — Installation and verification steps
* [Conversation Lifecycle](./conversation-lifecycle) — What happens after a customer sends their first message
# Introduction
Source: https://docs.digifist.com/galantis/whatsapp/index
Turn WhatsApp into a measurable revenue channel for your Shopify store, with campaigns, automations, a shared inbox, and product messaging.
## What is Galantis WhatsApp?
Galantis WhatsApp is a Shopify-integrated WhatsApp marketing and automation platform. It connects your store to WhatsApp, the highest-engagement messaging channel across LATAM, MENA, India, and beyond, and gives you the tools to turn that channel into a measurable revenue driver.
Where most tools treat WhatsApp as a support inbox, Galantis treats it as a full-stack revenue channel. Campaigns reach segmented audiences with approved message templates. Automations respond to real Shopify events in real time: abandoned checkouts, new orders, new customers, and restocked products. The Inbox gives your support team a unified conversation view with full Shopify customer context. The Catalog module keeps your product data in sync with Meta so customers can browse and buy without leaving WhatsApp.
## What you can do with Galantis WhatsApp
Send one-time WhatsApp broadcasts to segmented audiences, with lists, dynamic segments, include/exclude rules, and real-time delivery analytics.
Build event-driven flows that fire automatically on Shopify triggers: abandoned checkouts, new orders, new customers, product restocks, and more.
Manage all customer WhatsApp conversations in a shared inbox, with agent assignment, full Shopify customer context, and conversation lifecycle controls.
Capture WhatsApp numbers from customers on out-of-stock products and notify them automatically when inventory is replenished.
Sync your Shopify products to Meta and send interactive product messages: Single Product Messages, Multi-Product Messages, and full catalog browsing inside WhatsApp.
Build and validate automation flows with AI-powered assistance, including trigger suggestions, inline error detection, and optimization recommendations.
## Who it's built for
Galantis WhatsApp is built for Shopify merchants who want to turn WhatsApp into a revenue channel, not just a support inbox.
**Growth-focused DTC brands** running paid ads who need a scalable recovery layer for high-traffic, high-abandonment stores. **Mid-market Shopify stores** with dedicated marketing teams looking for an incremental channel beyond saturated email and SMS performance. **Merchants in WhatsApp-heavy regions** across LATAM, MENA, India, and parts of Europe, where customers expect brand communication on WhatsApp. **Support-heavy stores** selling complex products where pre-purchase questions directly impact conversion.
## How it works
Galantis sits between your Shopify store and the WhatsApp Business Platform via Meta. Customer data, orders, products, and consent state flow in from Shopify via webhooks. Messages flow out through the WhatsApp Cloud API. Every send is gated by WhatsApp's opt-in requirements: only customers who have explicitly subscribed receive marketing messages.
The platform modules are independent but connected. A customer who subscribes through the Back-in-Stock widget is opted in and immediately available for campaigns and automations. An abandoned checkout automation uses the same customer and order data that the Inbox surfaces for agents. Segment rules that drive campaign targeting also drive automation triggers.
## Ready to get started?
Install the app, connect your WhatsApp Business Account, and send your first message.
# Galantis Connect
Source: https://docs.digifist.com/galantis/whatsapp/integrations/galantis-connect
Extended integration capabilities for connecting Galantis to additional platforms and custom data sources beyond Shopify and Meta.
Galantis Connect provides extended integration capabilities for merchants who need to connect Galantis to platforms and data sources beyond the native Shopify and Meta integrations. Where the core platform is purpose-built for the Shopify + WhatsApp stack, Galantis Connect is the extensibility layer for merchants with more complex infrastructure needs.
## What Galantis Connect covers
Galantis Connect is designed for use cases such as:
* Connecting a third-party CRM or customer data platform to enrich Galantis contact profiles with data that is not available from Shopify alone
* Integrating with a warehouse management system or fulfillment platform to trigger automations based on fulfillment events outside of Shopify's native webhook set
* Connecting a loyalty or rewards platform so that loyalty tier changes can trigger automation flows or feed into segment rules
* Piping data from a headless commerce setup that does not use Shopify's standard storefront and checkout flows
These are use cases where the standard Shopify webhook pipeline does not capture the full data picture, or where events in external systems need to trigger Galantis behavior.
## Availability
Galantis Connect is not a self-serve feature — it is configured per merchant in collaboration with the Galantis team. The specific integrations available, the data mapping options, and the implementation approach depend on the merchant's infrastructure and the platforms involved.
**To explore Galantis Connect:** Contact Galantis support via the in-app support chat or email. Provide a description of the platform you want to connect, the data you need to bring into or send out of Galantis, and the use case you are trying to enable. The Galantis team will confirm availability and guide the setup process.
## Related guides
* [Shopify Integration](./shopify/index) — The primary data integration for all Shopify-native use cases
* [Meta & WhatsApp Integration](./meta-whatsapp/index) — The message delivery integration
* [Support](/whatsapp/support/index) — Contact information for Galantis Connect enquiries
# Integrations
Source: https://docs.digifist.com/galantis/whatsapp/integrations/index
How Galantis connects to Shopify, Meta, and WhatsApp — the data flows, authentication models, and webhook infrastructure that power the platform.
Galantis is built on two foundational integrations: Shopify and Meta. Every feature in the platform — campaigns, automations, the Inbox, catalog sync, Back-in-Stock — depends on one or both of these connections functioning correctly. Understanding how each integration works, what data flows through it, and how to maintain it is essential for operating Galantis reliably.
A third integration layer, Galantis Connect, provides extended connectivity for merchants who need to bring additional platforms or custom data sources into their workspace.
## Integration architecture
```
Shopify Store
│
├── Webhooks (customers, orders, products, collections, checkouts, consent)
├── GraphQL API (abandoned checkouts, webhooks management, billing)
│
▼
Galantis Platform
│
├── Customer profiles, order history, product catalog, consent state
├── Automation engine, campaign engine, inbox, billing engine
│
├── Queue Layer
│ └── Jobs: message sending, sync, monitoring, billing
│
▼
Meta / WhatsApp Cloud API
├── Message API — send and receive messages
├── Template API — create, submit, sync approval status
├── Media API — upload images, video, documents
└── Catalog API — push product data
```
Data flows in one primary direction for most operations: Shopify → Galantis → Meta. Customer and product data originates in Shopify, is processed and enriched in Galantis, and is pushed to Meta for message delivery and catalog display. Inbound messages from customers flow in the opposite direction: Meta → Galantis → merchant Inbox.
## Integrations in this section
Data sync, required permissions, webhook registration, and the abandoned checkout polling mechanism.
WABA connection, Meta OAuth flow, inbound and outbound webhooks, and multiple phone number support.
Extended integration capabilities for additional platforms and custom data sources.
## Integration health
Both the Shopify and Meta integrations depend on active access tokens that can expire or be revoked. A lapsed Shopify token prevents customer and order data from syncing. A lapsed Meta token prevents message delivery and catalog updates.
When platform behavior appears abnormal — automations not firing, messages not sending, customer data appearing stale — verifying integration token health is the first diagnostic step. Check:
* **Shopify connection** — confirm the app is still installed and active under **Shopify Admin → Apps**
* **Meta/WhatsApp connection** — confirm the token is valid under **Settings → WhatsApp Connection**
See the [Support](/whatsapp/support/index) section for integration-specific troubleshooting guides.
# Connecting WABA — Technical Reference
Source: https://docs.digifist.com/galantis/whatsapp/integrations/meta-whatsapp/connecting-waba
Technical reference for how Galantis connects to a merchant's WhatsApp Business Account: OAuth scopes, token storage and encryption, what the access token enables, and reconnection when a token expires.
This page is the **technical reference** for how Galantis authenticates against Meta's WhatsApp Business Platform — token scopes, storage, what the access token enables, and how reconnection works. It is intended for engineers, security reviewers, and merchants debugging a connection issue.
If you are a merchant connecting WhatsApp for the first time, start at [Connect WhatsApp](/galantis/whatsapp/getting-started/whatsapp-connection) — that page walks you through Meta's Embedded Signup modal step by step. This page documents what happens behind that modal.
The user-facing flow uses **Meta's Embedded Signup**: a Facebook-hosted pop-up rendered inside the Galantis app. Galantis does not implement a separate OAuth redirect — the Embedded Signup SDK returns the necessary credentials directly to Galantis once the merchant completes the modal.
## What the connection produces
A successful Embedded Signup hand-off gives Galantis:
* A **system user access token** scoped to the merchant's WABA, used for messaging APIs
* The **WhatsApp Business Account ID** (WABA ID)
* The **phone number ID** for each registered number
* (Optional) A **Meta Catalog access token** if the merchant connects a catalog in the same flow
All four are stored encrypted per workspace using Galantis's multi-tenant encryption layer. One merchant's credentials cannot be accessed by, or affect, any other workspace.
## What the access token enables
A connected WABA access token authorizes the following Meta API calls scoped to the merchant's WABA:
* Sending messages via the Cloud API (`POST /{phone_id}/messages`)
* Creating, submitting, and managing message templates (`POST /{waba_id}/message_templates`)
* Fetching template approval status
* Uploading media assets for template headers (`POST /{phone_id}/media`)
* Receiving inbound messages and delivery status via Meta webhooks
* Reading phone-number quality rating and limits (`GET /{phone_id}`)
A separately connected **Meta Catalog access token** additionally enables:
* Reading from and writing to the merchant's Meta Catalog (`POST /{catalog_id}/products`)
* Pushing product data from Galantis to Meta in batch
* Syncing catalog updates incrementally when Shopify product data changes
## Token storage
Tokens are encrypted at rest using a per-tenant key derived from the workspace ID and Galantis's master key. Decryption happens only at the moment of an outgoing Meta API call, in-process — tokens are never logged, never echoed in API responses, and never available to other tenants.
Galantis acts on the merchant's behalf using their token. The merchant remains the owner of the WABA in Meta Business Manager and can revoke Galantis's access at any time from **Meta Business Settings → Business Integrations**.
## Token expiry and reconnection
Meta access tokens can be invalidated when:
* Permissions are changed or revoked in Meta Business Manager
* The Meta user account that authorized the connection changes password or 2FA settings
* The Galantis app's authorization is manually revoked in Meta's app permissions
* A long-lived token reaches the end of its validity window
### Symptoms of an invalid token
* Messages fail to send across all campaigns and automations simultaneously
* Template approval status stops updating in Galantis
* Catalog sync fails for all products at once (if the catalog token is affected)
* The Meta webhook connection stops receiving inbound messages and status callbacks
### How to reconnect
Re-running the Embedded Signup flow issues a new token and replaces the old one.
In the Galantis app, go to **Settings → WhatsApp Connection**.
Galantis launches the same Embedded Signup modal. Sign in to Meta with the account that owns the WABA. Confirm the WABA selection — no need to re-add phone numbers or re-set the display name.
From the Inbox or Templates, send a test message to your own phone. A delivered message confirms the new token is active.
If the Meta Catalog token was also invalidated, reconnect it from the same settings screen. Verify by checking the sync status under **Catalog → \[Product]**.
Reconnecting generates a new access token; the previous token is invalidated. If the authorizing Meta account's permissions in Meta Business Manager have been reduced since the original connection, the new token may have less scope — reduce-then-reconnect is the most common cause of "reconnect ran but features are still broken."
## Related
* [Connect WhatsApp (Getting Started)](/galantis/whatsapp/getting-started/whatsapp-connection) — Merchant-facing walkthrough of the Embedded Signup modal
* [Multiple phone numbers](/galantis/whatsapp/integrations/meta-whatsapp/multiple-phone-numbers) — Adding additional numbers after the initial connection
* [Meta Catalog](/galantis/whatsapp/catalog/meta-catalog) — Catalog token connection and management
* [Meta webhooks](/galantis/whatsapp/integrations/meta-whatsapp/meta-webhooks) — Inbound message and status delivery
# Meta & WhatsApp Integration
Source: https://docs.digifist.com/galantis/whatsapp/integrations/meta-whatsapp/index
How Galantis connects to the WhatsApp Business Platform via Meta — authentication, message delivery, template management, and webhook infrastructure.
The Meta and WhatsApp integration is the delivery layer of Galantis. Where the Shopify integration provides the data — customer profiles, orders, products, consent — the Meta integration is what turns that data into actual WhatsApp messages reaching customers' phones.
Galantis communicates with Meta through the WhatsApp Cloud API (Meta Graph API v23.0), using your WhatsApp Business Account access token to send messages, submit templates, upload media, and push catalog data. Inbound messages and status updates from Meta arrive via webhooks registered to your WABA.
## What the Meta integration provides
* **Outbound messaging** — campaigns, automation messages, and Inbox agent replies sent via the Message API
* **Template management** — template creation, submission, and approval status sync via the Template API
* **Media upload** — images, videos, and documents uploaded for use in template headers via the Media Upload API
* **Catalog sync** — product data pushed from Galantis to Meta via the Catalog API
* **Inbound messages** — customer messages received through your WhatsApp number arrive via webhook and appear in the Inbox
* **Message status updates** — delivered, read, and failed status callbacks for every sent message, used for analytics and automation condition evaluation
## Guides in this section
The Meta OAuth flow, token storage, phone number registration, and reconnection.
Inbound message webhooks, message status updates, and template status change events.
Adding and managing multiple WhatsApp Business phone numbers per workspace.
## Meta API endpoints used
| API | Endpoint | Purpose |
| --------------------- | ----------------------------- | --------------------------------------------------------- |
| Message API | `POST /{phone_id}/messages` | Send all outbound WhatsApp messages |
| Media Upload API | `POST /{app_id}/uploads` | Upload images, videos, and documents (resumable protocol) |
| Template API (create) | `POST /message_templates` | Submit new templates for Meta review |
| Template API (read) | `GET /message_templates` | Fetch template list and current approval status |
| Template API (delete) | `DELETE /message_templates` | Delete a template |
| Catalog API | `POST /{catalog_id}/products` | Push product data to Meta Catalog |
All API calls use Meta Graph API version `v23.0` using the merchant's encrypted access token per tenant.
## Authentication model
Galantis stores one Meta access token per connected WhatsApp Business Account, encrypted per tenant. The token is obtained via Meta OAuth during the WABA connection flow and used for all subsequent Meta API calls.
Access tokens can expire or be revoked if permissions change in Meta Business Manager. When this happens, all Meta API calls from Galantis fail for that workspace. Symptoms include messages not sending, catalog sync failing across all products simultaneously, and template status no longer updating.
See [Connecting WABA](./connecting-waba) for how to reconnect and refresh the access token.
## Related guides
* [Getting Started — WhatsApp Connection](/whatsapp/getting-started/whatsapp-connection) — Initial WABA connection walkthrough
* [Catalog — Meta Catalog](/whatsapp/catalog/meta-catalog) — How Galantis uses the Catalog API
* [Templates](/whatsapp/templates/index) — How Galantis uses the Template API
# Meta Webhooks
Source: https://docs.digifist.com/galantis/whatsapp/integrations/meta-whatsapp/meta-webhooks
How Galantis receives inbound messages, message status updates, and template status changes from Meta via webhooks.
Meta sends webhooks to Galantis for three categories of events: inbound messages from customers, outbound message status updates, and template status changes. These webhooks are the real-time data feed from Meta back into Galantis — they are what makes the Inbox live, what populates campaign and automation analytics with delivery data, and what keeps template approval status current.
## What this covers
* The three Meta webhook event categories and what each delivers
* How inbound messages are processed into Inbox conversations
* How message status updates power analytics and automation conditions
* How template status changes update Galantis automatically
* Security validation and retry behavior
## Meta webhook event categories
### Inbound messages
**Event:** `messages` (inbound)
**Payload:** Message object containing sender phone number, message content (text, media, or interactive reply), and context (which message the customer is replying to, if any).
**What Galantis does:**
When an inbound message webhook arrives, Galantis:
1. Validates the webhook signature
2. Identifies the customer by their phone number — matching against contact records in Galantis
3. Creates or updates a `Conversation` record for the customer
4. Creates a `Message` record with the inbound message content
5. Dispatches the `ConversationMessageCreated` event
6. Broadcasts the new message to the merchant dashboard in real time — agents see the message appear in the Inbox immediately without refreshing
The inbound message also opens or resets the 24-hour conversation window for that customer. See [Compliance — Conversation Window](/whatsapp/compliance/conversation-window).
**QUICK\_REPLY responses:** When a customer taps a `QUICK_REPLY` button in a template message, the response arrives as an inbound message webhook with the button's reply payload. Automation condition nodes using `USER_REPLY_STATUS` evaluate against these reply events.
**STOP responses:** When a customer replies STOP, the inbound message webhook is received, the reply is processed, and the customer's `marketing_state` is immediately updated to `UNSUBSCRIBED`. See [Audience — Consent & Opt-outs](/whatsapp/audience/consent-optouts).
***
### Message status updates
**Event:** `message_status`
**Payload:** Status update containing the message ID, the new status (`sent`, `delivered`, `read`, `failed`), and a timestamp.
**Status progression:**
```
sent → delivered → read
↓
failed (at any stage)
```
**What Galantis does:**
When a message status webhook arrives:
1. Galantis matches the message ID to the corresponding `Message` record
2. Updates `Message.status` and the relevant status timestamp field
3. Aggregates the updated status into campaign-level or automation-level analytics
This is the mechanism that populates the `SENT`, `DELIVERED`, `READ`, and `FAILED` counts in campaign analytics and automation activity logs. Status updates arrive asynchronously — a campaign's analytics populate gradually as Meta sends callbacks for each message in the send batch.
**`played` status:** For audio and video messages, Meta sends a `played` status in addition to `read`. Galantis records this status on the `Message` model.
**`failed` status:** A failed status includes an error code and description from Meta indicating why delivery failed. Common failure codes (`CUSTOMER_IS_NOT_OPTED_IN`, `CUSTOMER_IS_MISSING_CALLING_CODE`) are exposed in campaign analytics and automation activity logs as human-readable error reasons.
**Automation condition evaluation:** The `MESSAGE_DELIVERY_STATUS` condition type in automation flows evaluates against the delivery status recorded via these webhooks. A condition checking whether the last message was "read" evaluates against the `read` status update received here.
***
### Template status changes
**Event:** `message_template_status_update`
**Payload:** Template identifier and new status — `approved`, `rejected`, or `paused`.
**What Galantis does:**
When a template status change webhook arrives:
1. Galantis matches the template identifier to the corresponding `MessageTemplate` record
2. Updates `MessageTemplate.status` to reflect the new state
3. If the template has moved to `APPROVED`, it becomes immediately available for use in campaigns and automation Action Nodes
4. If the template has moved to `REJECTED` or `PAUSED`, any active automations using it begin failing at the affected Action Node on subsequent customer executions — the automation is not automatically deactivated
This webhook-based status sync means merchants do not need to manually poll for template approval results. When Meta completes a review, the status in Galantis updates automatically — typically within minutes of the review completing.
## Security validation
All incoming Meta webhooks are validated via signature verification before processing. Meta includes a cryptographic signature in the webhook request headers, computed from the payload using the app secret. Galantis verifies this signature before passing the payload to any handler — requests with invalid or missing signatures are rejected immediately and never processed.
This validation prevents replay attacks and unauthorized webhook injection from sources other than Meta.
## Retry behavior
If Galantis fails to process a Meta webhook — due to a temporary server error, a processing issue, or an application exception — the failed processing is retried automatically with exponential backoff. This means a transient error does not permanently lose a webhook event.
Meta also retries webhook delivery from its side if the initial delivery attempt receives an error response. Combined with Galantis's own retry behavior, the system is resilient to most temporary failures in the processing pipeline.
If Galantis is unavailable for an extended period — longer than Meta's webhook delivery retry window — some webhook events may not be recoverable from Meta's side. In this case, message status updates may be missing from analytics for messages sent during the outage window, and inbound messages received during the outage may not appear in the Inbox. This is an edge case that applies only to extended outages, not to normal transient errors.
## Related guides
* [Inbox — Conversation Lifecycle](/whatsapp/inbox/conversation-lifecycle) — How inbound message webhooks create and update conversations
* [Compliance — Conversation Window](/whatsapp/compliance/conversation-window) — How inbound messages open and reset the 24-hour window
* [Campaign Analytics](/whatsapp/campaigns/campaign-analytics) — How status update webhooks populate delivery metrics
* [Templates — Approval Lifecycle](/whatsapp/templates/approval-lifecycle) — How template status webhooks update template state in Galantis
# Multiple Phone Numbers
Source: https://docs.digifist.com/galantis/whatsapp/integrations/meta-whatsapp/multiple-phone-numbers
Adding and managing multiple WhatsApp Business phone numbers within a single Galantis workspace.
Galantis supports connecting multiple WhatsApp Business phone numbers to a single workspace. Each number operates independently — it has its own sending identity, its own conversation threads, and its own quality rating in Meta. Using multiple numbers is appropriate for businesses that operate distinct brands, regions, or support functions under one Shopify store.
## What this covers
* When to use multiple phone numbers
* How to add a number to an existing workspace
* How numbers are used across campaigns, automations, and the Inbox
* Quality and compliance considerations per number
## When to use multiple phone numbers
**Multiple brands** — A Shopify store operating more than one brand may want each brand to have its own WhatsApp number so customers receive messages from a recognizable brand identity rather than a shared business number.
**Regional separation** — Stores serving multiple markets may want country-specific numbers — a Mexican number for LATAM customers and a UAE number for MENA customers — so messages arrive from a local or familiar-looking number.
**Functional separation** — Separating marketing sends from customer support conversations onto different numbers keeps the quality signals for each use case independent. A high-volume campaign number with some block rate does not drag down the quality rating of a support number used for high-satisfaction Inbox conversations.
**Dedicated high-volume sending** — A number used exclusively for large campaign broadcasts will accumulate quality signals specific to broadcast behavior. Keeping it separate from a transactional number protects the transactional number's quality.
## Adding a phone number
Go to **Settings → WhatsApp Connection** in the Galantis dashboard.
Select the option to add a phone number. You will be prompted to go through the Meta OAuth flow again — or, if your current WABA access token has sufficient permissions, Galantis may be able to fetch additional numbers from the same WABA without a full re-authorization.
Galantis fetches the phone numbers registered on your WABA. Select the additional number you want to connect.
After adding, confirm the number appears in your connected numbers list under **Settings → WhatsApp Connection** and is shown as active.
All phone numbers connected to a Galantis workspace must be registered on the same WhatsApp Business Account (WABA). Numbers from different WABAs cannot be connected to the same workspace. If you need numbers from multiple WABAs, contact Galantis support to discuss workspace configuration options.
## How multiple numbers work in campaigns and automations
**Campaigns** — Each campaign is associated with a single phone number. Multiple numbers are supported per workspace, allowing different numbers to be used for different campaign sends.
**Automations** — Each automation's Action Nodes send from a specified phone number. If you have numbers segmented by region, you can build separate automation flows per region, each using the appropriate number, or use `CUSTOMER_COUNTRY` condition nodes to route customers to Action Nodes configured with different number assignments.
**Inbox** — Conversations are associated with the phone number the customer messaged. Agents see conversations across all connected numbers in the unified Inbox.
## Quality and compliance per number
Every connected phone number has its own independent quality rating in Meta. Actions taken on one number — block rates, template rejection patterns, message frequency — do not directly affect the quality rating of other numbers in the same workspace.
This independence is one of the primary operational reasons to separate numbers by use case. A campaign number that absorbs the quality cost of high-volume promotional sends does not contaminate the quality rating of a support number used for Inbox conversations.
Each number must maintain its own compliance posture:
* Templates used on a number are reviewed against that number's sending history and quality signals
* Frequency caps on automations apply per number — a customer enrolled in an automation on Number A is not covered by frequency caps on Number B
* Opt-outs (STOP replies) are processed per number — a customer who replies STOP to a message from Number A is opted out from Number A, but their consent state in Galantis is updated globally across the workspace
Consent opt-outs update the customer's `marketing_state` globally in Galantis — not per phone number. A customer who replies STOP to any message from any connected number will be moved to `UNSUBSCRIBED` and excluded from all messaging across all numbers in the workspace. Managing separate opt-in lists per number is not supported at the consent state level.
## Related guides
* [Connecting WABA](./connecting-waba) — Adding numbers via the OAuth connection flow
* [Compliance — Opt-in & Consent](/whatsapp/compliance/opt-in-consent) — How consent state applies globally across numbers
* [Compliance — Quality & Deliverability](/whatsapp/compliance/quality-deliverability) — Per-number quality ratings and how they are managed
# Abandoned Checkout
Source: https://docs.digifist.com/galantis/whatsapp/integrations/shopify/abandoned-checkout
How Galantis detects abandoned checkouts through polling — the mechanism, timing, and implications for automation configuration.
Abandoned checkout detection works differently from every other Shopify integration in Galantis. While customer, order, and product data are all event-driven — Shopify sends a webhook the moment something changes — there is no equivalent webhook for abandoned checkouts. Shopify does not emit a real-time event when a customer starts a checkout and leaves without completing it.
Instead, Galantis polls the Shopify Admin GraphQL API every 10 minutes and queries for incomplete checkouts. This polling mechanism is reliable but introduces a timing gap that has direct implications for how abandoned checkout automations behave.
## What this covers
* Why polling is used instead of a webhook
* How the polling mechanism works
* The 10-minute timing gap and what it means for automation configuration
* What qualifies as an abandoned checkout in Galantis
* Edge cases and timing considerations
## Why polling is required
Shopify's webhook system fires events for discrete state changes — a customer is created, an order is placed, a product is updated. Checkout abandonment is not a discrete event in Shopify — it is the absence of an event (order placement) after a checkout was started. Shopify has no mechanism to push a notification to an external app when this absence occurs.
The `read_checkouts` permission grants Galantis access to the Shopify Admin GraphQL API endpoint that lists incomplete checkouts. Galantis queries this endpoint periodically to identify checkouts that were created but have not resulted in a completed order within a qualifying timeframe.
## How the polling mechanism works
Galantis runs a scheduled job every 10 minutes that queries the Shopify Admin GraphQL API for incomplete checkouts — checkouts that were created within a recent time window and have no associated completed order.
The job filters results to identify checkouts that meet the abandonment criteria — a checkout exists, the customer has a WhatsApp number, and no completed order has been placed from that checkout session.
For each qualifying checkout, the `ABANDONED_CHECKOUT` trigger fires for the associated customer, enrolling them in any active automation with that trigger — subject to frequency cap and exclusion rule checks.
## The 10-minute timing gap
The polling interval creates an inherent timing gap between the moment a customer abandons a checkout and when the `ABANDONED_CHECKOUT` trigger fires in Galantis. This gap can be anywhere from near-zero (if a customer abandons immediately before a poll runs) to just under 10 minutes (if they abandon immediately after a poll runs).
**Practical implication for automation configuration:**
A Delay Node set to 30 minutes in an abandoned checkout automation does not mean the customer receives a message 30 minutes after abandoning. It means the customer receives a message approximately 30 to 40 minutes after abandoning — the delay runs from when the trigger fires, not from when the customer actually left.
This is not a defect — it is the expected behavior of a polling-based detection system. For most abandoned checkout recovery flows, a 10-minute variance has no meaningful impact on conversion rates. A customer who abandoned 35 minutes ago and one who abandoned 40 minutes ago have equivalent recovery likelihood.
For merchants who need more precise timing documentation in their analytics or reporting, the trigger fire time (when the automation enrolled the customer) is recorded in the activity log. The actual checkout abandonment time is available in Shopify's checkout data.
## What qualifies as an abandoned checkout
Galantis identifies a checkout as abandoned when:
* A Shopify checkout record exists for a customer with a WhatsApp number
* The checkout has not been completed — no associated order exists
## Edge cases and timing considerations
**Customer completes the order between poll cycles**
If a customer abandons their checkout and then returns and completes the order before the next poll runs, Galantis may detect the incomplete checkout on its next poll. Since the order now exists, the checkout no longer qualifies as abandoned and the trigger should not fire.
If the trigger fires between the abandonment and the order completion within the same 10-minute poll window — which is possible if the abandonment and completion both occur between polls — an `ORDER_RECENCY` condition node in the automation can catch this. A condition that checks whether the customer placed an order within the last 30 minutes before the first action node will route completed-order customers to the NO path and suppress the recovery message.
**Multiple abandoned checkouts from the same customer**
If a customer abandons a checkout, receives a recovery message, and then abandons a new checkout within the frequency cap window, the cap prevents the second abandonment from triggering a new automation enrollment. The frequency cap check runs at trigger time — if the customer is within the cap window, the new abandonment is detected but no new enrollment occurs.
**Checkouts without a WhatsApp number**
Guest customers who have not provided a phone number, or customers whose phone number is not registered on WhatsApp, cannot receive a recovery message. The trigger may still fire for these customers if they have a Shopify customer record, but the subsequent message action will fail with a delivery error. An `ABANDONED_CHECKOUT` automation will attempt enrollment for any customer associated with the incomplete checkout — phone number validity is checked at the message dispatch step, not at the trigger evaluation step.
## Related guides
* [Automations — Triggers](/whatsapp/automations/triggers) — ABANDONED\_CHECKOUT trigger configuration including the polling timing note
* [Automations — Recipes — Abandoned Checkout Recovery](/whatsapp/automations/recipes/abandoned-checkout) — Full recipe with delay configuration that accounts for polling latency
* [Permissions](./permissions) — The `read_checkouts` permission required for polling
# Shopify Integration
Source: https://docs.digifist.com/galantis/whatsapp/integrations/shopify/index
How Galantis connects to Shopify — data synced, authentication, webhook infrastructure, and the abandoned checkout polling mechanism.
The Shopify integration is the data foundation of Galantis. Every customer profile, order record, product, collection, and consent state in Galantis originates from Shopify and is kept current through a combination of real-time webhooks and periodic polling. The integration is established during app installation and maintained automatically — but understanding its structure helps diagnose data issues and configure features correctly.
## What the Shopify integration provides
* **Customer data** — contact profiles, phone numbers, tags, marketing consent, and order history, synced via webhooks and an initial import at installation
* **Order data** — order creation, cancellation, and fulfillment events that power automation triggers and segment rules
* **Product and collection data** — the full product catalog synced into Galantis for Back-in-Stock, segment rules, and catalog message formats
* **Abandoned checkout data** — polled every 10 minutes via the Shopify Admin GraphQL API
* **Marketing consent** — `marketing_state` updates synced via the `customers/marketing_consent_updated` webhook
* **App billing** — subscription and plan management handled through Shopify's billing system via `app_subscriptions/update`
* **GDPR compliance** — data deletion requests handled via `customers/redact` and `shop/redact` webhooks
## Guides in this section
All Shopify permissions required by Galantis and what each enables.
Complete webhook topic reference — every registered webhook and its handler job.
How the polling mechanism works and its timing implications for automation.
## Authentication
The Shopify integration uses OAuth token exchange. When Galantis is installed from the Shopify App Store, the installation initiates the OAuth flow and the resulting access token is stored encrypted per tenant and used for all subsequent Shopify Admin GraphQL API calls.
The access token remains valid as long as the Galantis app is installed on the Shopify store. Uninstalling the app revokes the token and triggers the `app/uninstalled` webhook, which deactivates the Galantis tenant workspace.
## Multi-tenant architecture
Galantis provides complete isolation between merchant workspaces. Each installed store's data — customer records, automation configurations, campaign history, and integration tokens — is never shared across tenants. The Shopify access token for one store cannot access or affect any other store's data in Galantis.
## Related guides
* [Getting Started — Shopify Installation](/whatsapp/getting-started/shopify-installation) — Installation walkthrough and permission grant steps
* [Audience — Contacts](/whatsapp/audience/contacts) — How synced Shopify data populates customer profiles
* [Catalog — Shopify Sync](/whatsapp/catalog/shopify-sync) — How product and collection data syncs from Shopify
# Permissions
Source: https://docs.digifist.com/galantis/whatsapp/integrations/shopify/permissions
All Shopify permissions required by Galantis, what each enables, and what stops working if a permission is missing.
Galantis requests a defined set of Shopify permissions during installation. Each permission unlocks a specific category of data access or action capability. No permissions are requested speculatively — every permission maps directly to a platform feature. If a permission is not granted, the feature that depends on it will not function.
## What this covers
* All required Shopify permissions
* What each permission enables in Galantis
* What breaks if a permission is missing or revoked
* How to verify permission status
## Required permissions
**`read_customers`** — Allows Galantis to read customer records from Shopify.
**Enables:**
* Initial customer import at installation — populates the Galantis contact database with your existing customers
* Processing of `customers/create`, `customers/update`, and `customers/delete` webhooks — keeps customer profiles current
* Reading customer phone numbers, names, emails, tags, and locale for contact profiles
* Audience targeting — lists and segments draw from synced customer data
**`write_customers`** — Allows Galantis to write to customer records in Shopify.
**Enables:**
* Updating marketing consent state on the Shopify customer record when changes originate in Galantis
**If missing:** Customer profiles will not sync. Campaigns and automations targeting customers will have stale or empty audience data. Consent state will not update.
**`read_orders`** — Allows Galantis to read order records from Shopify.
**Enables:**
* Processing of `orders/create`, `orders/cancelled`, and `orders/updated` webhooks — powers `ORDER_PLACED`, `ORDER_CANCELLED`, and `ORDER_SHIPPED` automation triggers
* Order data availability in automation condition evaluation (`ORDER_VALUE`, `ITEM_COUNT_IN_ORDER`, `ORDER_RECENCY`)
* Order history display in the Inbox customer context panel
* Segment rules based on purchase history (total spent, order count, days since last order, purchased collection)
* Template variable mapping for `order.order_number`, `order.total_price`, `order.product_name`
**`read_fulfillments`** — Allows Galantis to read fulfillment data from Shopify.
**Enables:**
* Detecting when an order has been fulfilled and shipped
* Powering the `ORDER_SHIPPED` automation trigger via the `orders/updated` webhook with fulfillment data
**If missing:** Order-based automation triggers (`ORDER_PLACED`, `ORDER_CANCELLED`, `ORDER_SHIPPED`) will not fire. Segment rules based on purchase history will not evaluate correctly. Order context will not appear in the Inbox.
**`read_products`** — Allows Galantis to read product and collection records from Shopify.
**Enables:**
* Processing of `products/create`, `products/update`, and `products/delete` webhooks — keeps the Galantis product catalog current
* Processing of `collections/create`, `collections/update`, and `collections/delete` webhooks — keeps collection data current
* Catalog module functionality — product data synced into Galantis and available for Meta push
* Back-in-Stock module — inventory quantity monitoring per variant
* Segment rules based on purchased collection or purchased brand
* Automation condition evaluation using `PRODUCT_IN_ORDER_HAS_TAG`
**If missing:** The Catalog module will not function. Back-in-Stock inventory monitoring will not work. Product-based segment rules will not evaluate. Catalog message formats (SPM, MPM, Whole Catalog) will be unavailable.
**`read_checkouts`** — Allows Galantis to read checkout records from Shopify via the Admin GraphQL API.
**Enables:**
* The abandoned checkout polling mechanism — Galantis queries the Shopify Admin API every 10 minutes for incomplete checkouts
* The `ABANDONED_CHECKOUT` automation trigger
**If missing:** The `ABANDONED_CHECKOUT` trigger will not fire. Abandoned checkout recovery automations will be inactive even if configured and activated.
Shopify does not provide a real-time webhook for abandoned checkouts. The `read_checkouts` permission enables polling rather than event-driven detection. See [Abandoned Checkout](./abandoned-checkout) for how the polling mechanism works.
**`read_script_tags`** — Allows Galantis to read the script tags currently installed on your Shopify store.
**`write_script_tags`** — Allows Galantis to write, update, and delete script tags on your Shopify store.
**Enables:**
* Injecting the Inbox storefront chat widget into your theme
* Injecting the Back-in-Stock subscription widget into your theme
* Updating widget scripts when configuration changes are saved in the Galantis dashboard
**If missing:** Neither the Inbox widget nor the Back-in-Stock widget will appear on your storefront. Widget configuration saved in Galantis will have no effect on the live store.
If `write_script_tags` is revoked after installation, existing injected scripts may continue to load from cache temporarily, but any configuration changes made in Galantis will not deploy to the storefront. Re-granting the permission and saving widget settings will re-establish the injection.
## Permission summary
| Permission | Required for | Blocks if missing |
| ------------------- | ------------------------------------------ | -------------------------------------------- |
| `read_customers` | Customer sync, audience targeting | Contact profiles, campaigns, automations |
| `write_customers` | Consent state writeback | Consent sync |
| `read_orders` | Order triggers, segments, Inbox context | Order automations, purchase-based segments |
| `read_fulfillments` | ORDER\_SHIPPED trigger | Shipping automation trigger |
| `read_products` | Catalog, Back-in-Stock, product conditions | Catalog module, BIS module, product segments |
| `read_checkouts` | Abandoned checkout trigger | ABANDONED\_CHECKOUT automation |
| `read_script_tags` | Widget management | Widget deployment |
| `write_script_tags` | Widget injection | Inbox widget, Back-in-Stock widget |
## Verifying permissions
Permissions are granted during app installation and displayed in **Shopify Admin → Settings → Apps and sales channels → Galantis → Permissions**.
If a feature is not working as expected and data issues are suspected, verifying the permission set is a quick first diagnostic step — particularly for script tag permissions, which can be affected by certain Shopify plan changes or reinstallation flows.
## Related guides
* [Getting Started — Shopify Installation](/whatsapp/getting-started/shopify-installation) — How permissions are granted during installation
* [Webhooks](./webhooks) — How individual webhooks depend on these permissions
* [Support — Widget Not Displaying](/whatsapp/support/troubleshooting/widget-not-displaying) — Troubleshooting script tag permission issues
# Webhooks
Source: https://docs.digifist.com/galantis/whatsapp/integrations/shopify/webhooks
Complete reference for every Shopify webhook registered by Galantis — topic and what each webhook powers in the platform.
Galantis registers webhooks across every major Shopify data domain at installation time. These webhooks are the primary mechanism for keeping Galantis data current — when something changes in Shopify, the corresponding webhook fires and Galantis processes the update asynchronously.
Webhook handling is resilient to temporary failures — a transient error does not cause a webhook to be permanently lost. Failed processing is retried automatically until it succeeds or exhausts the retry limit. All incoming webhooks are validated via signature verification before processing.
## What this covers
* Every registered webhook topic
* What each webhook powers in Galantis
* Security validation and retry behavior
* What happens when a webhook is missed
## Customer webhooks
| Topic | What it does in Galantis |
| ------------------------------------- | ---------------------------------------------------------------------------------- |
| `customers/create` | Creates a new contact record; may enroll customer in `CUSTOMER_CREATED` automation |
| `customers/update` | Updates profile fields — name, phone, email, locale, tags |
| `customers/delete` | Removes the contact record |
| `customers/marketing_consent_updated` | Updates `marketing_state` on the contact record |
| `customer_tags/added` | Adds tags to the contact record; may fire `CUSTOMER_TAGGED` automation trigger |
| `customer_tags/removed` | Removes tags from the contact record |
## Order webhooks
| Topic | What it does in Galantis |
| ------------------ | ---------------------------------------------------------------------------------------------------------------- |
| `orders/create` | Creates an order record; enrolls qualifying customers in `ORDER_PLACED` automation |
| `orders/cancelled` | Updates order status; enrolls qualifying customers in `ORDER_CANCELLED` automation |
| `orders/updated` | Detects fulfillment data; enrolls qualifying customers in `ORDER_SHIPPED` automation when fulfillment is present |
The `orders/updated` webhook covers all order update events in Shopify, not only shipping. Galantis specifically detects whether the update contains fulfillment data and only fires the `ORDER_SHIPPED` automation trigger when it does.
## Product and collection webhooks
| Topic | What it does in Galantis |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `products/create` | Creates a product record in Galantis; queues for Meta catalog push |
| `products/update` | Updates product fields, variant data, pricing, and inventory; detects `inventory_quantity` 0→>0 for Back-in-Stock trigger; queues updated product for Meta catalog sync |
| `products/delete` | Removes the product record; removes from Meta catalog |
| `collections/create` | Creates a collection record in Galantis |
| `collections/update` | Updates collection data and product memberships |
| `collections/delete` | Removes the collection record |
## Billing and app lifecycle webhooks
| Topic | What it does in Galantis |
| -------------------------- | -------------------------------------------------------------------------------------------------- |
| `app_subscriptions/update` | Processes plan changes, upgrades, downgrades, and subscription status updates from Shopify Billing |
| `app/uninstalled` | Deactivates the workspace; stops all automation processing and message sending for the store |
The `app/uninstalled` webhook triggers immediate workspace deactivation. If the app is reinstalled, a new OAuth token exchange occurs and data may need to be re-synced. Active automations and campaign schedules from before uninstallation are not automatically re-activated.
## GDPR compliance webhooks
| Topic | What it does in Galantis |
| ------------------ | ------------------------------------------------------------------------------------------------------------ |
| `customers/redact` | Sets the affected customer's `marketing_state` to `REDACTED`; initiates data erasure for the customer record |
| `shop/redact` | Initiates full shop-level data erasure for uninstalled stores that have requested data deletion |
These webhooks are sent by Shopify in response to GDPR data subject requests and merchant data deletion requests. See [Compliance — GDPR & Data Privacy](/whatsapp/compliance/gdpr-data-privacy) for the full context.
## What happens when a webhook is missed
Webhook delivery is not guaranteed — Shopify will retry failed deliveries, but a sustained outage or network issue can result in missed webhooks. When this happens, the Galantis record for affected entities will be stale until a corrective sync occurs.
Recovery options:
* **For product data** — trigger a manual full sync from **Catalog → Shopify Sync → Sync Now**
* **For abandoned checkouts** — the polling mechanism runs every 10 minutes and self-heals; no manual recovery is needed
## Related guides
* [Permissions](./permissions) — Shopify permissions that gate each webhook category
* [Abandoned Checkout](./abandoned-checkout) — The polling mechanism used instead of a webhook for checkout data
* [Catalog — Shopify Sync](/whatsapp/catalog/shopify-sync) — Manual sync as a webhook recovery mechanism for product data
* [Compliance — GDPR & Data Privacy](/whatsapp/compliance/gdpr-data-privacy) — GDPR webhook handling
# Gather Context Before Contacting Support
Source: https://docs.digifist.com/galantis/whatsapp/support/debugging
What to capture from the Galantis dashboard before opening a support ticket — the information that turns a 'something is broken' message into a fix in the same day.
Most issues that aren't resolved by the troubleshooting guides become a support ticket. The single biggest factor in how fast that ticket gets resolved is the **context you include**. A ticket with a clear reproduction path, the right identifiers, and the visible error message gets triaged immediately; a ticket that just says "messages aren't sending" sits in a queue while we ask the same follow-up questions back.
This page is the checklist of what to capture before you hit Send on the support form.
## The five things every ticket should have
The full URL of your Galantis dashboard (`https://app.galantis.com/` or similar). This identifies which account is affected.
"Campaigns → Send" or "Automations → New Order trigger" — not just "messaging." The more specific, the faster we find it.
The exact sequence of clicks that triggers the issue. If it's intermittent, note how often it happens.
Copy-paste the exact text Galantis shows you. Screenshots are perfect for this — capture both the error and the screen state.
When did it happen? Include your timezone. We use this to locate the relevant operation on our side.
What did you expect to happen, and what happened instead? This often surfaces miscommunications faster than the error message.
## Where to find each piece of context
### Workspace URL
Your workspace URL is in your browser address bar when you're logged into Galantis. The full URL — not just `app.galantis.com` — uniquely identifies your account.
### Feature and action
Be specific about the Galantis section and the specific action:
* ✅ "Campaigns → 'Summer Sale 2026' campaign → Send button"
* ✅ "Automations → 'Abandoned Cart' → New customer not being enrolled"
* ✅ "Inbox → Reply not delivered to customer Maria Santos"
* ❌ "Sending doesn't work"
* ❌ "Automation broken"
### Reproduction steps
Walk through the exact actions that reliably trigger the issue. Numbered steps work best:
> 1. Open Campaigns
> 2. Click "Summer Sale 2026"
> 3. Click "Send"
> 4. Confirmation dialog appears, click "Confirm"
> 5. Error appears: "Send failed, please try again"
If the issue is intermittent (happens sometimes), note that explicitly: "This succeeded the first 4 times today, failed on attempts 5 and 6 about 2 minutes apart."
### Error messages
Capture exactly what Galantis shows you:
* **Inline error banners** — the red/yellow text at the top of a page
* **Toast notifications** — the temporary pop-ups in the corner
* **Per-record errors** — failure reasons shown next to a specific message, customer, or template
* **Browser console errors** (only if support asks for these specifically — see [Browser console errors](#when-support-asks-for-browser-console-errors))
A screenshot of the error in context is more valuable than a text description. Most browsers can take screenshots with `Cmd+Shift+4` (Mac) or `Win+Shift+S` (Windows).
### Timestamps and timezone
Note when the issue happened, including your timezone:
* "2026-05-12 14:23 (Europe/Brussels)"
* "About 10 minutes ago, around 4:15 PM ET"
For repeated failures, the timing of the first occurrence matters — that's when we look for the originating event.
### Expected vs actual
Two short lines, side by side:
> **Expected:** Campaign sends to all 1,247 opted-in customers, status moves to "Sent."
>
> **Actual:** Campaign moves to "Sending" but stops at 312 messages, status stuck on "Sending" for 20 minutes.
This format catches misunderstandings about how a feature is supposed to work — sometimes "broken" turns out to be "working as designed but unexpectedly."
## Quick diagnostics you can run first
Before opening a ticket, three checks resolve a surprising share of issues:
Many message failures trace back to the customer record itself. Open **Audience → Contacts → \[Customer Name]** and verify:
* **Consent status** — is it Subscribed? Customers in other states are correctly blocked from marketing sends.
* **Phone number** — is it in full international format (with `+` and country code)? Numbers without a country code can't be delivered.
* **Recent message history** — does the most recent send show a failure reason?
For campaign or automation issues: open **Templates → \[Template Name]** and confirm the template status is **Approved**. Templates in Pending, Rejected, or Paused state cannot send. See [Template Rejection](/galantis/whatsapp/support/troubleshooting/template-rejection) if it's Rejected.
Open **Settings → WhatsApp Connection** and confirm your WhatsApp Business Account shows as connected with a valid phone number. If you see "Reconnect" or an error state, that's likely the root cause — see [Connect WhatsApp](/galantis/whatsapp/getting-started/whatsapp-connection).
Open **Billing → Usage**. If your Conversation credits are at or near zero, that explains any current send failures. Top up or upgrade your plan — see [Billing overview](/galantis/whatsapp/billing/overview).
If any of these checks identifies the issue, the [troubleshooting guides](#related-guides) cover the resolution. If everything looks fine and the issue persists, it's time for a support ticket — with all the context above included.
## When support asks for browser console errors
For widget display issues or unusual UI behavior, support may ask you to capture browser console errors. These help us diagnose issues that happen client-side (in your browser) rather than server-side.
Visit your live store URL (e.g. `https://your-store.com`) — not the Shopify theme editor preview, which doesn't run third-party scripts.
Press `F12` (Windows/Linux), `Cmd+Option+I` (Mac), or right-click → Inspect.
The Console tab shows runtime messages and errors. Reload the page.
Take a screenshot of the Console with the errors visible, or copy the error text. Include the URL of the page where the errors appeared.
## A complete ticket template
If you'd like a template to fill in before opening a ticket:
```
Workspace: https://app.galantis.com/
Feature: Campaigns → "Summer Sale 2026"
Action: Click Send
When: 2026-05-12 14:23 (Europe/Brussels)
Steps to reproduce:
1. Open Campaigns
2. Click "Summer Sale 2026"
3. Click "Send"
4. Confirm in the dialog
5. Error: "Send failed, please try again"
Expected: Campaign sends to all 1,247 opted-in customers.
Actual: Error appears, no messages are dispatched.
Already checked:
- Customer consent statuses look correct
- Template "summer-sale-promo" shows Approved
- WhatsApp connection is healthy
- Credit balance: 5,200 (sufficient for the send)
Screenshot attached.
```
A ticket like this gets resolved fastest. The more of the five context items you include, the less back-and-forth between you and support.
## Related guides
* [Support](/galantis/whatsapp/support) — Contact channels, response times, and escalation process
* [Message Delivery](/galantis/whatsapp/support/troubleshooting/message-delivery) — Common delivery error types and their resolution
* [Catalog Sync Errors](/galantis/whatsapp/support/troubleshooting/catalog-sync-errors) — Resolving Catalog sync failures
* [Template Rejection](/galantis/whatsapp/support/troubleshooting/template-rejection) — Why templates get rejected and how to resubmit
* [Widget Not Displaying](/galantis/whatsapp/support/troubleshooting/widget-not-displaying) — Storefront widget troubleshooting
# Support
Source: https://docs.digifist.com/galantis/whatsapp/support/index
How to get help with Galantis — troubleshooting guides, contact methods, response times, and escalation process.
This section covers everything you need when something isn't working as expected — from self-service troubleshooting guides for the most common issues to direct support contact and escalation paths for confirmed bugs or service disruptions.
Start with the troubleshooting guides. Most issues have a documented resolution path that's faster than waiting for a support response. If the guides don't resolve the issue, the gather-context guide explains exactly what to capture from the Galantis dashboard before opening a ticket so support can triage quickly.
## Guides in this section
The five things to capture from the Galantis dashboard before opening a ticket — turns "something is broken" into a same-day fix.
Diagnosing and resolving Meta template rejections and paused templates.
Resolving FAILED product sync status, image format failures, and Meta Catalog token issues.
Diagnosing failed message sends — consent errors, missing calling codes, and credit failures.
Fixing Inbox and Back-in-Stock widgets that are not appearing on your storefront.
## Contacting support
Galantis support is available through two channels:
* **In-app support chat** — accessible from the Galantis dashboard. The fastest path for questions and configuration help.
* **Email** — for issues that require file attachments, log exports, or detailed written context.
When contacting support, include:
* Your tenant workspace URL
* The feature and specific action that is failing
* Steps to reproduce the issue
* Any error messages visible in the Galantis interface
* A screenshot of the error and the relevant Galantis screen — see [Gather context](./debugging)
The more context you provide upfront, the faster the issue can be triaged and escalated if needed.
## Response times
| Priority | Definition | Target response |
| ------------ | -------------------------------------------------------------- | --------------- |
| **Critical** | Service outage — platform unavailable or all messaging stopped | \< 2 hours |
| **High** | Feature broken — a specific feature is non-functional | \< 8 hours |
| **Normal** | Questions, configuration help, non-urgent issues | \< 24 hours |
Response time targets apply during standard business hours. Critical issues with confirmed service outage receive escalated attention outside business hours.
## Escalation process
Support requests follow a standard escalation path:
A support agent reviews the reported issue, attempts to reproduce it using the provided context, and determines whether it can be resolved through configuration guidance or requires engineering involvement.
Confirmed bugs — issues that cannot be resolved through configuration and represent unexpected platform behavior — are escalated to the engineering team with the full reproduction context.
Engineering determines the appropriate resolution path — hotfix for critical issues, scheduled fix for lower-severity bugs. The merchant is notified of the fix timeline and informed when the resolution is deployed.
## Before contacting support
Run through the relevant troubleshooting guide first — the most common issues have documented resolution paths that don't require a support ticket. If the guide doesn't resolve the issue, gather the context listed in [Gather context for support](./debugging) before reaching out. A support ticket with workspace URL, exact error message, timestamp, and reproduction steps is triaged significantly faster than one without.
# Catalog Sync Errors
Source: https://docs.digifist.com/galantis/whatsapp/support/troubleshooting/catalog-sync-errors
Resolving FAILED product sync status, image format failures, Meta Catalog token issues, and other catalog synchronization problems.
Catalog sync errors prevent products from being pushed to Meta, which blocks SPM, MPM, and Whole Catalog message formats from displaying accurate or any product data. Most sync errors have a clear root cause visible in the product's error detail and a straightforward resolution path that does not require engineering involvement.
## What this covers
* How to identify which products have sync errors
* The most common error types and how to resolve each
* How to trigger a re-sync after fixing the root cause
* When to contact support
## Step 1 — Identify the failing products
Go to **Catalog** in the Galantis dashboard. The main view shows aggregate sync status counts — the number of products with `SYNCED`, `PENDING`, and `FAILED` status.
Filter the product list to show only products with `FAILED` status. This gives you the scope of the issue — a handful of isolated failures versus a wholesale failure across many products at once.
Click into an individual `FAILED` product and navigate to its sync status detail. The error detail shows the specific reason Meta rejected or failed to process this product during the push.
Review several `FAILED` products if there are multiple. Look for a common error type — a single root cause affecting many products at once (e.g., a token expiry) has a different resolution path from isolated per-product failures (e.g., individual image format issues).
## Common error types and resolutions
**Symptom:** Individual products with `FAILED` status. Error detail references image format, image size, or image validation.
**Cause:** Meta requires product images to be JPEG or PNG format and at least 500×500 pixels. Images that are a different format (WebP, GIF, AVIF), are below the minimum dimensions, or have a corrupted file will fail the Meta push.
**How to resolve:**
1. Identify the affected product in **Catalog → \[Product Name] → Error Details**
2. Open the product in **Shopify Admin → Products** and update the product image to a JPEG or PNG file that meets the minimum 500×500px requirement
3. Save the product in Shopify — this triggers an automatic webhook update in Galantis
4. The next catalog sync cycle will re-attempt the Meta push with the updated image
You do not need to manually trigger a re-sync for individual image fixes — the Shopify product update webhook handles it automatically.
**How to avoid:** When adding product images in Shopify, use JPEG or PNG format at a minimum of 500×500px. Shopify's image optimizer may convert formats, so verify the final stored format if images are uploaded via third-party tools.
If many products have image failures, run a bulk image audit in Shopify before triggering a manual re-sync. Fix all image issues first, then trigger one manual sync rather than multiple incremental re-syncs.
**Symptom:** A sudden spike of `FAILED` status across many products simultaneously — products that were previously `SYNCED` are now `FAILED` with no corresponding changes in Shopify. The pattern affects many products at once rather than isolated items.
**Cause:** The Meta Catalog access token has expired or been revoked in Meta Business Manager. All catalog push attempts fail at the authentication layer before any product data is evaluated.
**How to resolve:**
1. Go to **Settings → WhatsApp Connection** and check the Meta Catalog token status
2. If the token is shown as expired or invalid, click **Reconnect** and go through the Meta OAuth flow to issue a new token
3. After reconnecting, trigger a manual sync from **Catalog → Shopify Sync → Sync Now** to re-queue all `FAILED` products for the next Meta push cycle
A token expiry causes all products to show `FAILED` simultaneously. Do not attempt to fix individual products while the token is invalid — all attempts will fail. Reconnect the token first, then re-sync.
**How to avoid:** Check the Meta Catalog token status periodically, especially before high-traffic campaign periods. A token that expires during a sale or launch period will prevent catalog-based messages from displaying correct product data.
**Symptom:** Individual products with `FAILED` status. Error detail references a missing field — typically title, price, or image.
**Cause:** Meta requires a minimum set of fields for a product to be accepted into a catalog. Products missing a title, a price, or at least one image cannot be pushed.
**How to resolve:**
1. Open the `FAILED` product in **Catalog → \[Product Name] → Error Details** and identify the missing field
2. Open the product in Shopify and add the missing information — a product title, a variant price, or a product image
3. Save in Shopify — the `products/update` webhook fires automatically and updates the Galantis record
4. The next Meta sync cycle will include the now-complete product
**Common missing field scenarios:**
* Draft products that were synced before their data was complete — ensure products are fully configured before they enter the catalog sync pipeline
* Products with variants that have no price set (price = 0 or price = null) — verify all variant prices are correctly set in Shopify
**Symptom:** Campaigns or automations using SPM or MPM templates show message send failures. The error references a product that no longer exists.
**Cause:** A product was deleted from Shopify after a template was built referencing it. Galantis received the `products/delete` webhook and removed the product from its catalog, but the template still references the deleted product ID.
**How to resolve:**
1. Identify which template is referencing the deleted product — check **Templates** for SPM or MPM templates and review their product section configurations
2. Update the template to reference an available, `SYNCED` product
3. Resubmit the template for Meta approval if the product change requires a new approval (it typically will for SPM templates where the product is part of the approved template structure)
4. Once the template is re-approved, update any campaigns or automation Action Nodes that reference it
**How to avoid:** Before deleting a product in Shopify, check whether it is referenced in any active templates. If it is, update the templates first before deleting the product.
**Symptom:** Many products remain in `PENDING` status for an extended period without moving to `SYNCED` or `FAILED`. The sync appears to not be running.
**Cause:** The catalog sync process may not be running as expected — a queue backlog or a processing issue may be preventing products from being pushed.
**How to resolve:**
1. Trigger a manual full sync from **Catalog → Shopify Sync → Sync Now** to force a re-queue of all pending products
2. If the manual sync also does not process the products within a reasonable time, contact Galantis support — this indicates a processing issue that requires investigation
**What to check before contacting support:** Confirm the issue is genuinely `PENDING` for longer than expected, not just a brief queuing delay for a large catalog. A store with thousands of products may take 10–20 minutes for an initial push to complete.
## Triggering a manual re-sync
After fixing the root cause of sync errors, you can accelerate recovery by triggering a manual sync:
Ensure the underlying issue is resolved — images updated in Shopify, token reconnected, missing fields added — before triggering a re-sync. Running a re-sync before fixing the root cause will produce the same failures.
Go to **Catalog → Shopify Sync** and click **Sync Now**.
Products will move from `FAILED` or `PENDING` to `SYNCED` as the Meta push completes for each one. Monitor the aggregate status counts in the Catalog view to confirm progress.
After the sync completes, confirm the previously `FAILED` products now show `SYNCED` status. Any that remain `FAILED` have a different or additional issue — review their error details individually.
## Verifying catalog token health
The Meta Catalog token is a common failure point that is easy to check proactively:
1. Go to **Settings → WhatsApp Connection**
2. Locate the Meta Catalog token status
3. Confirm it shows as valid and connected
4. If it shows as expired, disconnected, or invalid — reconnect immediately
We recommend checking the token status before any catalog-dependent campaign launch and as a first step whenever catalog sync issues appear.
## Related guides
* [Catalog — Catalog Health](/whatsapp/catalog/catalog-health) — Full catalog health monitoring reference
* [Catalog — Meta Catalog](/whatsapp/catalog/meta-catalog) — Token connection and the three catalog flows
* [Catalog — Shopify Sync](/whatsapp/catalog/shopify-sync) — Manual sync and automatic webhook sync behavior
* [Gather context for support](../debugging) — What to capture from the dashboard before opening a sync-related ticket
# Message Delivery
Source: https://docs.digifist.com/galantis/whatsapp/support/troubleshooting/message-delivery
Diagnosing and resolving failed WhatsApp message sends — consent errors, missing calling codes, insufficient credits, and other delivery failures.
Message delivery failures appear as `FAILED` status on individual messages in campaign analytics, automation activity logs, or Inbox conversation threads. Each failure has a specific error reason attached to it — identifying the error reason is the first step to resolving the underlying issue and preventing it from affecting future sends.
## What this covers
* Where to find delivery failure details
* All common error types with resolution steps
* How to prevent each error type in future sends
* What to do when the error is not one of the common types
## Step 1 — Find the failing messages
Delivery failures surface in three places depending on what triggered the send:
**Campaign failures** — Go to **Campaigns → \[Campaign Name]**. The analytics view shows the `FAILED` count. Click into the failed message detail to see per-message error reasons.
**Automation failures** — Go to **Automations → \[Automation Name] → Activity**. Find the customer whose message failed and expand their node execution history. The `FAILED` Action Node shows the specific error reason.
**Inbox failures** — In the conversation thread, failed messages are marked with a failure indicator. The error reason is visible by hovering or expanding the message status.
## Common error types and resolutions
**What it means:** The customer's `marketing_state` is not `SUBSCRIBED` at the time the message was dispatched. Galantis attempted to send to a customer who has not explicitly opted into WhatsApp marketing.
**Common causes:**
* A customer's consent state changed from `SUBSCRIBED` to `UNSUBSCRIBED` between when the campaign audience was estimated and when the send ran — for example, the customer replied STOP to a previous message in the gap between scheduling and dispatch
* A manually imported list included customers without verified `SUBSCRIBED` consent
* A segment was built without a `Consent status = Yes` rule, and some segment members have non-subscribed consent states
**How to resolve:**
* For the current failed send: the message cannot be retroactively delivered — the customer was correctly excluded per WhatsApp policy
* For future sends: add `Consent status = Yes` to all segments used as campaign audiences; review imported lists to ensure all entries have verified consent; check the **Audience → Contacts → \[Customer]** profile to confirm `marketing_state` before investigating further
**How to verify the customer's consent state:**
Go to **Audience → Contacts**, search for the customer, and check their `marketing_state` field. If it shows `UNSUBSCRIBED`, the customer has opted out. If it shows `NOT_SUBSCRIBED` or `UNKNOWN`, they never provided consent.
This error is a compliance enforcement action, not a platform bug. Galantis is working correctly when it blocks sends to non-subscribed customers. The resolution is to ensure your audience targeting only includes `SUBSCRIBED` customers.
**What it means:** The customer's phone number in Galantis does not include a country calling code (e.g., `+52` for Mexico, `+971` for UAE). WhatsApp requires internationally formatted phone numbers for message delivery.
**Common causes:**
* Customers entered their phone number at Shopify checkout without the country code (e.g., `5512345678` instead of `+525512345678`)
* A phone number field in Shopify was not configured to require international format
* A customer data import included phone numbers without calling codes
**How to resolve:**
1. Go to **Audience → Contacts → \[Customer Name]** and check the `phone`, `phone_country_code`, and `phone_calling_code` fields
2. The phone number in Shopify must be corrected — Galantis syncs phone data from Shopify, so fixing it in Galantis only would be overwritten on the next sync
3. Open **Shopify Admin → Customers → \[Customer]** and update the phone number to include the correct international dialing prefix
4. Save the customer record in Shopify — the `customers/update` webhook fires and propagates the corrected number to Galantis
**For bulk affected customers:** If many customers are affected, the root cause is likely a checkout phone field that does not enforce international format. Review your Shopify checkout phone field settings and consider adding validation or auto-formatting that appends the correct country code.
**How to avoid:** Configure Shopify's phone number collection to require or auto-format international phone numbers at the point of entry.
**What it means:** Your Galantis workspace ran out of message credits during the send. Messages dispatched after the credit balance reached zero failed with this error.
**Identifying the scope:** Check your credit balance in **Billing → Overview**. If the balance is at or near zero, insufficient credits is the likely cause for recent failures. Compare the failed message count against your remaining credit balance at the time of the send.
**How to resolve:**
1. Top up your credit balance or upgrade your plan via **Billing**
2. Determine whether the failed messages need to be re-sent — for campaigns, assess whether the unsent recipients are worth a follow-up send once credits are restored; for automations, the automation will resume processing new enrollments once credits are available, but already-failed messages for past enrollments will not auto-retry
**Re-sending failed campaign messages:** If a campaign partially failed due to insufficient credits and you want to reach the failed recipients, you can create a new campaign targeting only those recipients. Filter the audience to customers who did not receive the original campaign — use a list of the failed recipients or a segment based on last-message-received date.
**How to avoid:** Set up a credit balance alert under **Billing** so you receive a notification when the balance drops below a threshold. Review estimated credit requirements before launching large campaigns.
Credits consumed before the balance hit zero are not refunded for partially failed campaigns. Ensure your credit balance is sufficient for the full estimated audience size before launching a campaign — the pre-launch compliance check validates this, but manually topping up before large sends removes the risk entirely.
**What it means:** An agent in the Inbox attempted to send a free-form session message to a customer, but the 24-hour conversation window had closed. Session messages are only permitted within an active window.
**How to resolve:**
* The agent must use an approved template to re-engage the customer outside the window
* In the Inbox, select an approved template from the template picker to send the message
This is not an error in the platform — it is correct enforcement of WhatsApp's messaging policy. See [Compliance — Conversation Window](/whatsapp/compliance/conversation-window) for the full window rules.
**What it means:** The template assigned to the campaign or automation Action Node is not in `APPROVED` status. The message could not be sent because WhatsApp does not accept unapproved template sends.
**How to resolve:**
1. Check the template status in **Templates → \[Template Name]**
2. If `PENDING_APPROVAL` — wait for Meta's review to complete
3. If `REJECTED` — review the rejection reason and fix the template; see [Template Rejection](./template-rejection)
4. If `PAUSED` — the template was previously approved but has been paused by Meta due to quality issues; see [Templates — Quality](/whatsapp/templates/template-quality)
For campaigns, re-launch the campaign once the template is `APPROVED`. For automations, the automation will resume sending correctly once the template is restored to `APPROVED` — no re-activation is needed.
## Errors not listed above
If the error reason on a failed message does not match any of the above, it is typically a Meta API error code that Galantis surfaces directly. These are less common and often transient:
* **Transient network or API errors** — Meta API errors with a 5xx code or a `TEMPORARY_FAILURE` indicator. These typically self-resolve — if the automation or campaign retried the send, check whether subsequent attempts succeeded.
* **Recipient phone number not on WhatsApp** — The customer's phone number is valid internationally but is not registered on WhatsApp. This is a data quality issue — the customer cannot be reached on WhatsApp at this number.
* **Rate limit exceeded** — The phone number's per-period message throughput limit was reached. High-volume campaigns can hit this limit. The send will typically recover in the next batch cycle as the rate limit window resets.
For any persistent error not covered here, capture the specific error code from the failed message detail and open a support ticket via the in-app chat. Include the campaign or automation name, the affected customer (or a sample of affected customers), and a screenshot of the error detail. See [Gather context for support](../debugging) for the full checklist.
## Checking a customer's delivery eligibility
Before investigating a delivery failure in depth, a quick eligibility check on the customer's profile often identifies the root cause immediately:
Go to **Audience → Contacts** and search for the customer whose message failed.
Confirm `marketing_state = SUBSCRIBED`. Any other state means the customer cannot receive campaign or automation messages.
Confirm `phone`, `phone_country_code`, and `phone_calling_code` are all populated and correctly formatted. A missing `phone_calling_code` is the cause of `CUSTOMER_IS_MISSING_CALLING_CODE` failures.
Review the customer's recent message history on their profile. If the last outbound message shows `FAILED`, the error reason is visible there without needing to open the campaign or automation detail.
## Related guides
* [Audience — Consent & Opt-outs](/whatsapp/audience/consent-optouts) — Understanding and managing customer consent states
* [Audience — Contacts](/whatsapp/audience/contacts) — Phone number fields and how they sync from Shopify
* [Billing — Conversations](/whatsapp/billing/conversations) — Credit consumption and balance management
* [Compliance — Conversation Window](/whatsapp/compliance/conversation-window) — The 24-hour window rule for session messages
* [Gather context for support](../debugging) — What to capture before opening a delivery-related ticket
# Template Rejection
Source: https://docs.digifist.com/galantis/whatsapp/support/troubleshooting/template-rejection
Diagnosing and resolving Meta template rejections and paused templates in Galantis.
Template rejection is one of the most common issues merchants encounter. Meta rejects templates that do not comply with its content policies, category requirements, or structural rules. A rejected template cannot be used in campaigns or automations until the issue is resolved and the template is resubmitted and approved.
This guide covers how to find the rejection reason, the most common causes, and exactly what to fix before resubmitting.
## What this covers
* Where to find the rejection reason
* All common rejection causes and how to resolve each
* How to resubmit after fixing the issue
* What to do when a previously approved template is paused
## Step 1 — Find the rejection reason
Go to **Templates** in the Galantis dashboard and locate the template with `REJECTED` status.
Click into the template and navigate to the **Status** tab or section. Meta's rejection reason is displayed here — it identifies the specific policy or structural issue that caused the rejection.
Read the rejection reason carefully before making any changes. Fixing the wrong thing and resubmitting wastes the review cycle and delays your campaign. Meta's rejection reasons are specific — they name the component and the violation.
Resubmitting a template without addressing the rejection reason will result in another rejection. Repeated submissions of the same non-compliant content may affect your template submission standing with Meta.
## Common rejection causes
**What it means:** The template content does not match the declared category. A promotional message was submitted as Utility, or a transactional message was incorrectly submitted as Marketing.
**Most common form:** A template with discount codes, sale language, or promotional CTAs submitted under the `UTILITY` category to benefit from lower per-message pricing.
**How to fix:**
* If the message is promotional — it offers a discount, announces a product, or asks the customer to buy something — change the category to `MARKETING`
* If the message is genuinely transactional but was mistakenly categorized — an order confirmation submitted as Marketing — change to `UTILITY`
* Review the full decision guide in [Templates — Categories](/whatsapp/templates/template-categories) if you are uncertain which category applies
**How to avoid next time:** Apply the single-question test before submitting: "Would the customer benefit from receiving this message even if they were not being asked to buy something?" If yes — Utility. If no — Marketing.
**What it means:** One or more `{{N}}` variable placeholders in the template body or header do not have example values provided. Meta requires concrete sample content for every variable.
**How to identify:** The rejection reason will reference specific variable positions — e.g., "Variable example missing for `{{2}}`."
**How to fix:**
* Open the template builder and locate each `{{N}}` placeholder
* Provide a realistic example value for each variable — not a generic placeholder like `[name]` or `VALUE`, but actual representative content:
* `{{1}}` for `customer.first_name` → example: `María`
* `{{2}}` for `order.total_price` → example: `$349.00`
* `{{3}}` for a discount code → example: `VERANO20`
* Ensure no variable position is left with an empty or placeholder example
**How to avoid next time:** Before submitting any template, verify that every `{{N}}` has a filled-in, realistic example value.
**What it means:** The template body, header, or button text contains content that violates WhatsApp's Business Policy — exaggerated claims, misleading offers, content from a restricted industry, or deceptive language.
**Common examples:**
* Superlative claims without substantiation: "The best prices guaranteed", "100% results"
* Urgency language that is demonstrably false: "Only 1 left!" when inventory is not actually limited
* Content from restricted categories: alcohol, gambling, financial products, health supplements (with restrictions varying by market)
* Deceptive button URLs that navigate to a different destination than the button label implies
**How to fix:**
* Remove or rewrite the flagged content
* Replace exaggerated claims with factual descriptions
* Verify button URLs navigate to the destination the button label describes
* Review Meta's WhatsApp Business Policy for your specific industry and market if you operate in a restricted category
**How to avoid next time:** Write template copy as if it will be reviewed for factual accuracy — because it will be.
**What it means:** Variable placeholders in the template skip a position number. For example, using `{{1}}` and `{{3}}` in the body without `{{2}}`. Meta requires variables to be sequential starting from `{{1}}`.
**How to fix:**
* Review the template body and identify all `{{N}}` placeholders
* Renumber them sequentially: `{{1}}`, `{{2}}`, `{{3}}` — no gaps
* Update the example values to match the renumbered positions
* Update any campaign or automation variable mappings that reference the old position numbers after resubmission
**How to avoid next time:** When editing an existing template and removing a variable, renumber all subsequent variables rather than leaving a gap.
**What it means:** One or more buttons in the template have an invalid configuration — an incorrectly formatted URL, an invalid phone number format, an unsupported button type combination, or a missing required field.
**Common examples:**
* `URL` button with a malformed URL (missing protocol, contains spaces, or uses an unsupported URL scheme)
* `PHONE_NUMBER` button with a phone number that is not in international format (`+` prefix and country code)
* `COPY_CODE` button with an empty code value
* Incompatible button type combinations (Meta has restrictions on which button types can appear together)
**How to fix:**
* Open the template builder and check each button configuration
* For URL buttons: ensure the URL starts with `https://` and is a valid, reachable URL
* For phone number buttons: format the number in full international format including `+` and country code
* For copy code buttons: ensure the code field is populated with a non-empty value
* Remove any button type combinations that Meta does not support
**How to avoid next time:** Test all button URLs before submitting to confirm they resolve correctly.
## Resubmitting after fixing
Edit the template in the Galantis template builder. Address every issue identified in the rejection reason — not just the most obvious one. If the rejection lists multiple issues, fix all of them before resubmitting.
Before resubmitting, read the complete template as if you are a Meta reviewer seeing it for the first time. Confirm the category matches the content, all variables have examples, and all buttons are correctly configured.
Click **Submit**. The template returns to `PENDING_APPROVAL` status. Meta's review typically completes within minutes to a few hours.
Status updates arrive automatically via Meta webhook — the template status in Galantis updates without manual polling. Watch for the status to move to `APPROVED` before scheduling campaigns or activating automations that use this template.
## When a previously approved template is paused
A template that was previously `APPROVED` and in active use can be paused by Meta if quality signals degrade after approval. When this happens, active campaigns referencing it will fail for new sends, and automation Action Nodes using it will return `FAILED` for customers who reach them.
**How to diagnose:**
* Go to **Templates → \[Template Name] → Status** and confirm the template is `PAUSED` rather than `APPROVED`
* Review Meta's reason for the pause if provided
**How to resolve:**
* Assess whether the issue is content-based (revise and resubmit), audience-based (review who is being targeted and whether the message is relevant), or frequency-based (adjust send cadence to reduce block rates)
* If the template content is sound and the issue is audience quality — recipients are blocking because the message is irrelevant to them — improve targeting rather than revising the template
* After addressing the root cause, edit and resubmit the template if content changes were needed
See [Templates — Quality](/whatsapp/templates/template-quality) for the broader context on how Meta evaluates live template quality and what signals lead to a pause.
## Related guides
* [Templates — Categories](/whatsapp/templates/template-categories) — Category selection rules and the decision guide
* [Templates — Creating Templates](/whatsapp/templates/creating-templates) — Variable examples and button configuration
* [Templates — Approval Lifecycle](/whatsapp/templates/approval-lifecycle) — Full status lifecycle reference
* [Templates — Quality](/whatsapp/templates/template-quality) — Why approved templates can be paused after going live
# Widget Not Displaying
Source: https://docs.digifist.com/galantis/whatsapp/support/troubleshooting/widget-not-displaying
Fixing Inbox chat widgets and Back-in-Stock subscription widgets that are not appearing on your Shopify storefront.
Both the Inbox chat widget and the Back-in-Stock subscription widget are injected into your Shopify storefront via script tags. When a widget is not appearing, the cause is almost always one of a small set of identifiable issues — a missing Shopify permission, a caching problem, a theme conflict, or a condition that has not been met for the widget to display.
This guide covers both widgets together since they share the same injection mechanism and the same diagnostic path.
## What this covers
* Pre-checks before troubleshooting
* Diagnosing why a widget is not appearing
* Fixes for each common cause
* Testing after a fix
## Before troubleshooting
Confirm which widget is affected and which symptom you are seeing:
| Symptom | Widget | Section |
| --------------------------------------------------------- | ------------ | ------------------------------------------------------------------------------- |
| Chat button not visible on any page | Inbox widget | [Inbox widget not appearing](#inbox-widget-not-appearing) |
| Chat button not visible on specific pages | Inbox widget | [Display rules and page targeting](#display-rules-and-page-targeting) |
| Back-in-Stock button not visible on out-of-stock products | BIS widget | [BIS widget not appearing](#back-in-stock-widget-not-appearing) |
| Back-in-Stock button visible on in-stock products | BIS widget | [Widget appearing on in-stock variants](#widget-appearing-on-in-stock-variants) |
| Widget visible but form submission fails | Either | [Form submission failures](#form-submission-failures) |
Do not test widgets inside the Shopify theme editor or Customizer preview. The Shopify theme preview does not execute third-party script tags. Always verify widgets on your live storefront URL (e.g., `https://your-store.com`), not `https://your-store.myshopify.com/admin`.
***
## Inbox widget not appearing
### Check 1 — Verify the write\_script\_tags permission
The `write_script_tags` permission is required for Galantis to inject the widget script. If this permission is missing or was revoked, no widget will appear.
**How to check:**
1. Go to **Shopify Admin → Settings → Apps and sales channels**
2. Find Galantis in the installed apps list and click it
3. Open the **Permissions** section
4. Confirm `write_script_tags` is listed as a granted permission
**If the permission is missing:**
* Uninstall and reinstall the Galantis app from the Shopify App Store — this re-initiates the permission grant flow
* Contact Galantis support if reinstalling is not practical
***
### Check 2 — Clear browser cache and reload
Script tag injection can be cached by the browser. A widget that was configured after a recent change may not appear until the cache is cleared.
**Steps:**
1. Open your live storefront URL in a browser
2. Clear the browser cache (`Cmd+Shift+R` on Mac, `Ctrl+Shift+R` on Windows for a hard reload)
3. Check whether the widget now appears
If the widget appears after a hard reload, the issue was browser caching. Future visitors will see the widget after their own cache clears.
***
### Check 3 — Check for JavaScript errors in the browser console
A script conflict with your Shopify theme or another installed app can prevent the Galantis widget script from loading correctly.
**Steps:**
1. Open your live storefront in a browser
2. Open the browser developer tools (`F12` or right-click → Inspect)
3. Navigate to the **Console** tab
4. Reload the page and look for JavaScript errors
If the console shows errors referencing the Galantis widget script or errors that appear to block script execution, note the error message and include it in a support ticket. A screenshot of the console errors is more useful than a text description.
***
### Check 4 — Verify widget settings are saved
If the widget was recently configured but not saved, the script tag may not have been written to Shopify.
**Steps:**
1. Go to **Inbox → Widget Settings** in the Galantis dashboard
2. Confirm the settings are configured (button position, colors, label text)
3. Click **Save** — even if settings appear correct, re-saving forces a script tag write to Shopify
4. Return to your storefront and reload
***
## Display rules and page targeting
If the Inbox chat button is visible on some pages but not others, the issue is likely the widget's display rules configuration.
**Steps:**
1. Go to **Inbox → Widget Settings** and review the **Display rules** section
2. Confirm the pages where the button should appear are included in the display rules
3. Confirm the page you are testing on matches one of the included page patterns
4. Update display rules if needed and save
***
## Back-in-Stock widget not appearing
### Check 1 — Confirm the variant is genuinely out of stock
The Back-in-Stock widget only appears when the currently selected variant has `inventory_quantity = 0` in Shopify. The widget does not appear for in-stock variants, regardless of widget configuration.
**Steps:**
1. Go to **Shopify Admin → Products → \[Product Name]**
2. Find the specific variant you are testing on and confirm its inventory shows `0`
3. If the inventory shows a positive number, the variant is in stock and the widget is working correctly — it should not appear
**Common source of confusion:** A product page where all variants are in stock — the Back-in-Stock widget will not appear on any of them, which may look like a missing widget but is actually correct behavior.
***
### Check 2 — Verify the write\_script\_tags permission
Same check as for the Inbox widget — see [Check 1](#check-1--verify-the-writescript_tags-permission) above.
***
### Check 3 — Check inventory tracking is enabled
If the product has inventory tracking disabled in Shopify, Shopify does not report an `inventory_quantity` for variants. The widget cannot determine stock status and will not appear.
**Steps:**
1. Go to **Shopify Admin → Products → \[Product Name]**
2. In the Inventory section, confirm **Track quantity** is enabled
3. If tracking is disabled, enable it and set the inventory quantity to `0` for the out-of-stock variant
***
### Check 4 — Verify widget settings are saved
Same check as for the Inbox widget — go to **Back-in-Stock → Settings**, confirm configuration, click **Save**, and reload the storefront page.
***
### Check 5 — Test on the live storefront, not theme preview
Repeat the same verification as for the Inbox widget — theme preview does not execute script tags. Test on your live URL.
***
## Widget appearing on in-stock variants
If the Back-in-Stock widget button appears when a customer selects an in-stock variant, the issue is a stale page load — the widget is evaluating inventory data embedded in the page at load time.
**Why this happens:** The page was loaded when the variant was out of stock. The variant was restocked in Shopify after the page loaded. The widget does not re-evaluate inventory in real time — it uses the data embedded at page load.
**Resolution:** This resolves itself on the next page load. No configuration change is needed. The widget will correctly show or hide based on the current inventory state after any page refresh.
***
## Form submission failures
If the widget button appears and the modal opens correctly, but submitting the form fails, the issue is separate from the display/injection layer.
**For the Inbox chat widget:** When a customer taps the chat button and it fails to open WhatsApp or fails to pre-fill your business number, confirm:
* Your WhatsApp Business Account is connected under **Settings → WhatsApp Connection**
* The selected phone number is active and not in an error state
**For the Back-in-Stock subscription form:** When a customer submits their number but the subscription is not recorded in **Back-in-Stock → Subscriptions**:
* Check the browser console for network errors on the form submission request
* Confirm your WhatsApp Business Account is connected
* Contact Galantis support with the browser console error if the issue persists
***
## Testing checklist after a fix
After applying any of the resolutions above, run through this checklist to confirm the widget is working end to end:
* [ ] Widget appears on the correct pages (Inbox: configured pages; BIS: out-of-stock variants only)
* [ ] Widget does not appear where it should not (BIS: in-stock variants; Inbox: excluded pages)
* [ ] Widget button is styled correctly with your configured colors and label text
* [ ] Modal opens when the button is tapped
* [ ] Form submission creates a record (BIS: subscription appears in **Back-in-Stock → Subscriptions**; Inbox: initiates a conversation in **Inbox**)
## Related guides
* [Inbox — Storefront Widget](/whatsapp/inbox/storefront-widget) — Widget installation and placement options
* [Inbox — Widget Appearance](/whatsapp/inbox/widget-appearance) — Display rules and appearance settings
* [Back-in-Stock — Widget Installation](/whatsapp/back-in-stock/widget-installation) — BIS widget installation and verification
* [Back-in-Stock — Product & Inventory Rules](/whatsapp/back-in-stock/product-inventory-rules) — How inventory quantity controls widget visibility
* [Integrations — Shopify — Permissions](/whatsapp/integrations/shopify/permissions) — write\_script\_tags permission context
# Approval Lifecycle
Source: https://docs.digifist.com/galantis/whatsapp/templates/approval-lifecycle
The four template statuses in Galantis — DRAFT, PENDING_APPROVAL, APPROVED, and REJECTED — and what each means for your campaigns and automations.
Every template in Galantis moves through a defined lifecycle from creation to active use. The status at each stage determines whether the template can be used to send messages. Understanding what each status means — and what actions are available at each stage — prevents delays in campaign launches and automation activations.
## What this covers
* All four template statuses and their meaning
* What triggers each status transition
* What you can and cannot do at each status
* How to resolve a rejection and resubmit
* How status changes in Meta affect active automations
## Template statuses
**`DRAFT`** — The template has been saved in Galantis but not yet submitted to Meta.
A template enters `DRAFT` status when it is created and saved without being submitted. It stays in `DRAFT` until you explicitly click **Submit**.
**What you can do in DRAFT:**
* Edit all template components — header, body, footer, buttons, category, and language
* Preview the assembled template
* Submit for Meta review when ready
**What you cannot do in DRAFT:**
* Use the template in a campaign
* Assign the template to an automation Action Node and activate the automation
`DRAFT` templates are not visible to Meta. No review has been initiated. The template exists only in Galantis until submitted.
Use `DRAFT` status to build and iterate on templates before committing to a submission. It is better to spend time in `DRAFT` refining copy, variable examples, and category accuracy than to submit prematurely and receive a rejection.
**`PENDING_APPROVAL`** — The template has been submitted to Meta and is awaiting review.
A template enters `PENDING_APPROVAL` immediately when you click **Submit**. Galantis sends the template to Meta's Template API and the status updates to reflect the pending review.
**What you can do in PENDING\_APPROVAL:**
* View the template and its submitted content
* Monitor the status — it will update automatically when Meta responds
**What you cannot do in PENDING\_APPROVAL:**
* Edit the template — submitted content is locked during review
* Use the template in a campaign or automation
Meta's review typically completes within minutes to a few hours. In some cases — particularly for first-time submissions from a new WhatsApp Business Account — review may take longer. Status updates arrive via Meta webhook and are reflected in Galantis automatically.
You do not need to manually refresh or poll for status updates. Galantis receives Meta's webhook notification when the review completes and updates the template status immediately.
**`APPROVED`** — Meta has reviewed and approved the template. It is ready for use in campaigns and automations.
A template reaches `APPROVED` status when Meta's review confirms the template content is compliant with WhatsApp's Business Policy and the declared category is accurate.
**What you can do in APPROVED:**
* Select the template in the campaign builder
* Assign the template to automation Action Nodes
* Use the template for Inbox agent replies when the conversation window is closed
**What can change after APPROVED:**
* Meta may pause or suspend a template if quality signals degrade after it is live — block rates, report rates, or category compliance flags can cause Meta to move a template from `APPROVED` to a paused state without action from you
* If a template is paused by Meta, active automations using it will begin failing for customers who reach the affected Action Node
Monitor template status periodically in **Templates**, especially for high-volume templates that are actively sending. See [Template Quality](./template-quality) for how quality signals affect live templates.
**`REJECTED`** — Meta's review found the template non-compliant. The template cannot be used until the issues are resolved and it is resubmitted and approved.
A template is rejected when Meta's review identifies one or more compliance issues. The rejection reason is visible in **Templates → \[Template Name] → Status**.
**Common rejection reasons:**
* **Misleading category** — promotional content submitted as Utility, or vice versa
* **Missing or empty variable examples** — `{{N}}` placeholders without sample values
* **Prohibited content** — language that violates WhatsApp's content policies (exaggerated claims, prohibited industries, misleading offers)
* **Incomplete variable sequence** — variable numbers that skip positions (e.g., `{{1}}` and `{{3}}` without `{{2}}`)
* **Invalid button configuration** — button type, URL format, or phone number format errors
**What you can do in REJECTED:**
* Read the rejection reason carefully — it identifies the specific issue
* Edit the template to address the rejection cause
* Resubmit for a new review
**What you cannot do in REJECTED:**
* Use the template in any campaign or automation
Resubmitting a template without addressing the rejection reason will result in another rejection. Read the rejection reason fully before making changes. Repeated submissions of non-compliant content may affect your template submission standing with Meta.
**Resolving a rejection:**
1. Open **Templates → \[Template Name] → Status** and read the rejection reason
2. Identify which component caused the rejection — category, body copy, variable examples, or buttons
3. Edit the template to address the specific issue
4. Add complete, realistic example values to all variable placeholders if missing
5. Resubmit — the template returns to `PENDING_APPROVAL`
## Status transition summary
```
DRAFT
│
└─ Submit ──→ PENDING_APPROVAL
│
├─ Meta approves ──→ APPROVED ──→ (Meta may pause) ──→ Paused/Suspended
│
└─ Meta rejects ──→ REJECTED ──→ Edit and resubmit ──→ PENDING_APPROVAL
```
## Impact on active automations
If a template used in an active automation is paused or suspended by Meta after the automation was activated:
* The automation remains active — it is not automatically deactivated
* Customers who reach the Action Node using the affected template will have that node fail with a `FAILED` status in the activity log
* The automation continues executing for other customers using other Action Nodes that reference approved templates
To resolve: address the template quality issue, restore the template to `APPROVED` status, and confirm the automation's action node is pointing to the restored template. No automation re-activation is needed once the template is approved again.
Automations with any Action Node referencing a non-`APPROVED` template are flagged and cannot be activated. This flag is checked at activation time — an automation that was correctly configured at activation is not retroactively deactivated if a template is later paused.
## Related guides
* [Creating Templates](./creating-templates) — Building templates correctly to minimize rejection risk
* [Template Categories](./template-categories) — Category accuracy — the most common rejection cause
* [Template Quality](./template-quality) — How live template performance affects status after approval
* [Support — Template Rejection](/whatsapp/support/troubleshooting/template-rejection) — Detailed rejection troubleshooting
# Creating Templates
Source: https://docs.digifist.com/galantis/whatsapp/templates/creating-templates
How to build and submit a WhatsApp message template in Galantis — header, body, footer, buttons, and submission.
Templates are built in Galantis and submitted to Meta for review from the same interface. The template builder walks through each structural component — header, body, footer, and buttons — and lets you preview the assembled message before submitting. Once submitted, Meta reviews the template and returns an approval or rejection, typically within minutes to a few hours.
## What this covers
* The four template components and their options
* How to create and submit a template
* Variable placeholder syntax
* Component requirements and limits
* Submission behavior and what happens after
## Creating a template
Go to **Templates → New Template** in the Galantis dashboard.
Select **Marketing** or **Utility**. This must be set before building the template content — it is a declaration of intent that Meta evaluates against your message. See [Template Categories](./template-categories) if you are unsure which applies.
Select the language code for this template (e.g., `en`, `es`, `pt_BR`). Each template is tied to a single language. If you need the same message in multiple languages, create separate template records — one per language.
Configure the header, body, footer, and buttons as described below.
Review the assembled template in the preview panel. When ready, click **Submit** to send it to Meta for review. The status changes to `PENDING_APPROVAL` immediately.
## Template components
### Header (optional)
The header appears above the body text. It is optional but strongly recommended for templates that use image or product formats — a text-only template without a header is valid but may perform less well visually.
A single line of plain text. Supports one optional variable placeholder (`{{1}}`).
Use for: subject-line-style context above the body — store name, offer headline, or a personalized greeting that would feel redundant in the body.
An uploaded image displayed above the body. The image is stored in Galantis and uploaded to Meta's media infrastructure.
Use for: product shots, promotional banners, brand imagery. Meta requires images meet minimum size and format standards — see [Support — Catalog Sync Errors](/whatsapp/support/troubleshooting/catalog-sync-errors) for image requirements.
An uploaded video displayed above the body.
Use for: product demonstrations, brand videos, how-to content. Keep videos short — WhatsApp loads media inline and long videos create friction.
An uploaded PDF or document file.
Use for: product guides, size charts, menus, or any reference material the customer needs to download or view.
A single product pulled from your synced Meta Catalog. Displays the product image, name, and price.
Use for: Single Product Message (SPM) format templates. Requires a connected and synced Meta Catalog. See [Template Formats](./template-formats).
A location pin with coordinates, name, and address.
Use for: store location messages, event venue details, or delivery address confirmations.
***
### Body (required)
The body is the main text of the message. It is the only required component — a template with only a body and no header, footer, or buttons is valid.
**Variable placeholders** are defined in the body using positional syntax: `{{1}}`, `{{2}}`, `{{3}}`. Each placeholder is mapped to a customer or order data field when the template is used in a campaign or automation. Variable positions must be sequential starting from `{{1}}` — gaps in the sequence (e.g., using `{{1}}` and `{{3}}` without `{{2}}`) will cause submission to fail.
**Rich text** — the body supports bold (`*text*`), italic (`_text_`), and strikethrough (`~text~`) formatting.
Meta requires that all variable placeholders in a submitted template include example values — concrete sample text that demonstrates what the variable will contain at send time. Submitting a template with empty variable examples is a common rejection cause. Fill in realistic example values for every `{{N}}` placeholder before submitting.
***
### Footer (optional)
A short line of static text below the body. Does not support variables. Character limit applies — keep it brief.
Common uses:
* Opt-out instruction: `Reply STOP to unsubscribe`
* Brand tagline
* Legal or compliance notice
***
### Buttons (optional, up to 3)
Buttons appear below the footer and give the customer a tappable action. Up to three buttons can be added per template, but all buttons must be of compatible types — not all button type combinations are supported by Meta.
A tappable reply button that sends a predefined text response back to your WhatsApp number when the customer taps it.
Use for: simple binary responses ("Yes, I'm interested" / "No thanks"), feedback collection, or opt-in confirmation flows.
The reply text is defined at template creation time and is fixed — it cannot be personalized per recipient.
Opens a link in the customer's browser when tapped. Supports a dynamic URL variable — the path or query string can be personalized per recipient using a `{{1}}` placeholder in the URL field.
Use for: "Shop now" links to collection pages, "View order" links to order status pages, abandoned checkout recovery links.
Use dynamic URL variables to link directly to a customer's abandoned checkout URL or a personalized recommendation page rather than a generic homepage.
Initiates a phone call to a specified number when tapped.
Use for: customer service contact, sales team calls, or support escalation paths where a live call is the appropriate next step.
Copies a predefined text string to the customer's clipboard when tapped. Typically used for discount codes.
Use for: promotional offer codes, referral codes, or any fixed string the customer needs to paste elsewhere.
The code is set at template creation time. If your offer codes vary per customer, use a URL button linking to a personalized checkout with the discount pre-applied instead.
## Submission and what happens next
When you click **Submit**, Galantis sends the template to Meta's Template API. The template status changes to `PENDING_APPROVAL` and Meta begins its review.
Meta reviews templates for:
* Category accuracy — does the content match the declared category?
* Variable example completeness — are all `{{N}}` placeholders accompanied by example values?
* Content policy compliance — does the message contain prohibited content?
* Button configuration validity — are the button types and values correctly formed?
Approval is typically returned within minutes to a few hours. The template status updates automatically in Galantis when Meta responds — you do not need to manually check or refresh. See [Approval Lifecycle](./approval-lifecycle) for the full status reference.
## Best practices
* **Write the body copy first, then set variables.** Decide what the message says before deciding what to personalize — over-using variables produces awkward, robotic-feeling messages.
* **Always include example values for every variable placeholder.** Empty examples are a rejection trigger. Use realistic values that reflect actual customer data — `Sarah` for `customer.first_name`, `$89.00` for `order.total_price`.
* **Keep footer text genuinely brief.** The footer competes with the body for the customer's attention. `Reply STOP to unsubscribe` is ideal — anything longer reduces the clarity of the main message.
* **Test button URLs before submitting.** A URL button linking to a broken or redirecting URL is a poor first impression and may affect quality signals. Verify all URLs are live and landing on the intended destination.
* **Do not resubmit a rejected template without addressing the rejection reason.** Repeated submissions of the same rejected content signals disregard for Meta's policies and may affect your account standing.
## Related guides
* [Template Categories](./template-categories) — Choosing the correct category before building
* [Template Formats](./template-formats) — Structural format options beyond the standard layout
* [Variables & Localization](./variables-localization) — Variable placeholder mapping and language management
* [Approval Lifecycle](./approval-lifecycle) — What happens after submission
# Templates
Source: https://docs.digifist.com/galantis/whatsapp/templates/index
WhatsApp message templates in Galantis — the pre-approved messages required for all campaigns, automations, and proactive outbound messaging.
Templates are the foundation of every outbound message in Galantis. Every campaign broadcast, every automation action node, and every proactive message sent outside a 24-hour conversation window requires a WhatsApp template that has been submitted to and approved by Meta before it can be used.
A template is not just a message — it is a structured artifact with a fixed format, a category declaration, optional dynamic variables, and a status that Meta controls. Understanding how templates work, what they require, and how Meta evaluates them is essential before building any campaign or automation.
## How templates work in Galantis
Templates are created in Galantis, submitted to Meta for review, and used in campaigns and automations once approved. The lifecycle moves through four states: `DRAFT` → `PENDING_APPROVAL` → `APPROVED` or `REJECTED`. Only `APPROVED` templates can be used to send messages.
At send time, dynamic variable placeholders in the template body — `{{1}}`, `{{2}}` — are populated with real customer or order data, producing a personalized message for each recipient while the template structure remains fixed and Meta-approved.
## Guides in this section
Marketing vs Utility — what each category means and when to use it.
Headers, body, footer, buttons, and how to build and submit a template.
Single Rich Card, Multi Rich Card, SPM, MPM, and Whole Catalog structures.
DRAFT, PENDING\_APPROVAL, APPROVED, and REJECTED — what each status means.
Dynamic variable mapping and per-language template management.
How Meta evaluates template quality and how to keep templates healthy.
## Before creating your first template
Two decisions shape every template before you write a single word of copy:
**Category first** — decide whether the message is Marketing or Utility. This is a compliance decision, not a formatting one. The category you declare must accurately reflect the message's purpose. Getting this wrong is the most common cause of rejection. See [Template Categories](./template-categories).
**Format second** — decide whether you need a standard message, a product card, a carousel, or a catalog-based format. Format choice depends on your campaign type and whether you have a Meta Catalog connected. See [Template Formats](./template-formats).
## Where templates are used
| Feature | Template requirement |
| ----------------- | ------------------------------------------------------------------------------------------------ |
| **Campaigns** | All campaigns require an `APPROVED` template |
| **Automations** | Every Action Node requires an `APPROVED` template |
| **Inbox** | Required when the 24-hour conversation window is closed |
| **Back-in-Stock** | The restock notification is sent via an automation Action Node — requires an `APPROVED` template |
## Related guides
* [Campaigns — Compliance Checks](/whatsapp/campaigns/compliance-checks) — Pre-launch template status validation
* [Automations — Actions](/whatsapp/automations/actions) — How templates are assigned to Action Nodes
* [Compliance — Templates vs Session Messages](/whatsapp/compliance/templates-vs-session) — When templates are required vs session messages
# Template Categories
Source: https://docs.digifist.com/galantis/whatsapp/templates/template-categories
Marketing and Utility — the two template categories in Galantis, what each covers, and why accurate categorization matters.
Every WhatsApp template submitted to Meta must be assigned a category. The category declares the message's purpose to Meta and determines how it is reviewed, how it is priced, and how Meta monitors it after approval. In Galantis, the two categories available are **Marketing** and **Utility**.
Choosing the correct category is a compliance decision. It must accurately reflect what the message does — not what you want it to cost or how quickly you want it approved. Miscategorization is the leading cause of template rejection in Galantis and one of the fastest paths to phone number quality degradation.
## What this covers
* What Marketing and Utility categories mean
* Which messages belong in each category
* Why accurate categorization matters for compliance and deliverability
* Authentication templates and why they are out of scope
## Categories
**Marketing** is the correct category for any message that promotes your brand, drives a purchase decision, or delivers an offer — regardless of how it is worded.
**Use Marketing for:**
* Promotional offers, discount codes, and sale announcements
* New product launches and collection reveals
* Seasonal or event-based campaigns
* Re-engagement messages and win-back offers
* Back-in-stock broadcasts sent as campaigns
* Any message where the primary goal is to drive a customer action that benefits your business
Marketing templates carry a higher per-message cost on **Meta's pricing model** compared to Utility in most markets. Galantis Conversation credits, however, are flat — 1 delivered message = 1 credit regardless of category — so the cost difference only shows up on your Meta invoice, not on the Galantis (Shopify) invoice. Marketing templates also receive closer scrutiny during quality monitoring: a Marketing template with high block rates will degrade your phone number quality faster than a Utility template under the same conditions, because recipients who block a promotional message signal stronger dissatisfaction.
Any message that includes a discount code, promotional CTA, or offer — even if it is embedded alongside transactional content — should be categorized as Marketing. The presence of promotional intent, not the proportion of the message it occupies, determines the correct category.
**Utility** is the correct category for transactional, informational, or service messages — messages the customer expects and benefits from regardless of a purchase decision.
**Use Utility for:**
* Order confirmations and receipts
* Shipping updates and delivery notifications
* Return or refund status updates
* Appointment reminders and booking confirmations
* Account or subscription status updates
* Operational store announcements (policy changes, service updates)
Utility templates carry a lower per-message cost on **Meta's pricing model** in most markets and typically have lower block rates because recipients expect and welcome transactional messages. (Galantis credits are still 1 per delivered message — the Meta saving is real, the Galantis saving is not.) However, Utility templates are held to strict content standards precisely because of these advantages — Meta actively checks that Utility templates do not contain marketing content.
Do not use Utility to send promotional content in order to benefit from lower pricing or faster approval. This is a Meta policy violation. Common violations include: adding a discount code to an order confirmation, embedding a "shop now" CTA in a shipping update, or framing a promotional announcement as a service message. Rejected templates and quality flags are the consequence — not just a formal warning.
## Authentication templates
WhatsApp supports a third category — Authentication — for one-time passcodes and verification messages. Authentication templates are supported at the WhatsApp platform level but are not currently used in Galantis. If your use case requires OTP or verification messaging, contact Galantis support to discuss availability.
## Why accurate categorization matters
Meta enforces category compliance at two points:
**During approval** — Meta's review checks whether the submitted template content matches the declared category. A promotional message submitted as Utility is frequently caught and rejected at this stage. Rejection wastes the approval cycle time and delays your campaign.
**After approval** — Meta monitors live templates through quality signals: block rates, report rates, and engagement patterns. A Utility template that functions as Marketing will be flagged through quality monitoring even if it passed the initial review. Consequences include the template being paused, reduced throughput on your phone number, and in repeated cases, account-level restrictions.
**Cost is not a valid reason to miscategorize.** The Meta per-message pricing difference between Marketing and Utility is real (Galantis credits are flat, so this difference only affects your Meta invoice), but the cost of a quality incident — reduced throughput, template suspension, or phone number restriction — significantly outweighs any short-term savings from incorrect categorization.
## Decision guide
When categorizing a template, ask one question:
> Would the customer benefit from receiving this message even if they were not being asked to buy something?
If yes — the message is informational and Utility is likely correct. An order confirmation, shipping update, or appointment reminder serves the customer's needs independent of any purchase intent.
If no — the message is promotional and Marketing is the correct category. A discount offer, product launch announcement, or re-engagement message serves your business's goals, not a pre-existing customer need.
If the message contains both informational and promotional content, Marketing is the correct category. The presence of promotional intent takes precedence.
## Related guides
* [Creating Templates](./creating-templates) — How to set the category when building a template
* [Template Quality](./template-quality) — How category compliance affects quality rating
* [Campaigns — Campaign Types](/whatsapp/campaigns/campaign-types) — How template category determines campaign type
* [Compliance — Quality & Deliverability](/whatsapp/compliance/quality-deliverability) — Phone number quality consequences of miscategorization
# Template Formats
Source: https://docs.digifist.com/galantis/whatsapp/templates/template-formats
The five WhatsApp template formats in Galantis — from standard rich cards to single and multi-product messages and whole catalog browsing.
Template format determines the visual structure and interactive capabilities of a WhatsApp message. Galantis supports five formats — each with a distinct component structure, a specific use case, and different catalog requirements. The format you choose is set at template creation time and determines how the message renders in the customer's WhatsApp client.
Standard campaigns use rich card formats. Product-focused campaigns use catalog-based formats that require a synced Meta Catalog. Choosing the right format depends on what you are promoting and whether you have catalog infrastructure in place.
## What this covers
* All five template formats with their component structures
* When to use each format
* Catalog requirements per format
* A format selection guide
## Formats
**`SINGLE_RICH_CARD`** — A single promotional card combining header, body, footer, and buttons into one visual unit.
**Component structure:**
| Component | Required | Notes |
| --------- | -------- | -------------------------------- |
| Header | Yes | Text with optional variable |
| Body | Yes | Rich text with dynamic variables |
| Footer | Optional | Static short text |
| Buttons | Optional | Up to 3 buttons |
**Use for:** Single-focus promotional messages where one clear call to action drives the customer forward — a product spotlight, a limited-time offer, a discount code delivery, or an event announcement.
**Meta Catalog required:** No
**Best practices:**
* Keep the header text short — it is a label, not a sentence
* Use one primary URL button for the main CTA and a `COPY_CODE` button if a discount code is included
* Avoid stacking three buttons unless all three represent genuinely distinct actions the customer would choose between
Single Rich Card is the most versatile format and the right starting point for most first templates. It works for promotional and utility purposes, requires no catalog infrastructure, and renders cleanly across all WhatsApp client versions.
**`MULTI_RICH_CARD`** — A horizontally swipeable carousel of multiple individual cards, each with its own image, body text, and buttons.
**Component structure:**
| Component | Required | Notes |
| -------------- | -------- | -------------------------------------------------- |
| Body | Yes | Carousel-level introductory text |
| Carousel cards | Yes | Multiple cards, each with image, body, and buttons |
Each carousel card contains:
* Image (required per card)
* Body text (required per card)
* Buttons (optional per card)
**Use for:** Showcasing multiple products, offers, or content items in a single message where the customer swipes through and selects what interests them. More engaging than sending multiple sequential messages, and less overwhelming than a product list.
**Meta Catalog required:** No — carousel card content is defined at template creation time. Content is fixed in the template and not pulled from a live catalog sync.
**Best practices:**
* Keep card count to what is genuinely useful — a 3–5 card carousel outperforms a 10-card one because customers rarely swipe past the first few
* Use consistent image dimensions across all cards for a clean visual presentation
* Each card should have a distinct CTA — avoid repeating the same button label across all cards
Because Multi Rich Card content is fixed at template creation, it is less suitable for products with frequently changing prices or availability. For dynamic product showcasing, consider Single Product Message or Multi-Product Message formats that pull live catalog data.
**`SINGLE_PRODUCT_MESSAGE` (SPM)** — Showcases one specific product from your Meta Catalog, with variants, pricing, and a native WhatsApp commerce buy interface.
**Component structure:**
| Component | Required | Notes |
| ---------------- | -------- | ------------------------------------------ |
| Header | Yes | `PRODUCT` type — pulled from catalog |
| Body | Yes | Supporting text with dynamic variables |
| Footer | Optional | Static text |
| Buttons | Optional | Action buttons |
| Product sections | Yes | Product and variant data from Meta Catalog |
**Use for:** Targeted product promotions where a specific item is the focus — a best-seller highlight, a personalized recommendation based on purchase history, a back-in-stock broadcast for a specific product, or a high-AOV item promotion.
**Meta Catalog required:** Yes — the product displayed is pulled from your synced Meta Catalog. The catalog must be connected and the referenced product must have `SYNCED` status before this template can be used in a campaign or automation.
**Best practices:**
* Choose products with strong imagery — the catalog product photo is the primary visual element
* Use the body text to add context that the product card alone does not provide (urgency, social proof, personalization)
* Verify the product's `SYNCED` status in the Catalog module before activating any campaign or automation that uses this template
If the product referenced in an SPM template loses its `SYNCED` status in the Meta Catalog — due to a sync error, image format issue, or catalog disconnection — messages using this template will fail for all recipients until the sync issue is resolved.
**`MULTI_PRODUCT_MESSAGE` (MPM)** — Displays up to 30 products from your Meta Catalog in a scrollable list, organized into sections.
**Component structure:**
| Component | Required | Notes |
| ---------------- | -------- | ----------------------------------------------------------------- |
| Header | Yes | Text with optional variable |
| Body | Yes | Introductory message text |
| Footer | Optional | Static text |
| Buttons | Optional | Action buttons |
| Product sections | Yes | Multiple product entries from Meta Catalog, grouped into sections |
**Use for:** Collection-based campaigns, curated product selections, and "shop the look" or "complete the set" messaging where the goal is to give the customer a browsable set of options rather than focus on a single item. Useful for promoting a new collection launch or a seasonal edit.
**Meta Catalog required:** Yes — all products displayed must be present in your synced Meta Catalog with `SYNCED` status. Products with `PENDING` or `FAILED` status cannot be included.
**Best practices:**
* Organize products into meaningful sections (e.g., "New Arrivals", "Top Sellers", "Under \$50") — sections add context and make the list easier to browse
* Limit the total product count to what a customer would realistically browse — 8–15 well-chosen products outperforms 30 indiscriminately selected ones
* Use the body text to frame the selection: "Here are this season's top picks" gives the customer a reason to engage with the list
**`WHOLE_CATALOG`** — A message with a catalog browse button that opens your entire WhatsApp catalog for the customer to browse freely.
**Component structure:**
| Component | Required | Notes |
| -------------- | -------- | ------------------------------------------ |
| Body | Yes | Introductory message text |
| Footer | Optional | Static text |
| CATALOG button | Yes | Opens the full catalog browser in WhatsApp |
**Use for:** High-intent audiences who are likely to browse broadly — frequent purchasers, VIP customers, or customers who have visited your store multiple times without converting. Also the most practical format for stores with large catalogs where pre-selecting products for MPM would be impractical.
**Meta Catalog required:** Yes — your entire catalog must be synced and connected to Meta. Product availability and pricing in the catalog browser reflects the current state of your Meta Catalog sync.
**Best practices:**
* Reserve Whole Catalog sends for audiences with demonstrated browse intent — sending it to cold or low-intent audiences typically underperforms compared to SPM or MPM with curated selections
* Use the body text to prompt browsing with a clear reason: "We just launched 50 new styles — explore them all" is more effective than a generic "Browse our catalog"
* Ensure your Meta Catalog is fully synced and up to date before sending — a Whole Catalog message that opens a catalog with missing or outdated products creates a poor experience
## Format selection guide
| Format | Catalog required | Products shown | Best for |
| ------------------------ | ---------------- | ---------------------------- | ------------------------------------------------ |
| `SINGLE_RICH_CARD` | No | 0 — image or text only | Single-focus promotions, most standard campaigns |
| `MULTI_RICH_CARD` | No | Multiple (fixed in template) | Multi-offer showcases, content carousels |
| `SINGLE_PRODUCT_MESSAGE` | Yes | 1 specific product | Targeted product promotions, personalized picks |
| `MULTI_PRODUCT_MESSAGE` | Yes | Up to 30 products | Collection sends, curated product selections |
| `WHOLE_CATALOG` | Yes | Full catalog | Browse-driven sends for high-intent audiences |
## Catalog requirements for product formats
SPM, MPM, and Whole Catalog formats all require:
1. A Meta Catalog connected to your Galantis workspace — go to **Catalog → Meta Sync**
2. Products with `SYNCED` status — check **Catalog → \[Product]** for sync status per item
3. Product images meeting Meta's format requirements — JPEG or PNG, minimum 500×500px
See [Catalog](/whatsapp/catalog/index) for the full catalog setup and sync reference.
## Related guides
* [Template Categories](./template-categories) — Category selection before choosing a format
* [Creating Templates](./creating-templates) — Building template components in the template builder
* [Catalog — Meta Catalog](/whatsapp/catalog/meta-catalog) — Connecting Meta Catalog for product formats
* [Campaigns — Message Composition](/whatsapp/campaigns/message-composition) — How formats map to campaign message types
# Template Quality
Source: https://docs.digifist.com/galantis/whatsapp/templates/template-quality
How Meta evaluates template quality after approval, what signals affect it, and how to keep your templates healthy.
Template approval is not the end of Meta's evaluation — it is the beginning. Once a template is live and sending, Meta monitors how customers respond to it. Block rates, report rates, delivery failures, and category compliance signals all feed into a quality assessment that can affect your template's status and your phone number's throughput capacity.
A template that passes approval but receives poor engagement signals can be paused by Meta without warning, removing it from active use in campaigns and automations mid-flight.
## What this covers
* The quality signals Meta monitors for live templates
* What happens when template quality degrades
* How template quality connects to phone number quality
* Optimization practices for keeping templates healthy
## Quality signals Meta monitors
Meta does not publish the exact formula used to calculate template quality, but the primary signals are well-documented:
**Customer block and report rates** — When a customer blocks your WhatsApp number or reports a message as spam after receiving a template, it is a strong negative quality signal. A single block is not significant; a pattern of blocks across recipients of the same template indicates the message is unwanted.
**Delivery failure rates** — Templates with high delivery failure rates — messages sent but not delivered — accumulate negative signals. This can result from targeting inactive or invalid numbers, but also from template-level issues that affect deliverability.
**Template category compliance** — Meta reviews live templates against their declared category on an ongoing basis. A Utility template with embedded promotional content that passed initial review may be flagged through quality monitoring when actual send patterns reveal its marketing nature.
**Message frequency vs engagement** — Sending a template to the same customers repeatedly in a short period without engagement signals — no reads, no replies, no clicks — indicates the message is not valued by recipients.
## What happens when quality degrades
Template quality degradation follows a progression that can affect both the template and the phone number it sends from:
| Quality State | Consequence |
| ---------------------- | ---------------------------------------------------------------------------------------------------------- |
| **High quality** | No restrictions — full throughput, normal delivery |
| **Medium quality** | Warning state — no immediate action but continued degradation will escalate |
| **Low quality** | Template may be paused by Meta — messages using it fail until quality recovers or the template is revised |
| **Paused / Suspended** | Template cannot send — active campaigns fail and automation Action Nodes fail for customers who reach them |
When a template is paused by Meta, active automations using it continue to execute — but the Action Node for the affected template returns `FAILED` status for every customer who reaches it. The automation does not stop; the individual message sends fail silently until the template is restored or replaced.
**Phone number impact** — Template quality issues aggregate at the phone number level. Multiple templates with poor quality signals simultaneously will degrade the phone number's overall quality rating more rapidly than a single template issue. See [Compliance — Quality & Deliverability](/whatsapp/compliance/quality-deliverability) for how phone number quality affects throughput.
## Monitoring template quality
Template quality metrics in Galantis are tracked through message-level delivery data — `SENT`, `DELIVERED`, `READ`, and `FAILED` statuses per message, aggregated per template. This gives an indirect view of quality health:
* **Read rate relative to delivered rate** — a low read rate suggests customers are receiving the message but not opening it, which may correlate with high block rates
* **Failed rate** — persistent delivery failures on a specific template warrant investigation
* **Trend over time** — a declining read rate across sends of the same template is a leading indicator of quality degradation before Meta flags it formally
For phone-number-level quality data and formal template status information from Meta, refer to your WhatsApp Business Account settings in Meta Business Manager directly. Galantis does not currently surface Meta's internal quality score for individual templates within the dashboard.
## Optimization practices
**Match category to content precisely.** The single most effective quality practice is accurate categorization. A Marketing template sent to opted-in customers who expected it has fundamentally better quality signal characteristics than a Utility template used for promotional content — because the recipients of the latter are more likely to block or report.
**Personalize with variables.** Templates that address the customer by name and reference relevant data (their order, their browsed product, their location) generate better engagement signals than generic broadcast copy. Use `customer.first_name` and order variables wherever the template context supports it.
**Respect frequency caps.** A customer who receives the same template — or different templates from the same number — multiple times in a short period is more likely to block. Configure automation frequency caps to prevent over-messaging, and space campaign sends to avoid hitting the same audience repeatedly within a short window.
**Honor opt-outs immediately.** Customers who replied STOP and are incorrectly messaged again are almost certain to block and report. Galantis enforces opt-out automatically, but manually imported contact lists should be reviewed carefully to ensure no `UNSUBSCRIBED` customers are included.
**Avoid spam-like language in Utility templates.** Phrases like "Limited time offer!", "Act now!", or "Exclusive deal!" in a Utility template are consistent quality flags during Meta's ongoing monitoring, even if they passed initial review. Keep Utility templates transactional in both structure and language.
**Retire poorly performing templates.** A template with consistently low read rates and high failure rates is better replaced than defended. Archive it, analyze what drove the poor performance, build a revised version, and submit the new template.
## What to do when a template is paused
1. Go to **Templates → \[Template Name] → Status** in Galantis to confirm the current status and any reason provided by Meta
2. Review the template content against Meta's current content policies — policies evolve and a template compliant at approval may conflict with a later policy update
3. Assess whether the quality signal cause is content-based (fix the template), audience-based (review who is being targeted), or frequency-based (adjust send cadence)
4. Make the necessary changes and resubmit
5. If the template is used in active automations, those automations will resume sending correctly once the template is restored to `APPROVED` status — no automation re-activation is required
## Related guides
* [Template Categories](./template-categories) — Category accuracy as the primary quality lever
* [Approval Lifecycle](./approval-lifecycle) — How template status changes when quality degrades
* [Compliance — Quality & Deliverability](/whatsapp/compliance/quality-deliverability) — How template quality aggregates to phone number quality
* [Support — Template Rejection](/whatsapp/support/troubleshooting/template-rejection) — Troubleshooting rejected and paused templates
# Variables & Localization
Source: https://docs.digifist.com/galantis/whatsapp/templates/variables-localization
Dynamic variable placeholders in WhatsApp templates — how they are defined, mapped, and managed across multiple languages in Galantis.
Variables make templates personal. Instead of a fixed message that reads identically for every recipient, variables allow a single approved template to address each customer by name, reference their order, or include their specific product — all within a Meta-approved structure. Localization ensures the same variable-driven personalization is available across every language your customers speak.
## What this covers
* Variable placeholder syntax and how placeholders are defined
* The `template_variables_mapping` structure
* Available data sources for variable values
* Example values and why they are required
* Localization — one template per language
* Managing multiple language versions
## Variable placeholder syntax
Variables in WhatsApp templates use positional syntax: `{{1}}`, `{{2}}`, `{{3}}`, and so on. Each number refers to the position of the variable in the template — `{{1}}` is the first variable, `{{2}}` is the second, regardless of where in the body text they appear.
**Rules for placeholders:**
* Positions must be sequential starting from `{{1}}` — skipping a number (e.g., using `{{1}}` and `{{3}}` without `{{2}}`) causes submission to fail
* Variables can appear in the body text and in the text header — not in the footer, and not as the entire content of a button label
* A URL button supports one variable in the URL path: `https://yourstore.com/checkout/{{1}}`
* There is no enforced maximum number of variables, but templates with many variables become harder to maintain and map correctly
## Variable mapping
When a template is selected for use in a campaign or automation, each placeholder must be mapped to a data source. Galantis stores this mapping as `template_variables_mapping`:
```json theme={null}
[
{ "initialValue": "{{1}}", "selectedValue": "customer.first_name" },
{ "initialValue": "{{2}}", "selectedValue": "order.total_price" },
{ "initialValue": "{{3}}", "selectedValue": "static:SUMMER20" }
]
```
Each placeholder is assigned either a dynamic field from customer or order data, or a static text value entered at configuration time.
## Available variable data sources
| Field | Description |
| --------------------- | ---------------------------------- |
| `customer.first_name` | Customer's first name from Shopify |
| `customer.last_name` | Customer's last name from Shopify |
| `customer.email` | Customer's email address |
| `customer.phone` | Customer's phone number |
`customer.first_name` is the most used variable across all template types. Opening with the customer's name meaningfully improves engagement compared to a generic greeting — and costs nothing beyond the variable slot.
Avoid mapping `customer.email` or `customer.phone` to visible body text variables. Reflecting a customer's own contact details back to them in a promotional message is unexpected and can feel surveillance-like. These fields are available for edge-case technical use, not general personalization.
| Field | Description |
| -------------------- | -------------------------------------- |
| `order.order_number` | Shopify order number |
| `order.total_price` | Order total value |
| `order.product_name` | Name of the first product in the order |
Order variables are most appropriate for post-purchase templates — cross-sell sequences, shipping confirmations, or review requests — where the customer expects their recent order to be referenced.
**Store name** — The name of your Shopify store. Useful for brand reinforcement in templates sent from a number the customer may not immediately recognize.
**Custom static text** — A fixed string entered directly at mapping configuration time. The same value is sent to all recipients for that placeholder — it does not vary per customer.
Use static text for:
* Discount codes that apply to all recipients (`SUMMER20`, `FREESHIP`)
* Fixed URLs for specific landing pages
* Consistent offer terms or product names used across a campaign
Static text is the correct choice any time a variable slot needs a value that does not come from customer data.
## Example values — why they are required
Meta requires that every variable placeholder in a submitted template include an example value — a concrete sample of what that variable will contain at send time. Example values are reviewed by Meta as part of the approval process to confirm that the variable content is appropriate for the declared template category.
**What to provide:**
* `{{1}}` mapped to `customer.first_name` → example: `Sarah`
* `{{2}}` mapped to `order.total_price` → example: `$89.00`
* `{{3}}` mapped to a discount code → example: `SUMMER20`
**What not to provide:**
* Generic placeholders like `[name]` or `[value]` — these do not satisfy the example requirement
* Empty strings — a blank example value causes rejection
* Misleading examples that do not represent the actual variable content
Submitting a template with missing or empty variable examples is one of the most common rejection causes. Fill in realistic, representative examples for every `{{N}}` placeholder before clicking Submit.
## Localization
WhatsApp templates are language-specific. Each template is tied to a single `language` code — for example, `en` for English, `es` for Spanish, `pt_BR` for Brazilian Portuguese. A template approved for `en` cannot be sent to a customer whose preferred language is `es` — a separate template record must exist for each language.
**Creating templates per language:**
1. Build the template content in one language and submit it for approval
2. Create a new template with the same name and structure, set the language to the target language, translate the content, and submit that template separately
3. Repeat for each additional language
Each language version is a fully independent template record with its own approval status, quality metrics, and usage history. An `APPROVED` status in one language does not transfer to another — each must be reviewed and approved by Meta independently.
**Routing customers to language-appropriate templates:**
In automations, use a `CUSTOMER_COUNTRY` or `CUSTOMER_LANGUAGE` condition node to branch customers to the Action Node configured with the appropriate language template. See [Automations — Conditions](/whatsapp/automations/conditions).
In campaigns, create separate campaigns per language and select the corresponding language's template and audience segment for each send.
## Managing variable mapping across language versions
Variable positions must be consistent across language versions of the same template. If `{{1}}` maps to `customer.first_name` in the English version, it must also map to `customer.first_name` in the Spanish version — not to a different field. Inconsistent variable positions across language versions cause confusion when configuring automation Action Nodes that may serve multiple markets.
Establish variable position conventions before creating your first template and apply them consistently across all language versions.
## Best practices
* **Use `{{1}}` for `customer.first_name` consistently across all templates.** Making first name the first variable creates a predictable convention that simplifies mapping configuration across many templates.
* **Keep the variable count low.** Each variable is a mapping task at campaign and automation configuration time. Templates with 5+ variables are harder to configure correctly and more likely to produce awkward messages if any mapping is misconfigured.
* **Write example values that reflect real data.** Use a realistic name, a realistic order value, and a real discount code format. Example values that look nothing like actual customer data can contribute to a misleading category impression during Meta's review.
* **Name language variants consistently.** A naming pattern like `welcome_en`, `welcome_es`, `welcome_pt_BR` makes it easy to identify and select the correct language version when configuring campaigns and automations.
* **Audit variable mappings when updating templates.** If a template is edited and resubmitted with a different variable structure, review and update all campaign and automation configurations that reference it.
## Related guides
* [Creating Templates](./creating-templates) — Where variable placeholders are defined in the template builder
* [Campaigns — Personalization](/whatsapp/campaigns/personalization) — Variable mapping configuration in campaigns
* [Automations — Actions](/whatsapp/automations/actions) — Variable mapping in automation Action Nodes
* [Automations — Conditions](/whatsapp/automations/conditions) — CUSTOMER\_COUNTRY condition for language-based routing
# Blog Posts
Source: https://docs.digifist.com/themes/everest/blog-posts
Configure Everest's article template, content blocks, metadata, sharing, and comment-aware behavior.
Blog Posts control the article detail template in Everest. The template is powered by the `main-article` section, which renders the article through reorderable blocks for tags, metadata, heading, share actions, featured image, and rich article content.
## What this template controls
* The block order used to present article content
* Back-to-blog navigation behavior
* Article metadata such as author and publish date
* Tag links, sharing, featured image, and article content output
* Shared width, color, and spacing settings for the article wrapper
* Comment form and comment list visibility when blog comments are enabled in Shopify
## Template structure
This template uses the following main section and default blocks:
* **Article**
* **Tags**
* **Info**
* **Heading**
* **Share**
* **Featured Image**
* **Content**
## Getting started
In Theme Customizer, open a blog post resource so Everest loads the article template with real content.
Review the article blocks first because their order defines how readers move through the post.
Choose the article width before adjusting styling so text-heavy content remains comfortable to scan.
Decide whether back navigation, post details, tags, and comments support the way your blog is meant to be read.
## Main settings
### Article settings
Adds a link below the article content that sends visitors back to the parent blog.
**Default:** Enabled
### Layout
Controls the reading width of the article container.
**Available options:** `XXS`, `Page`, `Fluid`\
**Default:** `XXS`
`XXS` keeps long-form reading narrower and is the default Everest article presentation.
Sets the visual treatment for the article section wrapper.
Control the vertical space around the article section.
**Available options:** `No`, `S`, `M`, `L`, `XL`
## Default blocks
Renders article tags as linked buttons that take visitors to the tagged blog archive.
Displays author, publish date, or both depending on block settings.
Outputs the article title. Everest promotes it to `h1` when the section appears first on the page.
Adds the shared social sharing control for the current article URL.
Displays the article image when one exists.
The block also controls the image aspect ratio used for the article hero.
Renders the main blog post body from Shopify's article content field.
## Comment behavior
Everest only shows the comment list and comment form when comments are enabled on the parent Shopify blog. When comments are moderated, the template also shows moderation-aware success messaging after form submission.
## Best practices
* Keep article width narrow enough for comfortable reading, especially on text-heavy posts.
* Use metadata and tag blocks consistently so archive pages and article pages feel connected.
* Review featured image ratios with real article imagery before publishing layout changes.
* If comments are enabled, test the full submission flow so validation and moderation messages are clear.
## Related guides
* [Blogs](/themes/everest/blogs)
* [Theme Settings: Typography](/themes/everest/theme-settings/typography)
* [Theme Settings: Colors](/themes/everest/theme-settings/colors)
# Blogs
Source: https://docs.digifist.com/themes/everest/blogs
Configure Everest's blog listing template, article cards, tag filters, and grid layout.
Blogs control the main article listing experience in Everest. The template is driven by the `main-blog` section, which combines a selected blog source, optional tag filters, pagination, and reusable article card blocks into one customizable listing page.
## What this template controls
* Which Shopify blog the page displays
* Tag-based article filtering on desktop and mobile
* Articles per page and pagination behavior
* Article grid columns on desktop and mobile
* Shared width, color, spacing, and border settings
* The default Section Header and Article Card block structure used inside the template
## Template structure
This template uses the following main section and related blocks by default:
* **Blog**
* **Section Header** block
* **Article Card** block with tags, heading, and article details sub-blocks
## Getting started
In Theme Customizer, open a blog resource or assign the blog template before editing it.
Set the correct Shopify blog first so filtering, article count, and pagination reflect the right content set.
Adjust articles per page and column count together so the listing stays readable across desktop and mobile.
If tag filters are enabled, review both the desktop button list and the mobile dropdown flow.
## Main settings
### Content and navigation
Selects which Shopify blog this template should render.
If no blog is chosen in the section, Everest falls back to the current blog resource.
Shows article tag filters above the article grid.
Everest renders the filters as a button row on desktop and as a dropdown menu on mobile.
Controls how many articles appear before pagination.
**Default:** `12`
### Layout
Controls the article grid density on larger screens.
**Range:** `1` to `6`\
**Default:** `3`
Controls how many article cards display per row on smaller screens.
**Available options:** `1`, `2`\
**Default:** `2`
### Common settings
Sets the maximum layout width for the blog listing container.
**Available options:** `Page`, `Fluid`, `Full`\
**Default:** `Page`
Applies the main color treatment for the template wrapper and article listing area.
Control the vertical spacing around the blog listing section.
**Available options:** `No`, `S`, `M`, `L`, `XL`
Adds a border treatment to the blog section wrapper.
**Available options:** `None`, `Top`, `Bottom`, `Both`
## Block behavior
The default article card structure is defined inside the template JSON. Everest uses:
* **Tags** to show article tags when available
* **Heading** for the article title
* **Article Details** for author and publish date
These blocks work together inside the shared article card component, so card presentation is affected by both the template and Everest's reusable card styling.
## Best practices
* Choose article counts and column settings together so pagination feels intentional instead of crowded.
* Keep tag filtering enabled only when the selected blog has a clear tag structure.
* Review mobile filtering carefully because Everest switches from visible buttons to a dropdown pattern.
* Use consistent featured image ratios across posts so the grid looks balanced.
## Related guides
* [Blog Posts](/themes/everest/blog-posts)
* [Theme Settings: Cards](/themes/everest/theme-settings/cards)
* [Theme Settings: Typography](/themes/everest/theme-settings/typography)
# Collection Landing Page
Source: https://docs.digifist.com/themes/everest/collections/collection-landing-page
Configure Everest's alternate collection landing template with banner, sidebar navigation, and featured product sections.
The Collection Landing Page template controls the main structure used for this page type in Everest. It combines template-specific sections with reusable content blocks, which means most storefront behavior can be adjusted in the Theme Customizer without editing theme code.
## What this template controls
* The template section order and the supporting sections included by default
## Template structure
This template uses the following main sections or related theme building blocks by default:
* **Banner**
* **Sidebar Menu**
* **Rich Text**
* **Featured Products**
## Getting started
Open the relevant page type or assign the template to a resource before customizing it.
Start with the primary content section so layout, filtering, gallery, or page-level behavior is defined before refining supporting content.
Review any banners, content sections, or utility sections included in the template so the full page works together as a set.
## Supporting sections
This template relies on reusable sections working together rather than on a single main schema. Review the linked section guides below when you want to fine-tune each part in more depth.
## Best practices
* Test this template with real content volume so headings, cards, and filters behave as expected.
* Review supporting sections together because template defaults often work as a coordinated set.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Sidebar Menu](/themes/everest/sections/sidebar-menu)
* [Banner](/themes/everest/sections/banner)
# Collection List Page
Source: https://docs.digifist.com/themes/everest/collections/collection-list-page
Configure Everest's collection list template and its collection card layout options.
The Collection List Page template controls the main structure used for this page type in Everest. It combines template-specific sections with reusable content blocks, which means most storefront behavior can be adjusted in the Theme Customizer without editing theme code.
## What this template controls
* Layout structure, width, alignment, and spacing
* Product, collection, or cart-related storefront behavior
* Search, filter, and sorting behavior for product discovery
* Color schemes, contrast, and shared visual styling
* The template section order and the supporting sections included by default
## Template structure
This template uses the following main sections or related theme building blocks by default:
* **List Collections**
## Getting started
Open the relevant page type or assign the template to a resource before customizing it.
Start with the primary content section so layout, filtering, gallery, or page-level behavior is defined before refining supporting content.
Review any banners, content sections, or utility sections included in the template so the full page works together as a set.
## Main settings
### Settings
Select the collection source used by **collections**.
Choose how **Sort by** behaves in the section.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Available options:** Alphabetically, A-Z, Alphabetically, Z-A, Date, new to old, Date, old to new, Product count, high to low, Product count, low to high.
**Default:** `title-ascending`
Adjust **Number of columns on desktop** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `1` to `6` **Default:** `3`
Choose how **Number of columns on mobile** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** 1, 2.
**Default:** `2`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Test this template with real content volume so headings, cards, and filters behave as expected.
* Review supporting sections together because template defaults often work as a coordinated set.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
# Collection Page
Source: https://docs.digifist.com/themes/everest/collections/collection-page
Configure Everest's collection template, product grid, filters, sorting, and supporting merchandising sections.
The Collection Page template controls the main structure used for this page type in Everest. It combines template-specific sections with reusable content blocks, which means most storefront behavior can be adjusted in the Theme Customizer without editing theme code.
## What this template controls
* Layout structure, width, alignment, and spacing
* Product, collection, or cart-related storefront behavior
* Search, filter, and sorting behavior for product discovery
* Color schemes, contrast, and shared visual styling
* The template section order and the supporting sections included by default
## Template structure
This template uses the following main sections or related theme building blocks by default:
* **Callout Banner**
* **Collection**
* **Rich Text**
* **Recently Viewed Products**
## Getting started
Open the relevant page type or assign the template to a resource before customizing it.
Start with the primary content section so layout, filtering, gallery, or page-level behavior is defined before refining supporting content.
Review any banners, content sections, or utility sections included in the template so the full page works together as a set.
## Main settings
### Settings
Adjust **Products per page** with a slider-based control.
**Range:** `8` to `50` **Default:** `24`
Choose how **Number of columns** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** 3, 4.
**Default:** `4`
### Filtering and sorting
Enable or disable **Enable filtering**.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Default:** `enabled`
Customize filters with the Search & Discovery app. [Learn more](https://help.shopify.com/manual/online-store/search-and-discovery/filters)
Choose how **Desktop filter layout** behaves in the section.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Available options:** Vertical, Drawer.
**Default:** `vertical`
Drawer is the default mobile layout.
Enable or disable **Enable sorting**.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Default:** `enabled`
Select the color scheme used for **color for active filters**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-6`
### Mobile layout
Choose how **Number of columns on mobile** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** 1, 2.
**Default:** `2`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `full`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Test this template with real content volume so headings, cards, and filters behave as expected.
* Review supporting sections together because template defaults often work as a coordinated set.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Recently Viewed Products](/themes/everest/sections/recently-viewed-products)
# Search
Source: https://docs.digifist.com/themes/everest/collections/search
Configure Everest's search results template, grid behavior, filters, sorting, and search-specific cards.
The Search template controls the main structure used for this page type in Everest. It combines template-specific sections with reusable content blocks, which means most storefront behavior can be adjusted in the Theme Customizer without editing theme code.
## What this template controls
* Layout structure, width, alignment, and spacing
* Product, collection, or cart-related storefront behavior
* Search, filter, and sorting behavior for product discovery
* Color schemes, contrast, and shared visual styling
* The template section order and the supporting sections included by default
## Template structure
This template uses the following main sections or related theme building blocks by default:
* **Search**
* **Predictive Search**
## Getting started
Open the relevant page type or assign the template to a resource before customizing it.
Start with the primary content section so layout, filtering, gallery, or page-level behavior is defined before refining supporting content.
Review any banners, content sections, or utility sections included in the template so the full page works together as a set.
## Main settings
### Settings
Select the color scheme used for **color for header**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-4`
Choose how **Header layout** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Page, Full.
**Default:** `full`
Adjust **Products per page** with a slider-based control.
**Range:** `8` to `50` **Default:** `24`
### Layout
Adjust **Number of columns on desktop** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `1` to `6` **Default:** `3`
Choose how **Number of columns on mobile** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** 1, 2.
**Default:** `2`
### Filtering and sorting
Enable or disable **Enable filtering**.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Default:** `enabled`
Customize filters with the Search & Discovery app. [Learn more](https://help.shopify.com/manual/online-store/search-and-discovery/filters)
Choose how **Desktop filter layout** behaves in the section.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Available options:** Vertical, Drawer.
**Default:** `vertical`
Drawer is the default mobile layout.
Enable or disable **Enable sorting**.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Default:** `enabled`
Select the color scheme used for **color for active filters**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-6`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `4`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `4`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Test this template with real content volume so headings, cards, and filters behave as expected.
* Review supporting sections together because template defaults often work as a coordinated set.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Predictive Search](/themes/everest/sections/predictive-search)
# Footer
Source: https://docs.digifist.com/themes/everest/footer/footer
Configure Everest's footer columns, utility content, localization controls, and footer block types.
The footer controls the global bottom area of the Everest storefront. It combines shared footer settings with reusable blocks, so the main decisions are about information density, utility links, branding, localization, payment methods, and overall footer styling.
Everest's footer also depends on global brand and social settings. That means logo, brand text, description, and social profile links can all affect the final footer output even when the section settings stay the same.
## What this section controls
* Footer column structure on desktop
* Copyright text and policy link output
* Follow on Shop, social icons, and localization selectors
* Payment icon visibility and custom payment icon names
* Footer color, width, spacing, and border treatment
* Link list and information block content
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
In the footer group, select **Footer** to review the global footer settings and blocks.
Start with columns, width, color scheme, and spacing so the footer layout feels balanced before you refine block content.
Finish by checking localization, payment icons, social output, and the content inside each footer block.
## Section settings
### Structure
Controls how many columns the footer grid uses on larger screens.
**Range:** `1` to `6`\
**Default:** `5`
Everest automatically adjusts the layout on smaller screens, so this setting matters most for desktop balance and content density.
Controls the copyright line shown in the bottom area of the footer.
The default text includes the `[year]` token, which Everest replaces with the current year automatically.
Displays links to the store policies available in Shopify, such as refund, privacy, shipping, or terms pages.
### Utility Features
Shows Shopify's **Follow on Shop** button when the store and sales channel support it.
Displays the shared social profile icons in the footer utility area.
The icons only appear when the related social links are filled in **Theme settings -> Social Media**.
Shows the country selector in the footer when Shopify Markets data includes more than one available country.
Shows the language selector in the footer when the store has more than one available language.
### Payment Methods
Displays the payment method icons in the footer utility area.
Lets you define the payment icons that Everest should render.
The default value includes common providers such as `master`, `visa`, `american_express`, `apple_pay`, `shopify_pay`, `diners_club`, `discover`, and `google_pay`.
Controls whether payment icons use their full color versions or a grayscale treatment.
### Styling
Controls the width of the footer container.
**Page** keeps the footer aligned to the standard content width.\
**Fluid** gives the footer a wider but still padded layout.\
**Full** stretches the footer edge to edge.
Controls the main footer background and text treatment.
Controls the color scheme used for footer content surfaces inside the main footer area.
Controls the spacing above the footer content area.
Controls the spacing below the footer content area.
Adds border styling to the footer wrapper.
**Available options:** None, Top, Bottom, Both.
## Block settings
### Link List
The **Link list** block creates an accordion-style footer menu with Shopify navigation links.
Controls the heading shown above the footer link list.
Sets the display size of the footer menu heading.
Selects the Shopify menu used for the footer link list.
Everest renders the chosen menu as a structured footer navigation group and collapses it into accordion behavior where needed.
### Information
The **Information** block is the flexible content block in Everest's footer. It can combine editorial text, images, newsletter signup, and shared brand details inside a single column.
Controls how much width the information block takes relative to other footer blocks.
Controls the main heading shown inside the information block and its display size.
Adds supporting rich text content such as contact information, store details, or a short brand message.
Adds an optional image to the information block and controls its maximum display width.
Controls how the optional image aligns on larger screens.
Displays shared brand content from theme settings, including the logo or text logo, brand headline, and brand description.
This block reads from **Theme settings -> Brand**, so the visible output depends on your global brand setup.
Adds the footer newsletter signup form inside the information block.
## Important dependencies
Footer branding uses the global brand settings. Depending on the setup, Everest can show the uploaded logo, SVG logo, text logo, brand headline, and brand description.
Social icons only render when the related profile URLs are filled in the global social media settings.
Country and language selectors only appear when the store has multiple available countries or languages.
## Best practices
* Keep the footer information hierarchy clear by mixing one broader information block with smaller link columns.
* Review desktop and mobile layouts together when you change the column count or block mix.
* Use shared brand and social settings before troubleshooting missing footer content.
* Keep footer menus concise so the lower part of the storefront stays easy to scan.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Brand Settings](/themes/everest/theme-settings/brand)
* [Social Media Settings](/themes/everest/theme-settings/social-media)
# Announcement Bar
Source: https://docs.digifist.com/themes/everest/header/announcement-bar
Configure Everest's slim header utility bar for rotating announcements, a secondary link menu, and social icons.
The announcement bar controls the compact utility strip above Everest's main header. It is designed for short promotional messages, a simple secondary menu, and optional social icons without adding too much visual weight to the top of the store.
This implementation is intentionally lighter than some other themes. Everest does not add countdowns, standalone CTA blocks, or a separate localization block here, so the main decisions are about message rotation, device visibility, width, and supporting utility content.
## What this section controls
* The overall width and color treatment of the announcement bar
* Rotating message behavior through the announcements slider block
* Individual announcement slides inside that slider
* A simple top-level utility menu
* Social icon output tied to global theme settings
* Desktop and mobile visibility for each top-level block
## How Everest announcement bar works
The section itself only controls the outer wrapper. The actual content comes from three supported block types:
* **Announcements** for the rotating message area
* **Menu** for a simple inline link list
* **Social** for social media icons
In the default Everest header group preset, the announcements slider appears first, followed by a desktop-only menu and desktop-only social icons.
Everest always uses the announcements slider structure for message content. Disabling autoplay stops automatic rotation, but the message area still uses the same slider-based block.
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
In the header group, select **Announcement bar** to access the section settings and block list.
Choose the section width and color scheme before adjusting content blocks so you can judge spacing and contrast more accurately.
Configure the announcements slider first, then add or refine the menu and social blocks based on how much utility content you want in the bar.
## Section settings
Controls the maximum width of the inner announcement bar container.
**Page** keeps the bar aligned to Everest's standard page width.
**Fluid** gives the content a wider container while still respecting page gutters.
**Full** stretches the bar edge to edge.
The schema default is **Full**, while the default header-group preset uses **Page**.
Controls the overall background and foreground treatment of the announcement bar wrapper.
Use this to keep the bar visually connected to the header or intentionally separate it as its own utility layer.
## Block settings
This is the parent slider block for all rotating messages in the bar.
Controls how quickly the slider rotates through messages.
**Range:** `0` to `10` seconds
**0 seconds** disables automatic rotation.
In Everest's swiper implementation, autoplay only activates when there is more than one announcement slide.
Controls where the announcements slider appears.
**Desktop** shows the block only on larger screens.
**Mobile** shows the block only on smaller screens.
**Both** shows the block across devices.
In Everest, device visibility also affects section spacing because the announcement bar CSS adjusts padding based on which block visibility classes are present.
Each nested **Announcement** block becomes one slide inside the parent announcements slider.
Controls the message content for an individual slide.
The field uses rich text, so you can add light formatting when needed, but this block works best with short, easily scannable copy.
Displays an icon before the message text on that specific slide.
This is useful for adding a small visual cue to shipping updates, promotions, or store notices.
Accepts raw SVG markup for the announcement icon.
If **Show icon** is disabled, this field has no visible effect.
Everest renders this field directly as SVG markup. Invalid, oversized, or inconsistent SVG code can affect alignment and visual quality.
The menu block adds a simple inline utility navigation area to the announcement bar.
Selects the Shopify menu used for the announcement bar link list.
Everest renders only the top-level links from the selected menu in this block.
Controls whether the utility menu appears on desktop, mobile, or both.
This block works best with short menus that contain only a few high-priority links.
This is not a dropdown navigation block. It renders a flat inline list of top-level links only.
The social block outputs social media icons using Everest's shared social-media snippet.
The block does not store platform URLs directly.
Instead, it reads the global social link fields from **Theme settings**, such as Instagram, Facebook, YouTube, TikTok, X, LinkedIn, Snapchat, Pinterest, and Vimeo.
Controls where the social icon list appears.
Use desktop-only visibility when the bar already feels dense on mobile.
If the related global social link fields are blank, this block may show little or no visible output.
## Important behavior and limitations
The announcement bar wrapper still contains a conditional reference to localization-related classes, but the current section schema does not expose country or language selector settings here.
In practice, Everest's announcement bar should be documented as a message, menu, and social utility bar rather than a localization bar.
Everest's global header script measures the visible announcement bar height and stores CSS variables used by desktop menu overlays.
Taller announcement bar content can therefore influence menu positioning and the available height for large desktop navigation panels.
On smaller screens, the announcement bar container switches to a column layout and centers announcement slide content.
This is another reason to keep message text brief and utility content limited.
## Best practices
Everest's announcement bar is strongest when each slide is brief, scannable, and easy to read in a single line.
Use the menu block for a few supporting links such as shipping, help, or store policies rather than a full navigation set.
Rotation helps when you have two or three important messages, but faster timing can reduce readability.
Add platform URLs in theme settings before relying on the social block, otherwise the bar may feel incomplete.
Start with the announcements block only, then add the menu or social block only if the bar still feels clean on both desktop and mobile.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Header
Source: https://docs.digifist.com/themes/everest/header/header
Configure Everest's primary navigation, desktop and mobile menus, localization controls, and header utilities.
The header controls the primary navigation experience across your store. In Everest, it also acts as the connection point for search, customer account access, localization controls, extra utility icons, and mega menu promotions.
Several visible header elements also depend on global theme settings such as your logo, search behavior, cart type, and social links. Once those dependencies are clear, the header becomes much easier to customize confidently.
## What this section controls
* Desktop header layout and menu placement
* Sticky header behavior
* Desktop dropdown or mega menu behavior
* Menu trigger mode for desktop navigation
* Country and language selectors
* Customer avatar display
* Two optional additional icon links
* Header width, colors, and border treatment
* Static mobile and slideout menu blocks
* Mega menu promotion blocks
## How Everest header works
The section renders three main zones:
* **Start area**: mobile menu trigger and search
* **Center area**: logo or text-based brand mark
* **End area**: localization, additional icons, account, app blocks, and cart
Desktop navigation can render as either a **dropdown menu** or a **mega menu**. Mobile navigation uses a dedicated drawer block, while desktop also includes a separate slideout menu block for an additional drawer-style navigation experience.
The header also reads several global theme settings, especially for logo, search, cart, and social links. Those controls are documented later on this page so you can tell which behavior belongs to the section and which comes from theme settings.
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
In the header group, select **Header** to access the main section settings.
Start with header layout, menu trigger, and desktop menu type so the main navigation structure is in place first.
Open the built-in mobile and slideout menu blocks, then configure promotion blocks only if you are using the mega menu layout.
## Layout options
Logo stays on the left and the main menu moves to a dedicated row below it.
This layout gives longer menus more room and creates a clearer separation between branding and navigation.
Logo stays centered while the navigation sits on its own row below.
This works well when brand presence should feel more prominent without compressing the menu into the top row.
Logo and desktop navigation share the same row.
This is the most compact layout and works best when your top-level navigation is short and easy to scan.
## Navigation settings
Select the main Shopify menu used by the header.
This menu drives the desktop dropdown or mega menu, acts as the default source for the mobile menu, and also becomes the practical source of truth for the main slideout navigation.
Choose how desktop menus open.
**Click** opens menus on click and closes them when visitors click outside the menu.
**Hover** opens menus on pointer hover and uses a short close delay to reduce flicker when moving across the menu boundary.
Choose the desktop navigation style.
**Dropdown** uses stacked disclosure menus and works well for simpler navigation trees.
**Mega** uses a full-width panel with grouped child links and can include promotion blocks tied to top-level menu items.
Controls the desktop top-level menu label size.
Available presets are **XS**, **S**, **M**, **L**, and **XL**.
Controls the width of desktop dropdown panels.
**Range:** `10rem` to `32rem`\
**Default:** `22.4rem`
This setting only appears when **Menu type** is set to **Dropdown**.
Controls how top-level menu items size horizontally.
**Auto** keeps the natural width of each item.
**Min content** shrinks items to their tightest content width, which can make long labels wrap more aggressively.
### Enable sticky header
Keeps the header attached to the top of the viewport while visitors move through the page.
In Everest's current implementation, sticky mode behaves as a scroll-aware header that hides while scrolling down and returns while scrolling up.
The section exposes sticky mode as a simple on/off control. The underlying code also supports internal sticky variants, but those modes are not available as separate section settings in the current schema.
## Localization and account
Displays the country selector in the header icon area when your store has more than one available country.
The selector uses Shopify Markets data and renders a searchable country list when enough countries are available.
In the current header implementation, the country selector is rendered only on desktop screens.
Displays the language selector in the header icon area when your store has more than one available language.
In the current header implementation, the language selector is also desktop-only.
Changes how the account icon behaves when Shopify customer accounts are enabled.
If enabled and the signed-in customer has an avatar, the avatar is shown. Otherwise the standard user icon is displayed.
## Additional icons
Turns on two optional desktop-only quick-link slots inside the header.
These work well for actions such as **Track order**, **Help center**, or **Store locator**.
Each icon slot supports:
* image icon
* optional SVG override
* text label
* destination link
If SVG mode is enabled and SVG code is provided, the SVG overrides the uploaded image.
The second icon slot uses the same structure as the first one.
Empty icon slots are skipped automatically, so you do not need to fill both.
Keep additional icons limited to one or two high-value actions. Too many icon links reduce the clarity of the header's main navigation.
## Design settings
Controls the header container width.
**Page** keeps the header aligned to the theme's standard content width.
**Fluid** expands the header more generously while still respecting page gutters.
**Full** stretches the header edge to edge.
Adds top, bottom, or dual borders using the shared section styling system.
Available options are **None**, **Top**, **Bottom**, and **Both**.
Controls the main header wrapper color scheme.
This is the primary background and text treatment for the visible header bar itself.
Controls the color scheme used for dropdown panels and mega menu overlays.
Use this when the desktop menu surface should feel visually distinct from the main header bar.
This setting appears in the header schema, but the current header markup does not use it for visible output.
In the current theme code, **Color scheme for content** has no visible effect on the main header output. You can treat it as an inactive setting unless a future theme update connects it to rendered header content.
## Block settings
Controls the mobile and tablet drawer navigation.
Select a dedicated menu for mobile navigation.
If left empty, the block falls back to the header section's main **Menu** setting.
Use **Parent text size** for top-level drawer links and **Child text size** for nested links.
This helps preserve hierarchy in deeper mobile menu structures.
Adds a second list of links below the main mobile menu.
This is useful for support pages, policies, or utility links that should stay separate from the main navigation.
Controls the text size of the secondary menu list.
The mobile drawer also renders social links in its utility area when those links are configured in global theme settings.
Controls the additional desktop slideout navigation drawer.
Sets the label shown beside the desktop slideout trigger.
Adds an optional menu above the main slideout navigation.
This is useful for featured collections, highlighted campaigns, or quick utility destinations.
Controls the visual weight of those featured links.
Controls the main slideout navigation text size.
The block schema includes its own **Menu** setting, but the current rendered main link list uses the header section's main **Menu** value in practice.
Treat the header section's main **Menu** setting as the source of truth for the primary slideout navigation structure in the current theme version.
Adds promotion cards inside the desktop mega menu.
Tie the promotion group to a top-level desktop menu item by entering its position number.
For example, entering `2` connects the promotion group to the second main navigation item.
Each promotion card supports:
* its own color scheme
* half or full column width
* content alignment
* content padding
* optional image or video
* desktop/mobile media visibility
Promotion cards support nested **Heading**, **Text**, and **Button** blocks.
Header promotion blocks render only in the **Mega** menu path. If the header uses **Dropdown** menu type, promotion blocks will not appear in desktop navigation.
The header supports standard `@app` blocks.
App blocks render in the right-hand icon area and can be useful for wishlist, loyalty, or translation integrations.
## Global theme settings that affect the header
Everest header output depends on global brand settings for:
* logo image
* SVG logo
* text logo mode
* logo text
* logo color scheme
* logo width
Practical behavior:
* **Use text for logo** overrides image and SVG usage
* **SVG logo** overrides uploaded logo image when SVG code is present
* if no logo is configured, the store name is shown
Header search behavior depends on global search settings.
These settings control:
* whether product type filtering appears in search
* whether predictive search suggestions are enabled
* whether predictive suggestions show product vendor and price
Everest uses different search UI patterns on desktop and mobile, but both rely on these global search settings.
**Cart type** changes how the header cart icon behaves:
* **Drawer** makes the cart icon act like a button that opens the cart drawer
* **Page** makes the cart icon link to the cart page
* **Notification** enables cart notification markup after the header
The header bubble displays **cart total price**, not item count, and that price label is hidden on mobile.
Social links configured in global theme settings also appear in the mobile drawer utility area.
## Best practices
Use **menu below** layouts when your store has longer top-level labels or more categories to scan.
Reserve the mega menu for categories that genuinely need multi-level navigation or promotional support.
Create a dedicated mobile menu instead of mirroring every desktop navigation choice one-to-one.
Use additional icons for one or two high-value actions so the header stays easy to parse.
Country and language selectors appear only when your Shopify Markets and language setup includes multiple options.
Unexpected logo behavior usually comes from Brand settings, not from the Header section itself.
Review sticky header behavior on real devices, especially if your first viewport is already busy with navigation, search, and icons.
Tie header promotions to the correct top-level menu position and verify them in mega menu mode before publishing.
## Related guides
Start with the theme overview and preset context before documenting other Everest sections.
Review the shared icon reference used across DigiFist theme documentation.
# Introduction
Source: https://docs.digifist.com/themes/everest/index
A versatile, feature-rich Shopify theme built for stores of any size.
Everest is a Shopify theme built for merchants who need a reliable, fully-featured storefront. It includes a comprehensive section library, advanced product and collection tools, and a complete set of page templates.
## Presets
Coming soon.
## Products
Flexible block-based product page with media gallery, variants, and dynamic checkout.
Link separate products to behave like variants using swatches, images, or text.
Highlight products with Sale, New, Bestseller, and custom tag-based badges.
Branding configuration for digital gift card pages.
## Collections
Product grid with filtering, sorting, and promotional card injection.
Display all or selected collections with custom imagery and pagination.
Dedicated landing page template for featured or seasonal collections.
Full search results with filtering, sorting, and multi-type results.
## Pages & Templates
Customizable error page that guides lost visitors back to your store.
Article feed with tag filtering and block-based individual article layout.
Full-page cart with item management, discounts, and express checkout.
Contact page template with form and store information.
Account dashboard, login, register, addresses, and order details.
Frequently asked questions page template with accordion layout.
Generic content template for About, policies, and more.
Coming soon page with email signup for pre-launch stores.
## Sections & Theme Settings
Browse the full library of sections available for any page in your store.
Control colors, typography, buttons, layout, and global behavior.
Set up navigation, announcement bar, logo, and footer content.
Embed third-party Shopify apps for reviews, wishlists, live chat, and more.
# 404 Page
Source: https://docs.digifist.com/themes/everest/pages-templates/404
Configure Everest's 404 template and the recovery content shown when a page cannot be found.
The 404 Page template controls the main structure used for this page type in Everest. It combines template-specific sections with reusable content blocks, which means most storefront behavior can be adjusted in the Theme Customizer without editing theme code.
## What this template controls
* Headings, text content, and on-page messaging
* Layout structure, width, alignment, and spacing
* Calls to action, links, and navigation behavior
* Color schemes, contrast, and shared visual styling
* The template section order and the supporting sections included by default
## Template structure
This template uses the following main sections or related theme building blocks by default:
* **404**
* **Featured Collections**
## Getting started
Open the relevant page type or assign the template to a resource before customizing it.
Start with the primary content section so layout, filtering, gallery, or page-level behavior is defined before refining supporting content.
Review any banners, content sections, or utility sections included in the template so the full page works together as a set.
## Main settings
### Settings
Enter the content used for **heading**.
**Default:** `404 - Page not found`
Enter the content used for **text**.
**Default:** `
Oops, We can't find what you're looking for here.
`
Enter the content used for **button label**.
Keep action labels short so they remain readable across devices.
**Default:** `Continue shopping`
Leave empty to hide the button
Set the destination URL for **button link**.
Keep action labels short so they remain readable across devices.
**Default:** `/collections/all`
Choose how **Button style** behaves in the section.
Keep action labels short so they remain readable across devices.
**Available options:** Filled, Outlined, Text.
**Default:** `outlined`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** XXS, Page, Fluid.
**Default:** `xxs`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Keep labels short and scannable, especially in tighter layouts or utility areas.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Test this template with real content volume so headings, cards, and filters behave as expected.
* Review supporting sections together because template defaults often work as a coordinated set.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
# Cart
Source: https://docs.digifist.com/themes/everest/pages-templates/cart
Configure Everest's cart template, sidebar content, and cart action blocks.
The Cart template controls the main structure used for this page type in Everest. It combines template-specific sections with reusable content blocks, which means most storefront behavior can be adjusted in the Theme Customizer without editing theme code.
## What this template controls
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
* Block types such as Subtotal, Note, Payment Icons, Shipping Estimator
* The template section order and the supporting sections included by default
## Template structure
This template uses the following main sections or related theme building blocks by default:
* **Cart**
* **Featured Products**
## Getting started
Open the relevant page type or assign the template to a resource before customizing it.
Start with the primary content section so layout, filtering, gallery, or page-level behavior is defined before refining supporting content.
Review any banners, content sections, or utility sections included in the template so the full page works together as a set.
## Main settings
### Sidebar
Select the color scheme used for **color for sidebar**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-4`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Small, Page, Fluid.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Test this template with real content volume so headings, cards, and filters behave as expected.
* Review supporting sections together because template defaults often work as a coordinated set.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Cart Drawer](/themes/everest/sections/cart-drawer)
# Contact
Source: https://docs.digifist.com/themes/everest/pages-templates/contact
Configure Everest's contact page template and the supporting form, map, and content sections it can include.
The Contact template controls the main structure used for this page type in Everest. It combines template-specific sections with reusable content blocks, which means most storefront behavior can be adjusted in the Theme Customizer without editing theme code.
## What this template controls
* The template section order and the supporting sections included by default
## Template structure
This template uses the following main sections or related theme building blocks by default:
* **Page**
* **Contact Form**
* **Map**
* **Rich Text**
## Getting started
Open the relevant page type or assign the template to a resource before customizing it.
Start with the primary content section so layout, filtering, gallery, or page-level behavior is defined before refining supporting content.
Review any banners, content sections, or utility sections included in the template so the full page works together as a set.
## Supporting sections
This template relies on reusable sections working together rather than on a single main schema. Review the linked section guides below when you want to fine-tune each part in more depth.
## Best practices
* Test this template with real content volume so headings, cards, and filters behave as expected.
* Review supporting sections together because template defaults often work as a coordinated set.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Contact Form](/themes/everest/sections/contact-form)
* [Map](/themes/everest/sections/map)
# Customer Accounts
Source: https://docs.digifist.com/themes/everest/pages-templates/customer-accounts
Understand the Everest customer account templates for login, registration, addresses, orders, activation, and password reset flows.
The Customer Accounts template controls the main structure used for this page type in Everest. It combines template-specific sections with reusable content blocks, which means most storefront behavior can be adjusted in the Theme Customizer without editing theme code.
## What this template controls
* The template section order and the supporting sections included by default
## Template structure
This template uses the following main sections or related theme building blocks by default:
* **Account**
* **Addresses**
* **Login**
* **Order**
* **Register**
* **Activate Account**
* **Reset Password**
## Getting started
Open the relevant page type or assign the template to a resource before customizing it.
Start with the primary content section so layout, filtering, gallery, or page-level behavior is defined before refining supporting content.
Review any banners, content sections, or utility sections included in the template so the full page works together as a set.
## Included account templates
* Account overview
* Addresses
* Login
* Order detail
* Register
* Activate account
* Reset password
These templates have minimal theme-level settings in Everest. Their behavior depends more on Shopify customer account flows, shared theme styling, and the customer account theme settings category.
## Best practices
* Test this template with real content volume so headings, cards, and filters behave as expected.
* Review supporting sections together because template defaults often work as a coordinated set.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Customer Account Settings](/themes/everest/theme-settings/customer-account)
# FAQ
Source: https://docs.digifist.com/themes/everest/pages-templates/faq
Configure Everest's FAQ page template and the accordion-based answer groups used on it.
The FAQ template controls the main structure used for this page type in Everest. It combines template-specific sections with reusable content blocks, which means most storefront behavior can be adjusted in the Theme Customizer without editing theme code.
## What this template controls
* The template section order and the supporting sections included by default
## Template structure
This template uses the following main sections or related theme building blocks by default:
* **Page**
* **Accordions**
* **Rich Text**
## Getting started
Open the relevant page type or assign the template to a resource before customizing it.
Start with the primary content section so layout, filtering, gallery, or page-level behavior is defined before refining supporting content.
Review any banners, content sections, or utility sections included in the template so the full page works together as a set.
## Supporting sections
This template relies on reusable sections working together rather than on a single main schema. Review the linked section guides below when you want to fine-tune each part in more depth.
## Best practices
* Test this template with real content volume so headings, cards, and filters behave as expected.
* Review supporting sections together because template defaults often work as a coordinated set.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Accordions](/themes/everest/sections/accordions)
# Page
Source: https://docs.digifist.com/themes/everest/pages-templates/page
Configure Everest's standard page template and the rich content blocks that support it.
The Page template controls the main structure used for this page type in Everest. It combines template-specific sections with reusable content blocks, which means most storefront behavior can be adjusted in the Theme Customizer without editing theme code.
## What this template controls
* Headings, text content, and on-page messaging
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
* Block types such as Content, Custom Liquid
* The template section order and the supporting sections included by default
## Template structure
This template uses the following main sections or related theme building blocks by default:
* **Page**
## Getting started
Open the relevant page type or assign the template to a resource before customizing it.
Start with the primary content section so layout, filtering, gallery, or page-level behavior is defined before refining supporting content.
Review any banners, content sections, or utility sections included in the template so the full page works together as a set.
## Main settings
### Settings
Enter the content used for **heading**.
**Default:** `{{ page.title }}`
Choose how **Heading size** behaves in the section.
**Available options:** S, M, L, XL.
**Default:** `h2`
Enter the content used for **text**.
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** XXS, Page, Fluid, Full.
**Default:** `xxs`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Test this template with real content volume so headings, cards, and filters behave as expected.
* Review supporting sections together because template defaults often work as a coordinated set.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
# Password
Source: https://docs.digifist.com/themes/everest/password
Configure Everest's locked-store password experience, launch messaging, brand presentation, and access flow.
Password controls the temporary storefront experience shown while the store is protected. In Everest, this page uses the dedicated password layout together with the `main-password-header`, `banner`, and `main-password-footer` sections, so the final result depends on both page-level content and shared brand or social settings.
## What this template controls
* Brand logo or shop name display at the top of the locked store
* The password entry modal and admin access link
* Shopify password message output
* The main banner content used for launch messaging or newsletter signup
* Social icons and footer utility content on the password page
* Color schemes for the dedicated password header and footer sections
## Template structure
This template uses the following password-specific layout pieces by default:
* **Password Header**
* **Banner**
* **Password Footer**
## Getting started
In Theme Customizer, open the password template while the store password is enabled.
Start with the banner content because it carries the main message visitors see before the store opens.
Check the header logo, store name fallback, password entry flow, and any store password message set in Shopify.
Review social icons and footer styling last so the page feels complete without distracting from the launch message.
## How Everest's password page works
The header shows the brand logo when a global brand logo or SVG logo exists. If no logo is configured, Everest falls back to the shop name.
It also displays the optional Shopify password message and opens the storefront password form inside a modal dialog.
The main content area comes from the standard Everest banner section.
In the default password template, the banner is configured as a newsletter-style launch section with heading, text, and newsletter blocks.
The footer shows social icons, the Shopify attribution text, and the admin access link.
Social icons only appear when the related links are filled in Everest's global social settings.
Everest uses `layout/password.liquid` for this page type instead of the standard storefront layout. That is why the password page has its own header and footer sections separate from the main storefront header and footer.
## Section settings
### Password Header and Password Footer
Both password-specific utility sections expose a single color scheme setting so you can keep the locked-store experience aligned with the rest of your launch styling.
### Banner dependency
The banner carries most of the visible launch content. Text, newsletter signup, spacing, and layout choices for the password page are primarily managed through the Banner section rather than through the password header or footer.
## Best practices
* Keep the banner message short so visitors understand the launch state immediately.
* Configure brand and social settings before troubleshooting missing password-page content.
* Test the password modal on mobile to make sure access remains easy while the store is locked.
* Use the password page to support a launch goal such as email capture, early access, or simple status messaging.
## Related guides
* [Banner](/themes/everest/sections/banner)
* [Theme Settings: Brand](/themes/everest/theme-settings/brand)
* [Theme Settings: Social Media](/themes/everest/theme-settings/social-media)
# Gift Card
Source: https://docs.digifist.com/themes/everest/products/gift-card
Understand how Everest's gift card template uses brand settings, QR codes, and customer-facing gift card actions.
The Gift Card template controls the main structure used for this page type in Everest. It combines template-specific sections with reusable content blocks, which means most storefront behavior can be adjusted in the Theme Customizer without editing theme code.
## What this template controls
* The template section order and the supporting sections included by default
## Template structure
This template uses the following main sections or related theme building blocks by default:
## Getting started
Open the relevant page type or assign the template to a resource before customizing it.
Start with the primary content section so layout, filtering, gallery, or page-level behavior is defined before refining supporting content.
Review any banners, content sections, or utility sections included in the template so the full page works together as a set.
## Key implementation notes
Gift cards pull branding from global brand settings such as the main logo, SVG logo, and favicon-related assets when available.
The template renders a QR code for the gift card identifier and includes built-in copy-to-clipboard behavior for the gift card code.
This template renders outside the normal storefront layout, so it behaves more like a self-contained customer-facing utility page.
## Best practices
* Test this template with real content volume so headings, cards, and filters behave as expected.
* Review supporting sections together because template defaults often work as a coordinated set.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Brand Settings](/themes/everest/theme-settings/brand)
# Product Badges
Source: https://docs.digifist.com/themes/everest/products/product-badges
Configure Everest's built-in sale and sold-out badges on product cards, search results, and product pages.
Product Badges control the small status labels Everest shows for important product states. In Everest, badge behavior is intentionally narrow and automatic: the theme shows badges for sold-out or on-sale products, and the visual styling comes from global badge settings plus an optional Product Badge block on the product page.
## What this feature controls
* Global badge position on product cards
* Badge corner radius styling
* Sale and sold-out badge color schemes
* Product page badge placement through the Product Badge block
* Search result badge styling for page-type results
## Getting started
In Theme Customizer, go to **Theme settings -> Badges** to configure the shared badge style first.
Check collection cards or other product-card surfaces to confirm the global position and color choices feel balanced.
On the product template, add or review the **Product Badge** block if you want the same state labels shown on the product page.
Verify badge output with at least one on-sale product and one sold-out product so both styling paths are covered.
## Global badge settings
Controls the default overlay position for badges rendered on product cards.
**Available options:** `Bottom left`, `Bottom right`, `Top left`, `Top right`\
**Default:** `Top right`
Controls how rounded the badge corners appear.
**Range:** `0px` to `40px`\
**Default:** `40px`
Sets the color scheme used when a product is available and its compare-at price is higher than its selling price.
**Default:** `scheme-5`
Sets the color scheme used when a product is unavailable.
**Default:** `scheme-3`
## Product page block settings
The Product Badge block can place badges either inline with other product content or as an overlay.
**Available options:** `Inline`, `Overlay`\
**Default:** `Overlay`
Controls the space below the Product Badge block on the product page.
## Display logic
Everest shows the sold-out badge whenever the selected product is unavailable.
Everest shows the sale badge when the selected product is available and its compare-at price is greater than its current price.
On `main-search`, the badge snippet can also render a page-type label for search result cards that represent pages rather than products.
## Important limitation
Everest does not use the broader tag-based custom badge system documented in some other themes. The built-in badge snippet only handles sale and sold-out product states automatically, so custom promotional badge text is not a native Everest badge feature.
## Best practices
* Choose badge colors that remain readable over real product imagery.
* Keep badge placement consistent across cards and product pages unless there is a clear layout reason to change it.
* Test both sold-out and on-sale states because each badge can use a different color scheme.
* Avoid relying on Everest badges for custom campaign messaging unless you plan to extend the theme code.
## Related guides
* [Product Page](/themes/everest/products/product-page)
* [Theme Settings: Badges](/themes/everest/theme-settings/badges)
* [Theme Settings: Products](/themes/everest/theme-settings/products)
# Product Groups
Source: https://docs.digifist.com/themes/everest/products/product-groups
Link separate Everest products into switchable groups on product cards and product pages.
Product Groups let Everest present separate Shopify products as one connected group. Instead of relying only on native variants, the theme reads metaobject data and renders linked options that send customers to the matching product page while preserving a grouped shopping experience on cards and product pages.
## What this feature controls
* Links separate products into one grouped selection flow
* Displays grouped items on product cards and product pages
* Chooses how groups appear on cards versus product pages
* Uses text, image, swatch, or product-image style outputs
* Supports custom labels and custom option images through metaobjects
* Extends the Product Variant Picker block on the product page
## Getting started
Create a Shopify metaobject definition for grouped products. Everest expects fields such as the grouped product list, the grouping label, the display type on cards, the display type on pages, and the optional custom label toggle.
If you want custom text or images for grouped options, create a second metaobject definition for product option value data.
In **Theme settings -> Products**, fill in the text fields for the Product Groups metaobject handle and, if used, the Product Options Type Values metaobject handle.
Turn on **Show product groups on product card** if grouped options should also appear on collection cards and other standard product cards.
Check the Product Variant Picker block on the product page because Everest renders Product Groups through that block before the native variant picker.
## Theme settings
Controls whether grouped product options appear on standard product cards when variant options are also enabled there.
**Default:** Enabled
Stores the handle of the Shopify metaobject definition that Everest should read for grouped product relationships.
This is a text field, so the handle needs to match the actual Shopify metaobject handle exactly.
Stores the handle of the optional metaobject definition used for custom text or image values.
Everest uses this when group options should render with custom labels or custom images instead of only product titles and featured images.
## Display behavior
On the product page, Everest renders Product Groups above the native product variant picker inside the Product Variant Picker block.
The legend uses the group label and can show a custom current value when the grouped metaobject enables custom labels on page.
On product cards, Product Groups render only when card variant options are enabled and the global Product Groups card setting is turned on.
Card interactions link directly to the grouped product URL instead of switching a native variant.
Everest supports different outputs depending on the metaobject value:
**Swatch** uses Shopify color-pattern data or custom swatch imagery.\
**Image** uses custom option images when available, otherwise the grouped product image.\
**Text** uses a matched custom text value or the option text.\
**Fallback image style** uses the grouped product featured image.
## Important dependencies
The snippet reads specific metaobject fields directly. If field names or data structure do not match what Everest expects, grouped options will not render correctly.
Swatch groups rely on Shopify's `shopify--color-pattern` data when the group type is set to swatch.
The Product Variant Picker block still affects the page experience through settings such as picker type, swatch shape, and spacing.
## Best practices
* Treat Product Groups as linked products with their own URLs, content, and pricing rather than as a replacement for simple native variants.
* Keep group labels consistent so customers understand what attribute is being changed.
* Use custom option values only when the product title alone is not enough for a clear selection experience.
* Test grouped products on both cards and product pages because the interaction pattern is different in each context.
## Related guides
* [Product Page](/themes/everest/products/product-page)
* [Theme Settings: Products](/themes/everest/theme-settings/products)
* [Product Badges](/themes/everest/products/product-badges)
# Product Page
Source: https://docs.digifist.com/themes/everest/products/product-page
Configure Everest's product template, gallery layout, product information, and supporting purchase blocks.
The Product Page template controls the main structure used for this page type in Everest. It combines template-specific sections with reusable content blocks, which means most storefront behavior can be adjusted in the Theme Customizer without editing theme code.
## What this template controls
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
* Block types such as Product Media Gallery, Product Blocks Main, Product Blocks Side
* The template section order and the supporting sections included by default
## Template structure
This template uses the following main sections or related theme building blocks by default:
* **Product**
* **Related Products**
* **Pickup Availability**
## Getting started
Open the relevant page type or assign the template to a resource before customizing it.
Start with the primary content section so layout, filtering, gallery, or page-level behavior is defined before refining supporting content.
Review any banners, content sections, or utility sections included in the template so the full page works together as a set.
## Main settings
### Settings
Choose how **Sticky product information on desktop** behaves in the section.
**Available options:** None, Gallery, Page.
**Default:** `gallery`
When you choose page option, the sticky product information will be sticky throughout the page, other sections' widths will be adjusted according to product gallery width.
Adjust **Product information width on desktop** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `24.0` to `72.0` **Default:** `38.4`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Test this template with real content volume so headings, cards, and filters behave as expected.
* Review supporting sections together because template defaults often work as a coordinated set.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Related Products](/themes/everest/sections/related-products)
* [Pickup Availability](/themes/everest/sections/pickup-availability)
# Accordions
Source: https://docs.digifist.com/themes/everest/sections/accordions
Configure Everest's accordions section and its main settings, content structure, and styling controls.
The Accordions section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Images, videos, and other media presentation options
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
* Block types such as Accordion
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Accordions** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
Add, remove, or reorder blocks after the main layout feels right so content hierarchy stays easier to manage.
## Section settings
### Settings
Enable or disable **Open first collapsible row**.
**Default:** `disabled`
Enable or disable **Show accordions media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `enabled`
### Media
Choose how **Show on** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
This setting only appears when its related parent option is enabled.
Choose how **Media position** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Start, End.
**Default:** `start`
This setting only appears when its related parent option is enabled.
Desktop and tablet only. Automatically adjusted for mobile.
Choose how **Aspect ratio** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Auto, Square, 4:3, 3:4, 3:2, 2:3, 5:4, 4:5, 16:9, 9:16, 2:1, 4:1, 8:1, 1:2.
**Default:** `auto`
This setting only appears when its related parent option is enabled.
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
Enable or disable **Enable mobile specific media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
Displays mobile-specific alternative media. Add a media before setting a mobile alternative.
### Media for mobile
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Block settings
### Accordion
This block controls the **accordion** content used inside the Accordions section.
### Settings
Choose how **Show on** behaves in the section.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
### Content
Enter the content used for **heading**.
Enter the content used for **text**.
Choose how **Text size** behaves in the section.
**Available options:** XS, S, M, L.
**Default:** `sm`
Choose the Shopify page connected to **page**.
Enable or disable **Show accordion icon**.
**Default:** `disabled`
### Icon
Enter the content used for **svg code**.
This setting only appears when its related parent option is enabled.
You can use SVG code for custom icons.
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `4`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Review media-heavy layouts on both desktop and mobile before publishing.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Apps
Source: https://docs.digifist.com/themes/everest/sections/apps
Configure Everest's apps section and its main settings, content structure, and styling controls.
The Apps section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Apps** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
## Section settings
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `full`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Banner
Source: https://docs.digifist.com/themes/everest/sections/banner
Configure Everest's banner section and its main settings, content structure, and styling controls.
The Banner section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Images, videos, and other media presentation options
* Layout structure, width, alignment, and spacing
* Calls to action, links, and navigation behavior
* Color schemes, contrast, and shared visual styling
* Block types such as Slide
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Banner** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
Add, remove, or reorder blocks after the main layout feels right so content hierarchy stays easier to manage.
## Section settings
### Settings
Choose how **Section height** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Ratio, Custom.
**Default:** `ratio`
Adjust **Custom height** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `0` to `100` **Default:** `60`
This setting only appears when its related parent option is enabled.
Choose how **Aspect ratio** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Auto, 1:1, 4:3, 3:4, 3:2, 2:3, 5:4, 4:5, 16:9, 9:16, 2:1, 4:1, 1:2.
**Default:** `auto`
This setting only appears when its related parent option is enabled.
### Slideshow
Adjust **Autoplay** with a slider-based control.
**Range:** `0` to `10` **Default:** `5`
Set to 0 to disable autoplay.
Choose how **Pagination** behaves in the section.
**Available options:** None, Dots 1, Dots 2, Dynamic, Fraction.
**Default:** `dots-2`
Choose how **Navigation** behaves in the section.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Available options:** None, 1, 2, 3.
**Default:** `style-1`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
This setting only appears when its related parent option is enabled.
### Mobile settings
Enable or disable **Enable mobile specific settings**.
**Default:** `disabled`
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Full.
**Default:** `full`
This setting only appears when its related parent option is enabled.
Choose how **Section height** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Ratio, Custom.
**Default:** `ratio`
This setting only appears when its related parent option is enabled.
Adjust **Custom height** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `0` to `100` **Default:** `60`
This setting only appears when its related parent option is enabled.
Choose how **Aspect ratio** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Auto, 1:1, 4:3, 3:4, 3:2, 2:3, 5:4, 4:5, 16:9, 9:16, 2:1, 4:1, 8:1, 1:2.
**Default:** `auto`
This setting only appears when its related parent option is enabled.
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `full`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Block settings
### Slide
This block controls the **slide** content used inside the Banner section.
### Settings
Choose how **Slide layout** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Full, Side by side, Split.
**Default:** `1`
Choose how **Media width** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** S, M, L.
**Default:** `md`
This setting only appears when its related parent option is enabled.
It will be optimized for mobile.
Choose how **Media order** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** First, Last.
**Default:** `first`
This setting only appears when its related parent option is enabled.
Enable or disable **Reverse layout on mobile**.
It has the strongest effect on layout balance and visual hierarchy.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
Media will be displayed above content on mobile.
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-2`
### Content
Choose how **Container** behaves in the section.
**Available options:** Box, No.
**Default:** `none`
Select the color scheme used for **color for box**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
This setting only appears when its related parent option is enabled.
Choose how **Content width** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Small, Medium, Large, Page.
**Default:** `page`
This setting only appears when its related parent option is enabled.
Choose how **Vertical alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⤒, Center, ⤓.
**Default:** `center`
Vertical alignment automatically optimized for mobile.
Choose how **Horizontal alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⇤, Center, ⇥.
**Default:** `center`
Choose how **Content alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⇤, Center, ⇥.
**Default:** `center`
This setting only appears when its related parent option is enabled.
Enable or disable **Show slide media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `enabled`
### Media
Choose how **Show on** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
This setting only appears when its related parent option is enabled.
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
Adjust **Media overlay** with a slider-based control.
Review the result on both desktop and mobile when media changes are involved.
**Range:** `0` to `100` **Default:** `30%`
This setting only appears when its related parent option is enabled.
Enable or disable **Enable mobile specific media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
Displays mobile-specific alternative media. Add a media before setting a mobile alternative.
### Media for mobile
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
### Secondary media
Choose how **Show on** behaves in the section.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
This setting only appears when its related parent option is enabled.
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
Enable or disable **Enable mobile specific media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
Displays mobile-specific alternative media. Add a media before setting a mobile alternative.
### Media for mobile
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
### Product
Choose the product source used by **product**.
**Supports nested blocks:**
* **Heading** for more granular content inside this block.
* **Text** for more granular content inside this block.
* **Description** for more granular content inside this block.
* **Button Group** for more granular content inside this block.
* **Newsletter** for more granular content inside this block.
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Keep labels short and scannable, especially in tighter layouts or utility areas.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Blog Posts
Source: https://docs.digifist.com/themes/everest/sections/blog-posts
Configure Everest's blog posts section and its main settings, content structure, and styling controls.
The Blog Posts section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Layout structure, width, alignment, and spacing
* Calls to action, links, and navigation behavior
* Color schemes, contrast, and shared visual styling
* Block types such as Article Card
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Blog Posts** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
Add, remove, or reorder blocks after the main layout feels right so content hierarchy stays easier to manage.
## Section settings
### Settings
Select the blog source used for **blog**.
### Layout
Choose how **Desktop** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Grid, Carousel.
**Default:** `carousel`
### Number of columns
Adjust **Desktop** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `1` to `6` **Default:** `4`
Adjust **Mobile** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `1` to `1.4` **Default:** `1`
### Carousel layout
Choose how **Navigation** behaves in the section.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Available options:** None, 1, 2.
**Default:** `style-1`
Select the color scheme used for **color for navigation**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Enable or disable **Overflow**.
**Default:** `disabled`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Block settings
### Article Card
This block controls the **article card** content used inside the Blog Posts section.
### Style
Choose how **Card frame** behaves in the section.
**Available options:** None, Border.
**Default:** `border`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
### Content
Choose how **Padding** behaves in the section.
**Available options:** No, S, M, L.
**Default:** `lg`
Choose how **Vertical alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⤒, Center, ⤓.
**Default:** `start`
Choose how **Horizontal alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⇤, Center, ⇥.
**Default:** `start`
### Media
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
Overwrites the image.
Choose how **Media position** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Inline, Background.
**Default:** `inline`
Choose how **Aspect ratio** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Auto, Square, 4:3, 3:4, 3:2, 2:3, 5:4, 4:5, 16:9, 9:16, 2:1, 4:1, 8:1, 1:2.
**Default:** `1.00`
This setting only appears when its related parent option is enabled.
Choose how **Object fit** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** Cover, Contain.
**Default:** `cover`
This setting only appears when its related parent option is enabled.
**Supports nested blocks:**
* **Heading** for more granular content inside this block.
* **Text** for more granular content inside this block.
* **Article Card Details** for more granular content inside this block.
* **Article Card Tags** for more granular content inside this block.
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Keep labels short and scannable, especially in tighter layouts or utility areas.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Callout Banner
Source: https://docs.digifist.com/themes/everest/sections/callout-banner
Configure Everest's callout banner section and its main settings, content structure, and styling controls.
The Callout Banner section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Headings, text content, and on-page messaging
* Images, videos, and other media presentation options
* Layout structure, width, alignment, and spacing
* Calls to action, links, and navigation behavior
* Color schemes, contrast, and shared visual styling
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Callout Banner** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
## Section settings
### Settings
Choose how **Layout** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Boxed, Minimal, Inline.
**Default:** `1`
Choose how **Spacing** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Standard, Compact.
**Default:** `standard`
This setting only appears when its related parent option is enabled.
### Content
Enter the content used for **heading**.
**Default:** `Callout heading`
Choose how **Heading size** behaves in the section.
**Available options:** S, M, L, XL.
**Default:** `h2`
This setting only appears when its related parent option is enabled.
Enter the content used for **text**.
This setting only appears when its related parent option is enabled.
Choose how **Action preference** behaves in the section.
**Available options:** Button, Newsletter.
**Default:** `button`
This setting only appears when its related parent option is enabled.
Enter the content used for **button label**.
Keep action labels short so they remain readable across devices.
This setting only appears when its related parent option is enabled.
Leave empty to hide the button
Set the destination URL for **button link**.
Keep action labels short so they remain readable across devices.
This setting only appears when its related parent option is enabled.
Enter the content used for **newsletter button label**.
Keep action labels short so they remain readable across devices.
**Default:** `Submit`
This setting only appears when its related parent option is enabled.
Choose how **Button style** behaves in the section.
Keep action labels short so they remain readable across devices.
**Available options:** Filled, Outlined, Text.
**Default:** `outlined`
This setting only appears when its related parent option is enabled.
Select the color scheme used for **color for content**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-4`
Enable or disable **Show callout banner media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `disabled`
### Media
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Upload or choose an image for **mobile image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
If mobile image is set, it will be used on mobile devices instead of the main image.
Choose how **Media position** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Start, End, Full.
**Default:** `full`
This setting only appears when its related parent option is enabled.
### Timer
Enable or disable **Show timer**.
**Default:** `enabled`
Set the numeric value used for **year**.
**Default:** `2027`
Choose how **Month** behaves in the section.
**Available options:** January, February, March, April, May, June, July, August, September, October, November, December.
**Default:** `01`
Adjust **Day** with a slider-based control.
**Range:** `1` to `31` **Default:** `1`
Adjust **Hour** with a slider-based control.
**Range:** `0` to `23` **Default:** `0h`
Adjust **Minute** with a slider-based control.
**Range:** `0` to `59` **Default:** `0m`
Enter the content used for **end message**.
**Default:** `Sale has ended`
This message will be displayed when the timer ends.
### Parts display settings
Enable or disable **Show day part**.
**Default:** `enabled`
Enable or disable **Show hour part**.
**Default:** `enabled`
Enable or disable **Show minute part**.
**Default:** `enabled`
Enable or disable **Show second part**.
**Default:** `enabled`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `full`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Review media-heavy layouts on both desktop and mobile before publishing.
* Keep labels short and scannable, especially in tighter layouts or utility areas.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Cart Drawer
Source: https://docs.digifist.com/themes/everest/sections/cart-drawer
Understand how Everest's cart drawer helper works and which sections or theme settings influence it.
The cart drawer is rendered through a shared snippet rather than a section schema, so its behavior is primarily driven by global cart settings and cart state.
It handles empty-cart messaging, item list rendering, subtotal areas, optional recommendations, and checkout actions in an overlay-style drawer.
Because there is no regular section schema here, most customization comes from theme settings, cart content, and the supporting cart snippet structure.
## What this feature controls
* Drawer-based cart interactions and checkout flow
* Line item display, empty-state behavior, and subtotal area
* Optional cart recommendations and supporting cart content
## How it is configured
Start in the Theme Customizer or the related theme settings category that controls this feature.
Review the product, header, cart, or search area that surfaces this helper so you can understand where the storefront output comes from.
Because these helpers react to live cart, product, or search data, verify the result with realistic content before publishing.
## Key implementation notes
The cart drawer is rendered through a shared snippet, so there is no regular section settings panel for it.
Cart settings, line items, upsell logic, and customer cart state all influence the final drawer experience.
Test the empty state, a cart with multiple items, and the checkout action area before publishing changes that affect the drawer.
## Best practices
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
* [Cart Settings](/themes/everest/theme-settings/cart)
# Compare Slider
Source: https://docs.digifist.com/themes/everest/sections/compare-slider
Configure Everest's compare slider section and its main settings, content structure, and styling controls.
The Compare Slider section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Images, videos, and other media presentation options
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Compare Slider** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
## Section settings
### Settings
Choose how **Media ratio** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** 1:1, 2:3, 3:4, 4:5, 9:16.
**Default:** `3/2`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Review media-heavy layouts on both desktop and mobile before publishing.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Contact Form
Source: https://docs.digifist.com/themes/everest/sections/contact-form
Configure Everest's contact form section and its main settings, content structure, and styling controls.
The Contact Form section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Headings, text content, and on-page messaging
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
* Block types such as Field
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Contact Form** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
Add, remove, or reorder blocks after the main layout feels right so content hierarchy stays easier to manage.
## Section settings
### Settings
Enter the content used for **heading**.
**Default:** `Contact form`
Choose how **Heading size** behaves in the section.
**Available options:** XS, S, M, L, XL.
**Default:** `h1`
Enter the content used for **contact form footer text**.
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Block settings
### Field
This block controls the **field** content used inside the Contact Form section.
This block does not expose additional documented settings beyond its placement and content usage.
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Content Tiles
Source: https://docs.digifist.com/themes/everest/sections/content-tiles
Configure Everest's content tiles section and its main settings, content structure, and styling controls.
The Content Tiles section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
* Block types such as Content Tile
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Content Tiles** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
Add, remove, or reorder blocks after the main layout feels right so content hierarchy stays easier to manage.
## Section settings
### Settings
Choose how **Spacing** behaves in the section.
**Available options:** Standard, Compact.
**Default:** `standard`
Adjust **Tile corner radius** with a slider-based control.
**Range:** `0` to `8` **Default:** `0.8rem`
Adjust **Minimum height of each row** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `0` to `100` **Default:** `0rem`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
Choose how **Show on** behaves in the section.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
## Block settings
### Content Tile
This block controls the **content tile** content used inside the Content Tiles section.
### Settings
Choose how **Show on** behaves in the section.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
Adjust **Column factor** with a slider-based control.
**Range:** `1` to `12` **Default:** `1`
Adjust **Row factor** with a slider-based control.
**Range:** `1` to `12` **Default:** `1`
Enable or disable **Mobile grid and row settings**.
**Default:** `disabled`
Adjust **Column factor (mobile)** with a slider-based control.
**Range:** `1` to `12` **Default:** `12`
This setting only appears when its related parent option is enabled.
Adjust **Row factor (mobile)** with a slider-based control.
**Range:** `1` to `12` **Default:** `1`
This setting only appears when its related parent option is enabled.
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Controls **gradient background**.
Choose how **Aspect ratio** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Auto, 1:1, 4:3, 3:4, 3:2, 2:3, 5:4, 4:5, 16:9, 9:16, 2:1, 4:1, 8:1, 1:2.
**Default:** `auto`
### Content
Choose how **Vertical alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⤒, Center, ⤓.
**Default:** `start`
Choose how **Horizontal alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⇤, Center, ⇥.
**Default:** `start`
Choose how **Content padding** behaves in the section.
**Available options:** No, S, M, L, ↺.
**Default:** `default`
Enable or disable **Show content tile media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
Enable or disable **Show content tile icon**.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
### Media
Choose how **Show on** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
This setting only appears when its related parent option is enabled.
Choose how **Media position** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Top, Bottom, Start, End, Background.
**Default:** `top`
This setting only appears when its related parent option is enabled.
Desktop and tablet only. Automatically adjusted for mobile.
Choose how **Aspect ratio** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Auto, Square, 4:3, 3:4, 3:2, 2:3, 5:4, 4:5, 16:9, 9:16, 2:1, 4:1, 8:1, 1:2.
**Default:** `auto`
This setting only appears when its related parent option is enabled.
Choose how **Object fit** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** Cover, Contain.
**Default:** `cover`
This setting only appears when its related parent option is enabled.
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
Enable or disable **Enable mobile specific media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
Displays mobile-specific alternative media. Add a media before setting a mobile alternative.
### Media for mobile
Choose how **Aspect ratio** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Auto, Square, 4:3, 3:4, 3:2, 2:3, 5:4, 4:5, 16:9, 9:16, 2:1, 4:1, 8:1, 1:2.
**Default:** `auto`
This setting only appears when its related parent option is enabled.
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
### Icon
Choose how **Icon position** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Top, Bottom, Start, End.
**Default:** `start`
This setting only appears when its related parent option is enabled.
Adjust **Icon width** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `0` to `40` **Default:** `3.6rem`
This setting only appears when its related parent option is enabled.
Enter the content used for **svg code**.
This setting only appears when its related parent option is enabled.
You can use SVG code for custom icons.
**Supports nested blocks:**
* **Heading** for more granular content inside this block.
* **Text** for more granular content inside this block.
* **Button** for more granular content inside this block.
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Custom Liquid
Source: https://docs.digifist.com/themes/everest/sections/custom-liquid
Configure Everest's custom liquid section and its main settings, content structure, and styling controls.
The Custom Liquid section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Custom Liquid** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
## Section settings
### Settings
Controls **liquid code**.
Add app snippets or other code to create advanced customizations. [Learn more](https://shopify.dev/docs/api/liquid)
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Featured Collections
Source: https://docs.digifist.com/themes/everest/sections/featured-collections
Configure Everest's featured collections section and its main settings, content structure, and styling controls.
The Featured Collections section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Headings, text content, and on-page messaging
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
* Block types such as Collection Group, Card Group
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Featured Collections** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
Add, remove, or reorder blocks after the main layout feels right so content hierarchy stays easier to manage.
## Section settings
### Default settings for blocks
Choose how **Content padding** behaves in the section.
**Available options:** No, S, M, L, XL.
**Default:** `4`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
## Block settings
### Collection Group
This block controls the **collection group** content used inside the Featured Collections section.
### Settings
Enter the content used for **label**.
Select the collection source used by **collections**.
Choose how **Layout** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Grid, Carousel.
**Default:** `grid`
### Number of columns
Adjust **Desktop** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `0` to `8` **Default:** `4`
Use 0 to let columns adjust to their content width
Adjust **Mobile** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `0` to `2` **Default:** `1`
Use 0 to let columns adjust to their content width
### Carousel layout
Choose how **Navigation** behaves in the section.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Available options:** None, 1, 2.
**Default:** `style-2`
Select the color scheme used for **color for navigation**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-2`
Enable or disable **Overflow**.
**Default:** `disabled`
Overflow is available only when the featured card layout is normal.
### Card Group
This block controls the **card group** content used inside the Featured Collections section.
### Settings
Enter the content used for **label**.
Choose how **Layout** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Grid, Carousel.
**Default:** `grid`
### Number of columns
Adjust **Desktop** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `0` to `12` **Default:** `4`
Use 0 to let columns adjust to their content width
Adjust **Mobile** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `0` to `2` **Default:** `1`
Use 0 to let columns adjust to their content width
### Carousel layout
Choose how **Navigation** behaves in the section.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Available options:** None, 1, 2.
**Default:** `style-1`
Select the color scheme used for **color for navigation**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Enable or disable **Overflow**.
**Default:** `disabled`
Overflow is available only when the featured card layout is normal.
Choose how **Aspect ratio** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Auto, Square, 4:3, 3:4, 3:2, 2:3, 5:4, 4:5, 16:9, 9:16, 2:1, 4:1, 8:1, 1:2.
**Default:** `1.00`
**Supports nested blocks:**
* **Card** for more granular content inside this block.
* **Collection Card** for more granular content inside this block.
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Featured Product
Source: https://docs.digifist.com/themes/everest/sections/featured-product
Configure Everest's featured product section and its main settings, content structure, and styling controls.
The Featured Product section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Headings, text content, and on-page messaging
* Layout structure, width, alignment, and spacing
* Product, collection, or cart-related storefront behavior
* Color schemes, contrast, and shared visual styling
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Featured Product** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
## Section settings
### Settings
Choose the product source used by **product**.
Adjust **Product information width on desktop** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `24.0` to `72.0` **Default:** `38.4`
Select the color scheme used for **color for content**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Featured Products
Source: https://docs.digifist.com/themes/everest/sections/featured-products
Configure Everest's featured products section and its main settings, content structure, and styling controls.
The Featured Products section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Images, videos, and other media presentation options
* Layout structure, width, alignment, and spacing
* Calls to action, links, and navigation behavior
* Product, collection, or cart-related storefront behavior
* Color schemes, contrast, and shared visual styling
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Featured Products** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
## Section settings
### Settings
Select the collection source used by **collection**.
Choose the product source used by **product list**.
Overrides the collection choice.
Choose how **Featured card** behaves in the section.
**Available options:** Normal, Big.
**Default:** `normal`
Choose how **Layout** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Grid, Carousel.
**Default:** `grid`
Choose how **Media order** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** First, Last.
**Default:** `first`
This setting only appears when its related parent option is enabled.
Optimized for mobile
### Number of columns
Adjust **Desktop** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `1` to `6` **Default:** `3`
Adjust **Mobile** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `1` to `1.4` **Default:** `1`
### Carousel layout
Choose how **Pagination** behaves in the section.
**Available options:** None, Progress.
**Default:** `progress`
Choose how **Navigation** behaves in the section.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Available options:** None, 1, 2.
**Default:** `style-1`
Select the color scheme used for **color for navigation**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Enable or disable **Overflow**.
**Default:** `disabled`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Review media-heavy layouts on both desktop and mobile before publishing.
* Keep labels short and scannable, especially in tighter layouts or utility areas.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Image with Text
Source: https://docs.digifist.com/themes/everest/sections/image-with-text
Configure Everest's image with text section and its main settings, content structure, and styling controls.
The Image with Text section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
* Block types such as Card
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Image with Text** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
Add, remove, or reorder blocks after the main layout feels right so content hierarchy stays easier to manage.
## Section settings
### Settings
Choose how **Spacing** behaves in the section.
**Available options:** Standard, Compact.
**Default:** `standard`
Enable or disable **Separate cards**.
**Default:** `disabled`
Separate content and image
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Block settings
### Card
This block controls the **card** content used inside the Image with Text section.
### Settings
Choose how **Corner radius** behaves in the section.
**Available options:** No, S, M, L, ↺.
**Default:** `default`
### Style
Choose how **Card frame** behaves in the section.
**Available options:** None, Border.
**Default:** `border`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
### Content
Choose how **Show on** behaves in the section.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
Choose how **Content padding** behaves in the section.
**Available options:** No, S, M, L, ↺.
**Default:** `default`
### Desktop alignment
Choose how **Vertical alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⤒, Center, ⤓.
**Default:** `start`
Choose how **Horizontal alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⇤, Center, ⇥.
**Default:** `start`
### Mobile alignment
Choose how **Vertical alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⤒, Center, ⤓.
**Default:** `start`
Choose how **Horizontal alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⇤, Center, ⇥.
**Default:** `start`
### Media
Enable or disable **Show card media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `disabled`
Enable or disable **Reverse layout on mobile**.
It has the strongest effect on layout balance and visual hierarchy.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
Reverses the layout of the card on mobile.
Choose how **Media position** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Top, Bottom, Start, End, Background.
**Default:** `bottom`
This setting only appears when its related parent option is enabled.
Desktop and tablet only. Automatically adjusted for mobile.
Enable or disable **Stack on mobile**.
**Default:** `enabled`
This setting only appears when its related parent option is enabled.
When enabled, media and content stack vertically on mobile devices. Only applies when media position is set to Left or Right.
Adjust **Media width** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `2` to `12` **Default:** `6`
This setting only appears when its related parent option is enabled.
If you set 0, media will use automatic width.
Choose how **Object fit** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** Cover, Contain.
**Default:** `cover`
This setting only appears when its related parent option is enabled.
Choose how **Show on** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
This setting only appears when its related parent option is enabled.
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
Choose how **Aspect ratio** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Auto, Square, 4:3, 3:4, 3:2, 2:3, 5:4, 4:5, 16:9, 9:16, 2:1, 4:1, 8:1, 1:2.
**Default:** `auto`
This setting only appears when its related parent option is enabled.
Enable or disable **Enable mobile specific media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
Displays mobile-specific alternative media. Add a media before setting a mobile alternative.
### Media for mobile
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
Choose how **Aspect ratio** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Auto, Square, 4:3, 3:4, 3:2, 2:3, 5:4, 4:5, 16:9, 9:16, 2:1, 4:1, 8:1, 1:2.
**Default:** `auto`
This setting only appears when its related parent option is enabled.
**Supports nested blocks:**
* **Icon Svg** for more granular content inside this block.
* **Heading** for more granular content inside this block.
* **Text** for more granular content inside this block.
* **Button** for more granular content inside this block.
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Interactive Popup
Source: https://docs.digifist.com/themes/everest/sections/interactive-popup
Configure Everest's interactive popup section and its main settings, content structure, and styling controls.
The Interactive Popup section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Headings, text content, and on-page messaging
* Images, videos, and other media presentation options
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
* Block types such as Heading, Text, Form Newsletter, Button Group and more
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Interactive Popup** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
Add, remove, or reorder blocks after the main layout feels right so content hierarchy stays easier to manage.
## Section settings
### Settings
Enable or disable **Show on customizer**.
**Default:** `disabled`
Choose how **Popup type** behaves in the section.
**Available options:** Newsletter signup, Age verification, Custom.
**Default:** `custom`
Sets the popup type used for its behavior and targeting.
Adjust **Delay** with a slider-based control.
**Range:** `1` to `20` **Default:** `10s`
### Content
Choose how **Vertical alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⤒, Center, ⤓.
**Default:** `start`
Choose how **Horizontal alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⇤, Center, ⇥.
**Default:** `start`
Enable or disable **Show interactive popup media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `enabled`
### Media
Choose how **Show on** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
This setting only appears when its related parent option is enabled.
Choose how **Media position** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Start, End.
**Default:** `start`
This setting only appears when its related parent option is enabled.
Desktop and tablet only. Automatically adjusted for mobile.
Choose how **Aspect ratio** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Auto, Square, 4:3, 3:4, 3:2, 2:3, 5:4, 4:5, 16:9, 9:16, 2:1, 4:1, 8:1, 1:2.
**Default:** `auto`
This setting only appears when its related parent option is enabled.
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
Enable or disable **Enable mobile specific media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
Displays mobile-specific alternative media. Add a media before setting a mobile alternative.
### Media for mobile
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
### Common settings
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
## Block settings
### Heading
This block controls the **heading** content used inside the Interactive Popup section.
### Settings
Choose how **Show on** behaves in the section.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
Choose how **HTML tag** behaves in the section.
**Available options:** H1, H2, H3.
**Default:** `h3`
Useful for SEO and accessibility.
Enter the content used for **heading**.
Choose how **Heading size** behaves in the section.
**Available options:** XS, S, M, L, ↺.
**Default:** `default`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `0`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `sm`
### Text
This block controls the **text** content used inside the Interactive Popup section.
### Settings
Choose how **Show on** behaves in the section.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
Adjust **Line count** with a slider-based control.
**Range:** `0` to `10` **Default:** `0`
Text truncate to the specified number of lines. If you set 0, the text will not be truncated.
Enter the content used for **text**.
Choose how **Text size** behaves in the section.
**Available options:** XS, S, M, L.
**Default:** `sm`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `0`
### Form Newsletter
This block controls the **form newsletter** content used inside the Interactive Popup section.
### Settings
Enable or disable **Show label**.
**Default:** `enabled`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `0`
### Button Group
This block controls the **button group** content used inside the Interactive Popup section.
### Settings
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, Auto.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, Auto.
**Default:** `0`
Choose how **Space between** behaves in the section.
**Available options:** S, M, L, XL.
**Default:** `4`
Space between buttons, optimized for mobile
**Supports nested blocks:**
* **Button** for more granular content inside this block.
### Age Verification Actions
This block controls the **age verification actions** content used inside the Interactive Popup section.
### Confirm button
Enter the content used for **button label**.
Keep action labels short so they remain readable across devices.
**Default:** `Yes`
Choose how **Button style** behaves in the section.
Keep action labels short so they remain readable across devices.
**Available options:** Filled, Outlined, Text.
**Default:** `filled`
Choose how **Button width** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Auto, ↔.
**Default:** `full`
### Decline button
Enter the content used for **button label**.
Keep action labels short so they remain readable across devices.
**Default:** `No`
Set the destination URL for **button link**.
Keep action labels short so they remain readable across devices.
**Default:** `/`
Choose how **Button style** behaves in the section.
Keep action labels short so they remain readable across devices.
**Available options:** Filled, Outlined, Text.
**Default:** `outlined`
Choose how **Button width** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Auto, ↔.
**Default:** `full`
### Common settings
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Review media-heavy layouts on both desktop and mobile before publishing.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Map
Source: https://docs.digifist.com/themes/everest/sections/map
Configure Everest's map section and its main settings, content structure, and styling controls.
The Map section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Map** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
## Section settings
### Settings
Choose how **Section height** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Fixed, Half, Full.
**Default:** `36rem`
Enter the content used for **google maps api key**.
To display a map, you need a Google Maps API key. [Learn more](https://support.google.com/googleapi/answer/6158862?hl=en)
Enter the content used for **address**.
Adjust **Zoom level** with a slider-based control.
**Range:** `0` to `21` **Default:** `16`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Marquee
Source: https://docs.digifist.com/themes/everest/sections/marquee
Configure Everest's marquee section and its main settings, content structure, and styling controls.
The Marquee section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Headings, text content, and on-page messaging
* Color schemes, contrast, and shared visual styling
* Block types such as Item
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Marquee** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
Add, remove, or reorder blocks after the main layout feels right so content hierarchy stays easier to manage.
## Section settings
### Settings
Enable or disable **Enable animation**.
**Default:** `enabled`
Adjust **Animation speed** with a slider-based control.
**Range:** `1` to `10` **Default:** `5`
The higher the number, the slower the animation.
Adjust **Text size** with a slider-based control.
**Range:** `1.2` to `12.0` **Default:** `12rem`
Adjust **Text size for mobile** with a slider-based control.
**Range:** `1.2` to `4.0` **Default:** `4rem`
Adjust **Item spacing** with a slider-based control.
**Range:** `0` to `6` **Default:** `4.8`
### Common settings
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Block settings
### Item
This block controls the **item** content used inside the Marquee section.
This block does not expose additional documented settings beyond its placement and content usage.
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Multicolumn
Source: https://docs.digifist.com/themes/everest/sections/multicolumn
Configure Everest's multicolumn section and its main settings, content structure, and styling controls.
The Multicolumn section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Headings, text content, and on-page messaging
* Layout structure, width, alignment, and spacing
* Calls to action, links, and navigation behavior
* Color schemes, contrast, and shared visual styling
* Block types such as Card
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Multicolumn** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
Add, remove, or reorder blocks after the main layout feels right so content hierarchy stays easier to manage.
## Section settings
### Layout
Choose how **Desktop** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Grid, Carousel.
**Default:** `grid`
Choose how **Mobile** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Grid, Carousel.
**Default:** `grid`
### Number of columns
Adjust **Desktop** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `1` to `12` **Default:** `3`
Adjust **Mobile** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `1` to `2` **Default:** `1`
### Carousel layout
Choose how **Navigation** behaves in the section.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Available options:** None, 1, 2.
**Default:** `style-1`
Select the color scheme used for **color for navigation**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Enable or disable **Overflow**.
**Default:** `disabled`
Overflow is available only when the featured card layout is normal.
### Default settings for blocks
Choose how **Heading size** behaves in the section.
**Available options:** XS, S, M, L, XL.
**Default:** `h1`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Block settings
### Card
This block controls the **card** content used inside the Multicolumn section.
### Settings
Choose how **Corner radius** behaves in the section.
**Available options:** No, S, M, L, ↺.
**Default:** `default`
### Style
Choose how **Card frame** behaves in the section.
**Available options:** None, Border.
**Default:** `border`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
### Content
Choose how **Show on** behaves in the section.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
Choose how **Content padding** behaves in the section.
**Available options:** No, S, M, L, ↺.
**Default:** `default`
### Desktop alignment
Choose how **Vertical alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⤒, Center, ⤓.
**Default:** `start`
Choose how **Horizontal alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⇤, Center, ⇥.
**Default:** `start`
### Mobile alignment
Choose how **Vertical alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⤒, Center, ⤓.
**Default:** `start`
Choose how **Horizontal alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⇤, Center, ⇥.
**Default:** `start`
### Media
Enable or disable **Show card media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `disabled`
Enable or disable **Reverse layout on mobile**.
It has the strongest effect on layout balance and visual hierarchy.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
Reverses the layout of the card on mobile.
Choose how **Media position** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Top, Bottom, Start, End, Background.
**Default:** `bottom`
This setting only appears when its related parent option is enabled.
Desktop and tablet only. Automatically adjusted for mobile.
Enable or disable **Stack on mobile**.
**Default:** `enabled`
This setting only appears when its related parent option is enabled.
When enabled, media and content stack vertically on mobile devices. Only applies when media position is set to Left or Right.
Adjust **Media width** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `2` to `12` **Default:** `6`
This setting only appears when its related parent option is enabled.
If you set 0, media will use automatic width.
Choose how **Object fit** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** Cover, Contain.
**Default:** `cover`
This setting only appears when its related parent option is enabled.
Choose how **Show on** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
This setting only appears when its related parent option is enabled.
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
Choose how **Aspect ratio** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Auto, Square, 4:3, 3:4, 3:2, 2:3, 5:4, 4:5, 16:9, 9:16, 2:1, 4:1, 8:1, 1:2.
**Default:** `auto`
This setting only appears when its related parent option is enabled.
Enable or disable **Enable mobile specific media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
Displays mobile-specific alternative media. Add a media before setting a mobile alternative.
### Media for mobile
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
Choose how **Aspect ratio** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Auto, Square, 4:3, 3:4, 3:2, 2:3, 5:4, 4:5, 16:9, 9:16, 2:1, 4:1, 8:1, 1:2.
**Default:** `auto`
This setting only appears when its related parent option is enabled.
**Supports nested blocks:**
* **Icon Svg** for more granular content inside this block.
* **Heading** for more granular content inside this block.
* **Text** for more granular content inside this block.
* **Button** for more granular content inside this block.
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Keep labels short and scannable, especially in tighter layouts or utility areas.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Pickup Availability
Source: https://docs.digifist.com/themes/everest/sections/pickup-availability
Understand how Everest's pickup availability helper works and which sections or theme settings influence it.
Pickup availability shows store pickup information for the currently selected product variant when Shopify pickup data is available.
The output changes automatically with variant selection, making it a dynamic helper tied closely to the product page and inventory location data.
This section is typically surfaced through product-related blocks rather than as a standalone customizable section.
## What this feature controls
* Store pickup availability for the selected product variant
* Pickup timing, store details, and availability messaging
* The pickup drawer content used when shoppers request more detail
## How it is configured
Start in the Theme Customizer or the related theme settings category that controls this feature.
Review the product, header, cart, or search area that surfaces this helper so you can understand where the storefront output comes from.
Because these helpers react to live cart, product, or search data, verify the result with realistic content before publishing.
## Key implementation notes
Pickup availability updates when the selected variant changes, so the feature should always be tested across actual variant combinations.
The feature only appears when Shopify pickup locations and inventory data are available for the selected product.
In Everest, this helper is most relevant as part of the product information flow rather than as a standalone merchandising section.
## Best practices
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
* [Product Page](/themes/everest/products/product-page)
# Predictive Search
Source: https://docs.digifist.com/themes/everest/sections/predictive-search
Understand how Everest's predictive search helper works and which sections or theme settings influence it.
Predictive search powers the live search results shown from Everest's search UI in the header and search overlay.
It can return queries, collections, pages, articles, and products, with product cards optionally showing vendor and price information.
Its behavior depends heavily on global search settings, so Theme settings and search snippet behavior matter as much as the template markup.
## What this feature controls
* Live search suggestions and grouped search result types
* Product, collection, page, article, and query previews
* Search UI behavior that depends on global search settings
## How it is configured
Start in the Theme Customizer or the related theme settings category that controls this feature.
Review the product, header, cart, or search area that surfaces this helper so you can understand where the storefront output comes from.
Because these helpers react to live cart, product, or search data, verify the result with realistic content before publishing.
## Key implementation notes
Predictive search can show queries, collections, pages, articles, and products in grouped result areas.
Global search settings control which product details appear and how the broader live-search experience behaves.
The feature is closely tied to the search UI rendered from the header and search snippet components.
## Best practices
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
* [Search Settings](/themes/everest/theme-settings/search)
# Quick Links
Source: https://docs.digifist.com/themes/everest/sections/quick-links
Configure Everest's quick links section and its main settings, content structure, and styling controls.
The Quick Links section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Headings, text content, and on-page messaging
* Images, videos, and other media presentation options
* Layout structure, width, alignment, and spacing
* Calls to action, links, and navigation behavior
* Color schemes, contrast, and shared visual styling
* Block types such as Quick Link
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Quick Links** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
Add, remove, or reorder blocks after the main layout feels right so content hierarchy stays easier to manage.
## Section settings
### Layout
Choose how **Desktop** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Grid, Carousel.
**Default:** `grid`
Choose how **Mobile** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Grid, Carousel.
**Default:** `grid`
### Number of columns
Adjust **Desktop** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `1` to `12` **Default:** `3`
Adjust **Mobile** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `1` to `2.4` **Default:** `1`
### Carousel layout
Choose how **Navigation** behaves in the section.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Available options:** None, 1, 2.
**Default:** `none`
Select the color scheme used for **color for navigation**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Pagination** behaves in the section.
**Available options:** None, Dots, Dynamic, Progress.
**Default:** `none`
Enable or disable **Overflow**.
**Default:** `disabled`
Overflow is available only when the featured card layout is normal.
### Card
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
Choose how **Card frame** behaves in the section.
**Available options:** None, Border.
**Default:** `none`
Choose how **Corner radius** behaves in the section.
**Available options:** No, S, M, L, ↺.
**Default:** `default`
Choose how **Card padding** behaves in the section.
**Available options:** No, S, M, L.
**Default:** `md`
Enable or disable **Enable auto width**.
It has the strongest effect on layout balance and visual hierarchy.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
### Content
Enable or disable **Show card labels**.
**Default:** `disabled`
Choose how **Horizontal alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⇤, Center, ⇥.
**Default:** `center`
### Media
Enable or disable **Show card media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `enabled`
Adjust **Media height** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `0.4` to `20.0` **Default:** `10.0rem`
This setting only appears when its related parent option is enabled.
Choose how **Media padding** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** No, S, M, L.
**Default:** `md`
This setting only appears when its related parent option is enabled.
Choose how **Media shape** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** Default, Square, Circle.
**Default:** `default`
This setting only appears when its related parent option is enabled.
Enable or disable **Enable mix blend mode**.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
Applies blend mode effect to the media based on the mix blend color.
Controls **mix blend color**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `#f1f1f1`
This setting only appears when its related parent option is enabled.
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Block settings
### Quick Link
This block controls the **quick link** content used inside the Quick Links section.
### Settings
Set the destination URL for **card link**.
Keep action labels short so they remain readable across devices.
Enter the content used for **card label**.
This setting only appears when its related parent option is enabled.
If left blank, the card label will use the linked page's title.
### Media
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
Choose how **Aspect ratio** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Default, Auto, 1:1, 4:3, 3:4, 3:2, 2:3, 5:4, 4:5, 16:9, 9:16, 2:1, 4:1, 8:1, 1:2.
**Default:** `auto`
This setting only appears when its related parent option is enabled.
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Review media-heavy layouts on both desktop and mobile before publishing.
* Keep labels short and scannable, especially in tighter layouts or utility areas.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Quick Order List
Source: https://docs.digifist.com/themes/everest/sections/quick-order-list
Configure Everest's quick order list section and its main settings, content structure, and styling controls.
The Quick Order List section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Images, videos, and other media presentation options
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Quick Order List** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
## Section settings
### Settings
Enable or disable **Show images**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `disabled`
Enable or disable **Show SKUs**.
**Default:** `disabled`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Review media-heavy layouts on both desktop and mobile before publishing.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Recently Viewed Products
Source: https://docs.digifist.com/themes/everest/sections/recently-viewed-products
Configure Everest's recently viewed products section and its main settings, content structure, and styling controls.
The Recently Viewed Products section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Layout structure, width, alignment, and spacing
* Calls to action, links, and navigation behavior
* Color schemes, contrast, and shared visual styling
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Recently Viewed Products** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
## Section settings
### Settings
This section’s product cards are generated through search, based on the customer’s browsing history, so the product card setup is handled through search page.
Choose how **Layout** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Grid, Carousel.
**Default:** `grid`
Choose how **Mobile** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Grid, Carousel.
**Default:** `grid`
### Number of columns
Adjust **Desktop** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `1` to `6` **Default:** `3`
Adjust **Mobile** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `1` to `2.4` **Default:** `1`
### Carousel layout
Choose how **Navigation** behaves in the section.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Available options:** None, 1, 2.
**Default:** `style-1`
This setting only appears when its related parent option is enabled.
Select the color scheme used for **color for navigation**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
This setting only appears when its related parent option is enabled.
Enable or disable **Overflow**.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
Overflow is available only when the featured card layout is normal.
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Keep labels short and scannable, especially in tighter layouts or utility areas.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Related Products
Source: https://docs.digifist.com/themes/everest/sections/related-products
Configure Everest's related products section and its main settings, content structure, and styling controls.
The Related Products section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Layout structure, width, alignment, and spacing
* Calls to action, links, and navigation behavior
* Product, collection, or cart-related storefront behavior
* Color schemes, contrast, and shared visual styling
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Related Products** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
## Section settings
### Settings
Dynamic recommendations use order and product information to change and improve over time. [Learn more](https://help.shopify.com/themes/development/recommended-products)
Adjust **Maximum products to show** with a slider-based control.
**Range:** `2` to `10` **Default:** `4`
Choose how **Layout** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Grid, Carousel.
**Default:** `carousel`
### Number of columns
Adjust **Desktop** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `1` to `6` **Default:** `3`
Adjust **Mobile** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `1` to `1.4` **Default:** `1`
### Carousel layout
Choose how **Navigation** behaves in the section.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Available options:** None, 1, 2.
**Default:** `style-1`
This setting only appears when its related parent option is enabled.
Select the color scheme used for **color for navigation**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
This setting only appears when its related parent option is enabled.
Choose how **Display** behaves in the section.
**Available options:** Full, Partial.
**Default:** `partial`
Enable or disable **Overflow**.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
Overflow is available only when the featured card layout is normal.
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Keep labels short and scannable, especially in tighter layouts or utility areas.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Rich Text
Source: https://docs.digifist.com/themes/everest/sections/rich-text
Configure Everest's rich text section and its main settings, content structure, and styling controls.
The Rich Text section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Headings, text content, and on-page messaging
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
* Block types such as Heading, Text, Button Group
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Rich Text** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
Add, remove, or reorder blocks after the main layout feels right so content hierarchy stays easier to manage.
## Section settings
### Content
Choose how **Content width** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Small, Medium, Large, Page, Fluid, Full.
**Default:** `page`
Choose how **Horizontal alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⇤, Center, ⇥.
**Default:** `center`
Automatically adjusted for mobile.
Select the color scheme used for **color for content**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Block settings
### Heading
This block controls the **heading** content used inside the Rich Text section.
### Settings
Choose how **Show on** behaves in the section.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
Choose how **HTML tag** behaves in the section.
**Available options:** H1, H2, H3.
**Default:** `h3`
Useful for SEO and accessibility.
Enter the content used for **heading**.
Choose how **Heading size** behaves in the section.
**Available options:** XS, S, M, L, ↺.
**Default:** `default`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `0`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `sm`
### Text
This block controls the **text** content used inside the Rich Text section.
### Settings
Choose how **Show on** behaves in the section.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
Adjust **Line count** with a slider-based control.
**Range:** `0` to `10` **Default:** `0`
Text truncate to the specified number of lines. If you set 0, the text will not be truncated.
Enter the content used for **text**.
Choose how **Text size** behaves in the section.
**Available options:** XS, S, M, L.
**Default:** `sm`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `0`
### Button Group
This block controls the **button group** content used inside the Rich Text section.
### Settings
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, Auto.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, Auto.
**Default:** `0`
Choose how **Space between** behaves in the section.
**Available options:** S, M, L, XL.
**Default:** `4`
Space between buttons, optimized for mobile
**Supports nested blocks:**
* **Button** for more granular content inside this block.
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Sidebar Menu
Source: https://docs.digifist.com/themes/everest/sections/sidebar-menu
Configure Everest's sidebar menu section and its main settings, content structure, and styling controls.
The Sidebar Menu section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Calls to action, links, and navigation behavior
* Color schemes, contrast, and shared visual styling
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Sidebar Menu** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
## Section settings
### Settings
Select the Shopify menu used for **menu**.
Make sure the chosen option still feels easy to scan and use on smaller screens.
Select a menu to display in the sidebar.
Enter the content used for **menu label for mobile**.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Default:** `Collections`
### Common settings
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Keep labels short and scannable, especially in tighter layouts or utility areas.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Store Locator
Source: https://docs.digifist.com/themes/everest/sections/store-locator
Configure Everest's store locator section and its main settings, content structure, and styling controls.
The Store Locator section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Layout structure, width, alignment, and spacing
* Search, filter, and sorting behavior for product discovery
* Color schemes, contrast, and shared visual styling
* Block types such as Pin
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Store Locator** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
Add, remove, or reorder blocks after the main layout feels right so content hierarchy stays easier to manage.
## Section settings
### Settings
Choose how **Layout** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Image, Map.
**Default:** `map`
Each pin supports its own image.
### Map
Enter the content used for **google maps api key**.
To display a map, you need a Google Maps API key. [Learn more](https://support.google.com/googleapi/answer/6158862?hl=en)
Adjust **Zoom level** with a slider-based control.
**Range:** `0` to `21` **Default:** `4`
Enable or disable **Show store list**.
**Default:** `enabled`
### Search bar
Select the color scheme used for **color for search bar**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
### Common settings
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Block settings
### Pin
This block controls the **pin** content used inside the Store Locator section.
This block does not expose additional documented settings beyond its placement and content usage.
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Testimonials
Source: https://docs.digifist.com/themes/everest/sections/testimonials
Configure Everest's testimonials section and its main settings, content structure, and styling controls.
The Testimonials section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Layout structure, width, alignment, and spacing
* Calls to action, links, and navigation behavior
* Color schemes, contrast, and shared visual styling
* Block types such as Testimonial
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Testimonials** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
Add, remove, or reorder blocks after the main layout feels right so content hierarchy stays easier to manage.
## Section settings
### Number of columns
Adjust **Desktop** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `1` to `6` **Default:** `3`
Adjust **Mobile** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `1` to `1.4` **Default:** `1`
### Carousel layout
Choose how **Pagination** behaves in the section.
**Available options:** None, Dots, Progress, Dynamic.
**Default:** `dots`
Choose how **Navigation** behaves in the section.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Available options:** None, 1, 2.
**Default:** `style-1`
Select the color scheme used for **color for navigation**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Enable or disable **Overflow**.
**Default:** `disabled`
Overflow is available only when the featured card layout is normal.
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Block settings
### Testimonial
This block controls the **testimonial** content used inside the Testimonials section.
### Settings
Choose how **Corner radius** behaves in the section.
**Available options:** No, S, M, L, ↺.
**Default:** `default`
### Style
Choose how **Card frame** behaves in the section.
**Available options:** None, Border.
**Default:** `border`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
### Content
Choose how **Show on** behaves in the section.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
Choose how **Content padding** behaves in the section.
**Available options:** No, S, M, L, ↺.
**Default:** `default`
Choose how **Vertical alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⤒, Center, ⤓.
**Default:** `start`
Choose how **Horizontal alignment** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** ⇤, Center, ⇥.
**Default:** `start`
Enable or disable **Show card media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `disabled`
### Media
Choose how **Media position** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Top, Bottom, Start, End, Background.
**Default:** `top`
This setting only appears when its related parent option is enabled.
Desktop and tablet only. Automatically adjusted for mobile.
Adjust **Media width** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `2` to `12` **Default:** `6`
This setting only appears when its related parent option is enabled.
If you set 0, media will use automatic width.
Choose how **Show on** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** Desktop, Mobile, Both.
**Default:** `both`
This setting only appears when its related parent option is enabled.
Choose how **Object fit** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** Cover, Contain.
**Default:** `cover`
This setting only appears when its related parent option is enabled.
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
Enable or disable **Enable mobile specific media**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `disabled`
This setting only appears when its related parent option is enabled.
Displays mobile-specific alternative media. Add a media before setting a mobile alternative.
### Media for mobile
Upload or choose an image for **image**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
This setting only appears when its related parent option is enabled.
Overwrites the image and video. We recommend above video option for better performance, external videos can cause performance issues. Use a YouTube or Vimeo URL.
**Supports nested blocks:**
* **Text** for more granular content inside this block.
* **Button** for more granular content inside this block.
* **Divider** for more granular content inside this block.
* **Rating** for more granular content inside this block.
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Keep labels short and scannable, especially in tighter layouts or utility areas.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Video
Source: https://docs.digifist.com/themes/everest/sections/video
Configure Everest's video section and its main settings, content structure, and styling controls.
The Video section lets you control the content, layout, and presentation of this part of the Everest storefront. Most changes happen directly in the Theme Customizer, so you can adjust structure first and then refine styling, spacing, and supporting blocks with confidence.
## What this section controls
* Headings, text content, and on-page messaging
* Images, videos, and other media presentation options
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
## Getting started
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Add the **Video** section to a compatible template or select the existing section from the left sidebar.
Start with the structural settings such as layout, width, color scheme, spacing, or content source before refining smaller details.
## Section settings
### Settings
Shows when no Shopify-hosted video is selected.
Enter the content used for **heading**.
**Default:** `t:sections.video.settings.heading.default`
Choose how **Heading size** behaves in the section.
**Available options:** XS, S, M, L, XL.
**Default:** `h1`
Enable or disable **Play video on loop**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `disabled`
Choose a hosted video for **video**.
Review the result on both desktop and mobile when media changes are involved.
Paste an external video URL for **external video**.
Review the result on both desktop and mobile when media changes are involved.
**Default:** `https://www.youtube.com/watch?v=_9VUPq3SxOc`
Use a YouTube or Vimeo URL
Upload or choose an image for **cover image**.
Review the result on both desktop and mobile when media changes are involved.
Enter the content used for **video alt text**.
Review the result on both desktop and mobile when media changes are involved.
Describe the video for customers using screen readers. [Learn more](https://help.shopify.com/manual/online-store/themes/theme-structure/theme-features#video)
### Style
Enable or disable **Make section full width**.
It has the strongest effect on layout balance and visual hierarchy.
**Default:** `disabled`
### Common settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid, Full.
**Default:** `page`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Section border** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** None, Top, Bottom, Both.
**Default:** `none`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Review media-heavy layouts on both desktop and mobile before publishing.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Start with the structural settings first, then refine decorative styling after the layout feels settled.
* Preview the section with realistic content length to catch spacing and wrapping issues early.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Badges
Source: https://docs.digifist.com/themes/everest/theme-settings/badges
Configure Everest's global badges settings and the shared behavior they control across the store.
The Badges settings control shared theme behavior across Everest. Because these values affect multiple sections and templates at once, they are best used to set global design direction and core storefront behavior before adjusting individual sections.
## What these settings control
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
## How to access
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Select **Theme settings** in the customizer sidebar.
Open **Badges** to review and update the shared settings in this category.
## Settings
### Settings
Choose how **Badge position** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Bottom left, Bottom right, Top left, Top right.
**Default:** `top right`
Adjust **Badge corner radius** with a slider-based control.
**Range:** `0` to `40` **Default:** `40px`
Select the color scheme used for **sale badge color**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-5`
Select the color scheme used for **sold out badge color**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-3`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Change one global setting area at a time and preview multiple templates before publishing.
* Remember that theme settings affect many sections at once, so small adjustments can have wide impact.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
# Brand
Source: https://docs.digifist.com/themes/everest/theme-settings/brand
Configure Everest's global brand settings and the shared behavior they control across the store.
The Brand settings control shared theme behavior across Everest. Because these values affect multiple sections and templates at once, they are best used to set global design direction and core storefront behavior before adjusting individual sections.
## What these settings control
* Headings, text content, and on-page messaging
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
## How to access
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Select **Theme settings** in the customizer sidebar.
Open **Brand** to review and update the shared settings in this category.
## Settings
### Settings
Enter the content used for **headline**.
Enter the content used for **description**.
Upload or choose an image for **logo**.
Paste custom HTML or SVG code for **logo svg**.
SVG is recommended for better quality and performance. Overwrites logo image.
Enable or disable **Use text for logo**.
**Default:** `enabled`
Overwrites the image and svg
Enter the content used for **logo text**.
**Default:** `Everest`
This setting only appears when its related parent option is enabled.
Select the color scheme used for **logo color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-3`
This setting only appears when its related parent option is enabled.
Adjust **Logo width** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `50` to `300` **Default:** `100px`
This setting only appears when its related parent option is enabled.
Adjust **Logo width in footer** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `50` to `550` **Default:** `100px`
This setting only appears when its related parent option is enabled.
Upload or choose an image for **favicon image**.
Review the result on both desktop and mobile when media changes are involved.
Will be scaled down to 32 x 32px
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Change one global setting area at a time and preview multiple templates before publishing.
* Remember that theme settings affect many sections at once, so small adjustments can have wide impact.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Everest Header](/themes/everest/header/header)
# Buttons and Inputs
Source: https://docs.digifist.com/themes/everest/theme-settings/buttons-and-inputs
Configure Everest's global buttons and inputs settings and the shared behavior they control across the store.
The Buttons and Inputs settings control shared theme behavior across Everest. Because these values affect multiple sections and templates at once, they are best used to set global design direction and core storefront behavior before adjusting individual sections.
## What these settings control
* Headings, text content, and on-page messaging
* Layout structure, width, alignment, and spacing
* Calls to action, links, and navigation behavior
* Color schemes, contrast, and shared visual styling
## How to access
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Select **Theme settings** in the customizer sidebar.
Open **Buttons and Inputs** to review and update the shared settings in this category.
## Settings
### Settings
Controls **font**.
Keep action labels short so they remain readable across devices.
**Default:** `figtree_n6`
Adjust **Font size scale** with a slider-based control.
Keep action labels short so they remain readable across devices.
**Range:** `50` to `200` **Default:** `100%`
Choose how **Letter spacing (em)** behaves in the section.
Keep action labels short so they remain readable across devices.
**Available options:** -0.05, -0.025, 0, 0.025, 0.05.
**Default:** `-0.025em`
Choose how **Text transform** behaves in the section.
Keep action labels short so they remain readable across devices.
**Available options:** None, Uppercase, Capitalize.
**Default:** `none`
Choose how **Button shape** behaves in the section.
Keep action labels short so they remain readable across devices.
**Available options:** Square, Rounded, Diagonal.
**Default:** `rounded`
Adjust **Button radius (rem)** with a slider-based control.
Keep action labels short so they remain readable across devices.
**Range:** `0` to `8` **Default:** `0.8`
Adjust **Button border opacity** with a slider-based control.
Keep action labels short so they remain readable across devices.
**Range:** `0` to `100` **Default:** `100%`
Choose how **Icon stroke width** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Light, Medium, Bold.
**Default:** `1.5`
Choose how **Icon corner shape** behaves in the section.
**Available options:** Rounded, Sharp.
**Default:** `round`
Only for icons with corner option.
## Best practices
* Keep labels short and scannable, especially in tighter layouts or utility areas.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Change one global setting area at a time and preview multiple templates before publishing.
* Remember that theme settings affect many sections at once, so small adjustments can have wide impact.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
# Cards
Source: https://docs.digifist.com/themes/everest/theme-settings/cards
Configure Everest's global cards settings and the shared behavior they control across the store.
The Cards settings control shared theme behavior across Everest. Because these values affect multiple sections and templates at once, they are best used to set global design direction and core storefront behavior before adjusting individual sections.
## What these settings control
* Headings, text content, and on-page messaging
* Images, videos, and other media presentation options
* Color schemes, contrast, and shared visual styling
## How to access
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Select **Theme settings** in the customizer sidebar.
Open **Cards** to review and update the shared settings in this category.
## Settings
### Settings
Choose how **Card style** behaves in the section.
**Available options:** Standard, Card.
**Default:** `standard`
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-2`
Choose how **Shape** behaves in the section.
**Available options:** Square, Rounded, Diagonal.
**Default:** `rounded`
Enable or disable **Enable card shadow**.
**Default:** `enabled`
Adds a subtle shadow to cards.
Adjust **Corner radius** with a slider-based control.
**Range:** `0` to `8` **Default:** `0.8rem`
This setting only appears when its related parent option is enabled.
Choose how **Media ratio** behaves in the section.
It has the strongest effect on layout balance and visual hierarchy.
**Available options:** Auto, 3:4, 1:1, 4:5.
**Default:** `auto`
Choose how **Media padding** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** No, S, M, L, XL.
**Default:** `4`
Choose how **Content padding** behaves in the section.
**Available options:** No, S, M, L.
**Default:** `md`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Review media-heavy layouts on both desktop and mobile before publishing.
* Change one global setting area at a time and preview multiple templates before publishing.
* Remember that theme settings affect many sections at once, so small adjustments can have wide impact.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
# Cart
Source: https://docs.digifist.com/themes/everest/theme-settings/cart
Configure Everest's global cart settings and the shared behavior they control across the store.
The Cart settings control shared theme behavior across Everest. Because these values affect multiple sections and templates at once, they are best used to set global design direction and core storefront behavior before adjusting individual sections.
## What these settings control
* Product, collection, or cart-related storefront behavior
* Color schemes, contrast, and shared visual styling
## How to access
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Select **Theme settings** in the customizer sidebar.
Open **Cart** to review and update the shared settings in this category.
## Settings
### Settings
Choose how **Cart type** behaves in the section.
**Available options:** Drawer, Page, Popup notification.
**Default:** `notification`
Choose how **Show vendor on** behaves in the section.
**Available options:** None, Drawer, Cart page, Both.
**Default:** `none`
Choose how **Free shipping notification** behaves in the section.
**Available options:** None, Drawer, Cart page, Both.
**Default:** `both`
Enter the content used for **free shipping threshold**.
**Default:** `150`
Choose how **Cart note** behaves in the section.
**Available options:** None, Drawer.
**Default:** `none`
Use note block for cart page.
Choose how **Cart upsell** behaves in the section.
**Available options:** None, Drawer.
**Default:** `none`
Use upsell block for cart page.
### Cart drawer
Select the collection source used by **collection**.
Visible when cart drawer is empty.
Select the color scheme used for **color scheme**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Change one global setting area at a time and preview multiple templates before publishing.
* Remember that theme settings affect many sections at once, so small adjustments can have wide impact.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Cart Template](/themes/everest/pages-templates/cart)
# Colors
Source: https://docs.digifist.com/themes/everest/theme-settings/colors
Configure Everest's global colors settings and the shared behavior they control across the store.
The Colors settings control shared theme behavior across Everest. Because these values affect multiple sections and templates at once, they are best used to set global design direction and core storefront behavior before adjusting individual sections.
## What these settings control
* Color schemes, contrast, and shared visual styling
## How to access
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Select **Theme settings** in the customizer sidebar.
Open **Colors** to review and update the shared settings in this category.
## Settings
### Settings
Controls **color schemes**.
Use this to keep contrast and branding consistent with the rest of the store.
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Change one global setting area at a time and preview multiple templates before publishing.
* Remember that theme settings affect many sections at once, so small adjustments can have wide impact.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
# Customer Account
Source: https://docs.digifist.com/themes/everest/theme-settings/customer-account
Configure Everest's global customer account settings and the shared behavior they control across the store.
The Customer Account settings control shared theme behavior across Everest. Because these values affect multiple sections and templates at once, they are best used to set global design direction and core storefront behavior before adjusting individual sections.
## What these settings control
* Layout structure, width, alignment, and spacing
## How to access
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Select **Theme settings** in the customizer sidebar.
Open **Customer Account** to review and update the shared settings in this category.
## Settings
### Settings
Choose how **Section width** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** Page, Fluid.
**Default:** `page`
Choose how **Top spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Choose how **Bottom spacing** behaves in the section.
This setting shapes the section container and how it sits against surrounding content.
**Available options:** No, S, M, L, XL.
**Default:** `2`
Enable or disable **Enable sign in with Shop login**.
**Default:** `disabled`
## Best practices
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Change one global setting area at a time and preview multiple templates before publishing.
* Remember that theme settings affect many sections at once, so small adjustments can have wide impact.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Customer Accounts](/themes/everest/pages-templates/customer-accounts)
# Features
Source: https://docs.digifist.com/themes/everest/theme-settings/features
Configure Everest's global features settings and the shared behavior they control across the store.
The Features settings control shared theme behavior across Everest. Because these values affect multiple sections and templates at once, they are best used to set global design direction and core storefront behavior before adjusting individual sections.
## What these settings control
* Images, videos, and other media presentation options
## How to access
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Select **Theme settings** in the customizer sidebar.
Open **Features** to review and update the shared settings in this category.
## Settings
### Settings
Choose how **Enable breadcrumbs on** behaves in the section.
**Available options:** None, Products, Pages, All.
**Default:** `all`
Enable or disable **Show currency code**.
**Default:** `enabled`
### Performance
Choose how **Image optimization** behaves in the section.
Review the result on both desktop and mobile when media changes are involved.
**Available options:** Best detailed, Optimized.
**Default:** `true`
Optimized option will improve performance and reduce bandwidth usage of your store. Best detailed option will keep the original image quality.
Enable or disable **Reveal sections on scroll**.
**Default:** `enabled`
## Best practices
* Review media-heavy layouts on both desktop and mobile before publishing.
* Change one global setting area at a time and preview multiple templates before publishing.
* Remember that theme settings affect many sections at once, so small adjustments can have wide impact.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
# Layout
Source: https://docs.digifist.com/themes/everest/theme-settings/layout
Configure Everest's global layout settings and the shared behavior they control across the store.
The Layout settings control shared theme behavior across Everest. Because these values affect multiple sections and templates at once, they are best used to set global design direction and core storefront behavior before adjusting individual sections.
## What these settings control
* Headings, text content, and on-page messaging
* Layout structure, width, alignment, and spacing
* Color schemes, contrast, and shared visual styling
## How to access
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Select **Theme settings** in the customizer sidebar.
Open **Layout** to review and update the shared settings in this category.
## Settings
### Settings
Adjust **Page width** with a slider-based control.
It has the strongest effect on layout balance and visual hierarchy.
**Range:** `720` to `1920` **Default:** `1440px`
Adjust **Section spacing unit size** with a slider-based control.
**Range:** `0.2` to `2.4` **Default:** `1.6rem`
Affects the spacing between sections.
### Grid
Adjust **Grid horizontal gap** with a slider-based control.
**Range:** `0.4` to `4.0` **Default:** `0.8rem`
Adjust **Grid vertical gap** with a slider-based control.
**Range:** `0.4` to `4.0` **Default:** `0.8rem`
### Pages with sidebar
Enable or disable **Sidebar for pages**.
**Default:** `enabled`
Sidebar layout will be used for pages like contact, FAQ, about us, etc.
Select the color scheme used for **color of page**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-6`
Select the color scheme used for **color of page content**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
### Drawer
Select the color scheme used for **color for drawers**.
Use this to keep contrast and branding consistent with the rest of the store.
**Default:** `scheme-1`
## Best practices
* Check contrast after changing color schemes so text and controls remain easy to read.
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Change one global setting area at a time and preview multiple templates before publishing.
* Remember that theme settings affect many sections at once, so small adjustments can have wide impact.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
# Products
Source: https://docs.digifist.com/themes/everest/theme-settings/products
Configure Everest's global products settings and the shared behavior they control across the store.
The Products settings control shared theme behavior across Everest. Because these values affect multiple sections and templates at once, they are best used to set global design direction and core storefront behavior before adjusting individual sections.
## What these settings control
* Calls to action, links, and navigation behavior
* Product, collection, or cart-related storefront behavior
## How to access
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Select **Theme settings** in the customizer sidebar.
Open **Products** to review and update the shared settings in this category.
## Settings
### Product cards
Enable or disable **Show product rating**.
**Default:** `disabled`
Ratings are powered by the [Product Reviews](https://apps.shopify.com/product-reviews) app. Make sure you have the app installed and configured to display ratings.
Adjust **Variant options display limit** with a slider-based control.
**Range:** `2` to `6` **Default:** `3`
Enable or disable **Show product groups**.
**Default:** `enabled`
To display your product groups, add related metaobject for product groups.
Choose how **Quick add** behaves in the section.
**Available options:** None, Standard.
**Default:** `none`
Quick add is only available for products with variants. Bulk is optimized for items purchased in higher quantities.
Enable or disable **Enable comparison feature**.
Keep action labels short so they remain readable across devices.
**Default:** `enabled`
Comparison feature is only available for products with 'Product compare fields' metafield.
### Product options
Enable or disable **Show product swatches**.
**Default:** `enabled`
Swatches are shown on products when available.
### Product options
Enter the content used for **metaobject for product groups**.
This custom metaobject will be used to display the product groups.
Enter the content used for **metaobject for product options type values**.
This custom metaobject will be used to display the product options thumbnails.
## Best practices
* Keep labels short and scannable, especially in tighter layouts or utility areas.
* Change one global setting area at a time and preview multiple templates before publishing.
* Remember that theme settings affect many sections at once, so small adjustments can have wide impact.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
# Search
Source: https://docs.digifist.com/themes/everest/theme-settings/search
Configure Everest's global search settings and the shared behavior they control across the store.
The Search settings control shared theme behavior across Everest. Because these values affect multiple sections and templates at once, they are best used to set global design direction and core storefront behavior before adjusting individual sections.
## What these settings control
* Product, collection, or cart-related storefront behavior
* Search, filter, and sorting behavior for product discovery
## How to access
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Select **Theme settings** in the customizer sidebar.
Open **Search** to review and update the shared settings in this category.
## Settings
### Settings
Enable or disable **Show search in product types**.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Default:** `enabled`
### Search suggestions
Enable or disable **Enable search suggestions**.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Default:** `enabled`
Enable or disable **Show product vendor**.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Default:** `disabled`
Visible when search suggestions enabled.
Enable or disable **Show product price**.
Make sure the chosen option still feels easy to scan and use on smaller screens.
**Default:** `disabled`
Visible when search suggestions enabled.
## Best practices
* Change one global setting area at a time and preview multiple templates before publishing.
* Remember that theme settings affect many sections at once, so small adjustments can have wide impact.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
* [Search Template](/themes/everest/collections/search)
# Social Media
Source: https://docs.digifist.com/themes/everest/theme-settings/social-media
Configure Everest's global social media settings and the shared behavior they control across the store.
The Social Media settings control shared theme behavior across Everest. Because these values affect multiple sections and templates at once, they are best used to set global design direction and core storefront behavior before adjusting individual sections.
## What these settings control
* Calls to action, links, and navigation behavior
## How to access
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Select **Theme settings** in the customizer sidebar.
Open **Social Media** to review and update the shared settings in this category.
## Settings
### Share button
Enable or disable **Share on X (Twitter)**.
Keep action labels short so they remain readable across devices.
**Default:** `enabled`
Enable or disable **Share on WhatsApp**.
Keep action labels short so they remain readable across devices.
**Default:** `enabled`
Enable or disable **Share on Facebook**.
Keep action labels short so they remain readable across devices.
**Default:** `enabled`
Enable or disable **Share on Pinterest**.
Keep action labels short so they remain readable across devices.
**Default:** `enabled`
Enable or disable **Share on LinkedIn**.
Keep action labels short so they remain readable across devices.
**Default:** `enabled`
### Social accounts
Enter the content used for **facebook**.
Keep action labels short so they remain readable across devices.
Enter the content used for **instagram**.
Keep action labels short so they remain readable across devices.
Enter the content used for **youtube**.
Keep action labels short so they remain readable across devices.
Enter the content used for **tiktok**.
Keep action labels short so they remain readable across devices.
Enter the content used for **x (twitter)**.
Keep action labels short so they remain readable across devices.
Enter the content used for **linkedin**.
Keep action labels short so they remain readable across devices.
Enter the content used for **snapchat**.
Keep action labels short so they remain readable across devices.
Enter the content used for **pinterest**.
Keep action labels short so they remain readable across devices.
Enter the content used for **tumblr**.
Keep action labels short so they remain readable across devices.
Enter the content used for **vimeo**.
Keep action labels short so they remain readable across devices.
## Best practices
* Keep labels short and scannable, especially in tighter layouts or utility areas.
* Change one global setting area at a time and preview multiple templates before publishing.
* Remember that theme settings affect many sections at once, so small adjustments can have wide impact.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
# Typography
Source: https://docs.digifist.com/themes/everest/theme-settings/typography
Configure Everest's global typography settings and the shared behavior they control across the store.
The Typography settings control shared theme behavior across Everest. Because these values affect multiple sections and templates at once, they are best used to set global design direction and core storefront behavior before adjusting individual sections.
## What these settings control
* Headings, text content, and on-page messaging
## How to access
In Shopify admin, go to **Online Store** -> **Themes** -> **Customize**.
Select **Theme settings** in the customizer sidebar.
Open **Typography** to review and update the shared settings in this category.
## Settings
### Settings
Choose how **Type scale** behaves in the section.
**Available options:** Small, Medium, Large.
**Default:** `1.333`
### Heading
Controls **font**.
**Default:** `figtree_n6`
Selecting a different font from system fonts can affect the speed of your store. [Learn more about system fonts.](https://help.shopify.com/manual/online-store/os/store-speed/improving-speed#fonts)
Adjust **Font size scale** with a slider-based control.
**Range:** `50` to `200` **Default:** `100%`
Choose how **Letter spacing (em)** behaves in the section.
**Available options:** -0.05, -0.025, 0, 0.025, 0.05.
**Default:** `0em`
Choose how **Text transform** behaves in the section.
**Available options:** None, Uppercase, Capitalize.
**Default:** `none`
### Body
Controls **font**.
**Default:** `figtree_n4`
Selecting a different font from system fonts can affect the speed of your store. [Learn more about system fonts.](https://help.shopify.com/manual/online-store/os/store-speed/improving-speed#fonts)
Adjust **Font size scale** with a slider-based control.
**Range:** `100` to `200` **Default:** `100%`
Choose how **Letter spacing (em)** behaves in the section.
**Available options:** -0.05, -0.025, 0, 0.025, 0.05.
**Default:** `0.025em`
## Best practices
* Adjust layout changes alongside neighboring sections so page rhythm stays consistent.
* Change one global setting area at a time and preview multiple templates before publishing.
* Remember that theme settings affect many sections at once, so small adjustments can have wide impact.
## Related guides
* [Everest Theme Overview](/themes/everest/index)
# Icons
Source: https://docs.digifist.com/themes/icons
Customize the appearance of icons used throughout your store.
All icons and graphical assets in the theme are **DigiFist** property and protected by copyright.\
They may only be used within your store that uses our themes. Any external use, reproduction, or distribution is prohibited.
# Welcome to DigiFist Docs
Source: https://docs.digifist.com/themes/index
Everything you need to set up, customize, and get the most out of your DigiFist theme.
Browse the documentation for your theme or explore shared guides on sections, settings, and storefront configuration.
## Themes
A modern, clean design that puts your products front and center.
A fresh, vibrant design with a focus on imagery and color.
A calming, minimalist design that enhances the shopping experience.
A versatile, feature-rich design built for stores of any size.
## What's in each theme
Every DigiFist theme includes the following out of the box.
Purpose-built templates for product, collection, cart, account, blog, and more.
A full library of drag-and-drop sections for any page in your store.
Global controls for colors, typography, buttons, layout, and behavior.
Product badges, product groups, pre-order support, and gift card branding.
## Need help?
See what's new in the latest Release updates.
See what's new in the latest Sahara updates.
See what's new in the latest Mojave updates.
# Changelog
Source: https://docs.digifist.com/themes/mojave/changelog
Stay updated with the latest changes, improvements and fixes in the theme.
Comprehensive documentation restructuring and quality improvements completed.
### Documentation Restructuring
* Reorganized 62 documentation files into logical folder structure.
* Created dedicated folders: header/, footer/, products/, collections/, pages-templates/, sections/.
* Moved customer templates to pages-templates/customers/ subfolder.
* Updated 35+ internal cross-reference links to reflect new file locations.
### Documentation Improvements
* Updated all terminology to consistently use "Theme Customizer" instead of "theme editor".
* Fixed "Best practices" capitalization across 28 documentation files.
* Improved content structure consistency across all sections.
* Enhanced navigation and discoverability with organized folder structure.
### Files Restructured
* 17 files renamed to remove "main-" prefix.
* 2 files renamed to remove "section-" prefix.
* All files moved to appropriate category folders.
* Zero broken links after restructuring.
In this release, we’ve added the new preset structure to support new theme store experience.
In this release, we made improvements, and fixed bugs to enhance the user experience of the Mojave Theme.
### Features
* Added new Content tiles section.
* Added PDP Product rating block feature.
* Added thumbnails option to PDP gallery pagination style on mobile.
* Added link style option for hero banner section.
* Added back in stock feature support.
* Added Sign in with Shop button to the login page.
* Added decoration line option for hero banner section.
* Added option to select video from library in video section.
### Improvements
* Theme settings title and description improvements for a better user experience.
* Improvements have been made to ensure that breadcrumbs provide SEO support.
* Design improvements have been made to the PDP.
* Design improvements have been made to the PLP.
* Design improvements have been made to the product card swatches.
* Design improvements have been made to the Marquees section.
* Design improvements have been made to the Trust indicators section.
* Design improvements have been made to the Promotional collections section.
* Design improvements have been made to the Press section.
* Design improvements have been made to the Testimonials section.
* Improvements have been made for Newsletter modal in theme customizer.
### Fixes
* The issue with unavailable products in PDP variant selection has been fixed.
* Resolved script errors on the PDP.
* PDP vertical thumbs spacing issue has been fixed.
* PDP variant picker arrows visibility issue has been fixed.
* Login form not being centered issue has been fixed.
# Collection list page (CLP)
Source: https://docs.digifist.com/themes/mojave/collections/collection-list-page
Collections directory page (list.collections) displaying all or selected store collections
## What It Does
The **Collections List** section displays on your `/collections` page (Collections List template), showing an organized grid of all your store's collections or a curated selection. Each collection displays as a card with image, title, and product count, allowing customers to browse your catalog by category.
Configure page title, choose to show all collections or hand-picked selections, set pagination, and customize collection cards with overrides for specific images or titles.
This is a **template section** (appears on `/collections` page only - Collections List template). Not available as a regular section on other pages. Configure in Theme Customizer → Collections List page template.
## Getting Started
Visit `yourstore.myshopify.com/collections` to see your collections directory. This page auto-generates from Shopify collections.
In Theme Customizer → Collections List template → Set title (default "Collections"). This appears as page heading.
Select "Show all collections" or "Show selected collections". If selected, add Collection blocks for curated list.
Set "Collections per page" (default 12). For stores with many collections (50+), pagination improves page load.
## Settings
**Type:** Text input\
**Default:** "Collections"\
**Translatable:** Yes (uses locale file default "Collections")
Sets the page heading displayed at top of collections list page.
### How It Displays
* Large heading text (H1) at top of page
* Typically styled as page title (40-60px font size)
* Appears above collection cards grid
### Customizing Title
**Default "Collections":**
* Generic, functional, clear
* Works for most stores
* Translates automatically in multi-language stores
**Custom titles:**
* "Shop by Category" - More descriptive, guides browsing
* "Explore Collections" - Action-oriented, engaging
* "Browse Our Catalog" - Formal, traditional
* "Shop All" - Minimal, direct
* Brand-specific terms (e.g., "Women's Categories," "Product Lines")
### Choosing a Title
**Use "Collections" when:**
* Standard e-commerce terminology sufficient
* Customers familiar with "collections" concept
* Simple, direct language preferred
**Use custom title when:**
* Target audience unfamiliar with "collections" (may prefer "Categories")
* Brand voice is specific (playful, formal, technical)
* Want action-oriented language ("Explore," "Discover")
* Multi-brand store (e.g., "Shop Brands" if collections are brands)
### SEO Considerations
**H1 heading:**
* Title becomes H1 heading (most important heading for SEO)
* Should describe page purpose clearly
* "Collections" or "Shop by Category" both SEO-friendly
**Keywords:**
* Include target keywords if natural (e.g., "Women's Fashion Collections")
* Avoid keyword stuffing ("Cheap Products Collections Sale")
* Keep concise (3-5 words ideal)
### Best Practices
**Concise:**
* Keep to 1-4 words (long titles crowd page)
* "Collections" (1 word) - minimal
* "Shop by Category" (3 words) - descriptive
* "Explore Our Fashion Collections" (4 words) - max length
**Descriptive:**
* Should communicate page purpose
* Visitor should know this is collections/category directory
**Consistent:**
* Match terminology used elsewhere in site
* If main nav says "Categories," use "Categories" here (not "Collections")
**Translatable:**
* If multi-language store, keep default "Collections" (auto-translates via locale files)
* Or edit translations in theme's locale files for each language
**Recommendation:** Use default "Collections" for most stores. Change to "Shop by Category" if customers unfamiliar with collections terminology, or "Explore \[Your Brand]" for brand-specific messaging.
**Type:** Radio select\
**Options:** Show all collections, Show selected collections\
**Default:** Show all collections
Controls whether page displays all store collections automatically or only hand-picked collections via blocks.
### Show All Collections (Default)
**How it works:**
* Automatically displays every collection in your Shopify store
* Collections pulled from Shopify Admin → Products → Collections
* Order determined by Shopify settings or theme logic (often alphabetical)
* No manual collection selection needed
**Pros:**
* Zero maintenance—new collections auto-appear
* Comprehensive—customers see all available categories
* Fast setup—no need to add collection blocks
**Cons:**
* No control over order (automatic sorting)
* Displays ALL collections (including hidden/test collections if published)
* Can't exclude specific collections
**Best for:**
* Stores with organized collection structure (all collections customer-facing)
* 5-30 collections (manageable number for auto-display)
* Low-maintenance preference (don't want to manually curate)
### Show Selected Collections
**How it works:**
* Only displays collections added via "Collection" blocks (see Blocks tab)
* Must manually add Collection block for each collection to show
* Control exact order by reordering blocks
* Can display same collection multiple times (if needed for different images/titles)
**Pros:**
* Full control over which collections appear
* Custom order (drag-and-drop blocks to reorder)
* Exclude collections (e.g., hidden categories, staff-only, test collections)
* Override collection images/titles per-card
**Cons:**
* Manual maintenance—must add new collections as blocks
* More setup time (especially for stores with many collections)
* Forgetting to add new collections means customers don't see them
**Best for:**
* Curated experience (only show primary collections)
* Specific collection order important (e.g., Women → Men → Kids, not alphabetical)
* Need to hide certain collections (Sale, Staff Picks, etc.)
* Want custom images/titles different from Shopify Admin defaults
### Examples
**Example 1: Auto-display (Show all)**
* Store has 12 collections, all customer-facing
* All collections have good featured images, clear titles
* Order doesn't matter (alphabetical fine)
* **Setting:** "Show all collections" (automatic,zero maintenance)
**Example 2: Curated display (Show selected)**
* Store has 20 collections, but 5 are internal/test
* Want specific order: Best Sellers → New Arrivals → Seasonal → Men → Women → Kids
* **Setting:** "Show selected collections", add 15 Collection blocks in desired order
**Example 3: Custom imagery (Show selected)**
* Collections have generic featured images in Admin (created by staff)
* Want professional branded imagery for collections page
* **Setting:** "Show selected collections", add Collection blocks with custom images
### Switching Between Options
**Moving from All to Selected:**
1. Change setting to "Show selected collections"
2. Add Collection block for each collection you want to display
3. Reorder blocks to desired sequence
4. Optionally add custom images/titles
**Moving from Selected to All:**
1. Change setting to "Show all collections"
2. Collection blocks become inactive (not deleted, just not used)
3. All collections auto-display
### Best Practices
**Use "Show all" when:**
* All collections are customer-ready (published, good images, clear naming)
* Collection count is reasonable (5-30)
* You want hands-off management
**Use "Show selected" when:**
* Have hidden/internal collections to exclude
* Specific order is critical (brand hierarchy, seasonal priority)
* Need different imagery than Shopify Admin featured images
* Collection count very large (50+) and want to feature top categories
**Hybrid approach:**
* Use "Show all" initially (get site launched quickly)
* Switch to "Show selected" later when ready to curate experience
**Recommendation:** Use "Show all collections" (default) for straightforward stores with clean collection structure. Use "Show selected collections" for curated experiences or when collection order matters.
**Type:** Number input\
**Default:** 12\
**Info:** "Collections will be divided to pages by pagination"
Sets how many collection cards display per page before pagination kicks in.
### How Pagination Works
**If you have 50 collections and set "Collections per page" to 12:**
* **Page 1:** Collections 1-12
* **Page 2:** Collections 13-24
* **Page 3:** Collections 25-36
* **Page 4:** Collections 37-48
* **Page 5:** Collections 49-50
* Pagination links below grid: `< 1 2 3 4 5 >`
**If you have 8 collections and set to 12:**
* All 8 collections display on one page
* No pagination links (unnecessary)
### Choosing Collections Per Page
**Small number (8-12):** ← **Default: 12**
* **Pro:** Fast page load (fewer images)
* **Pro:** Less scrolling (easier to browse)
* **Con:** More pagination clicks to see all collections
* **Best for:** Stores with 20+ collections, slower internet users, mobile-first
**Medium number (16-24):**
* **Pro:** Balance browsing vs loading
* **Pro:** 2-3 rows of collections visible without scrolling (desktop)
* **Con:** Moderate page load (more images)
* **Best for:** Stores with 30-60 collections, desktop-heavy traffic
**Large number (30+):**
* **Pro:** Minimal pagination (maybe 2 pages total)
* **Pro:** All or most collections visible on single page
* **Con:** Slow page load (many images loading at once)
* **Con:** Long scrolling (overwhelming on mobile)
* **Best for:** Stores with 30-50 collections max, fast hosting, desktop-only
**No pagination (100+):**
* **Pro:** All collections on one page (no pagination)
* **Con:** Very slow load for stores with 50+ collections
* **Risk:** Page timeout, poor UX
* **Best for:** ONLY stores with \<20 collections (pagination unnecessary)
### Performance Considerations
**Image loading:**
* Each collection card loads featured image
* 12 collections = 12 images loading
* 50 collections = 50 images loading (can be slow)
**Recommendation by collection count:**
* **5-15 collections:** 12-24 per page (all fit on 1 page or 2 pages max)
* **15-30 collections:** 12-16 per page (2-3 pages)
* **30-60 collections:** 12 per page (5 pages, manageable)
* **60+ collections:** 12 per page (consider if you need this many customer-facing collections)
### Mobile Considerations
**Mobile scrolling:**
* Mobile displays 1-2 collection cards per row (vs 3-4 on desktop)
* 12 collections = 6-12 rows of scrolling on mobile
* 24 collections = 12-24 rows (too much scrolling)
**Mobile recommendation:**
* Keep pagination at 12 or less if mobile-heavy audience
* Customers comfortable with pagination links ("Next" button)
### SEO Implications
**Pagination:**
* Each pagination page has unique URL (e.g., `/collections?page=2`)
* Search engines crawl pagination pages
* Not a negative SEO factor (standard e-commerce pattern)
**Load time:**
* Faster page load (fewer collections per page) improves SEO
* Google favors fast-loading pages
* Balance UX (fewer clicks) vs speed (fewer images)
### Best Practices
**Test your store:**
1. Count your collections (Shopify Admin → Products → Collections)
2. Set to 12 (default)
3. Preview collections page
4. Check page load speed (Google PageSpeed Insights)
5. **If fast & many collections:** Increase to 16 or 24
6. **If slow:** Keep at 12 or reduce to 8
**Future-proofing:**
* If you have 10 collections now but plan to grow to 50+, set to 12 (room to grow)
* If you have 8 collections and don't plan to add many, set to 24 (all on one page now and later)
**User experience:**
* Most users comfortable with 2-3 clicks to browse all collections
* Page 1 should showcase primary/popular collections
* Avoid forcing users through 10+ pages (set higher pagination if this happens)
**Recommendation:** Use 12 (default) for most stores. Adjust to 8-10 for mobile-heavy stores or 16-24 for desktop-heavy stores with strong hosting. Never exceed number of total collections (avoid unnecessary pagination).
**Type:** Select dropdown\
**Options:** Page width (container--default), Narrow (container--md), Full-width (container--fullwidth)\
**Default:** Page width (container--default)
Controls the maximum width of the collections grid container.
### Width Options
**Page Width (Default - container--default):**
* **Width:** \~1200-1400px max (typical theme page width)
* **Best for:** Most stores, balanced layout
* **Appearance:** Collection grid centered with moderate side margins
* **Cards per row (desktop):** 3-4 collection cards
**Narrow (container--md):**
* **Width:** \~900-1000px max (narrower than page width)
* **Best for:** Minimal aesthetic, few collections
* **Appearance:** Tighter grid, larger margins, more whitespace
* **Cards per row (desktop):** 2-3 collection cards
**Full-Width (container--fullwidth):**
* **Width:** Edge-to-edge (100% browser width minus small padding)
* **Best for:** Many collections, visual/image-focused brands
* **Appearance:** Collections span nearly entire screen width
* **Cards per row (desktop):** 4-5+ collection cards (depends on screen size)
### Choosing Section Width
**Page Width when:** (Recommended default)
* Standard e-commerce layout
* 10-30 collections (3-4 cards per row is comfortable)
* Balanced, professional appearance
**Narrow when:**
* Few collections (5-10) - narrower grid prevents excessive whitespace
* Minimal brand aesthetic (lots of whitespace, breathing room)
* Collection images are detailed (larger cards when fewer per row)
* Mobile-first design (narrow desktop grid closer to mobile experience)
**Full-Width when:**
* Many collections (30+) - more cards per row reduces scrolling
* Image-heavy brand (fashion, photography) - showcase large collection images
* Modern, gallery-style layout
* Desktop-heavy traffic (utilize wide screens)
### Visual Comparison
**Narrow (2-3 cards per row):**
```
[ Collection ] [ Collection ]
[ Collection ] [ Collection ]
```
Large cards, lots of whitespace
**Page Width (3-4 cards per row):**
```
[ Collection ] [ Collection ] [ Collection ]
[ Collection ] [ Collection ] [ Collection ]
```
Balanced, standard grid
**Full-Width (4-5 cards per row):**
```
[Collection] [Collection] [Collection] [Collection] [Collection]
[Collection] [Collection] [Collection] [Collection] [Collection]
```
Many cards, edge-to-edge
### Mobile Behavior
**All widths behave similarly on mobile:**
* Mobile typically displays 1-2 collection cards per row
* Width settings primarily affect desktop/tablet (>768px)
* Full-width may have slightly less side padding on mobile
### Best Practices
**Consider collection count:**
* Few collections: Narrow (prevents cards stretching too wide)
* Many collections: Page Width or Full-Width (more cards visible)
**Match site aesthetic:**
* Check other pages' section widths
* Consistent width across pages feels cohesive
* If homepage uses page width, collections page should too
**Test on large screens:**
* Full-width can look sparse on 27"+ monitors (cards very small)
* Page Width maintains comfortable card size on large screens
* Narrow may look awkwardly tight on wide screens (excess whitespace on sides)
**Image quality:**
* Full-width requires high-res collection images (cards display larger)
* Narrow can get away with lower-res images (cards smaller)
**Recommendation:** Use Page Width (default) for most stores. Switch to Narrow for minimal aesthetic or \<10 collections. Use Full-Width for image-focused brands with many collections (30+).
**Block Type:** Collection\
**Limit:** 50 blocks max\
**Required when:** "Show selected collections" enabled (otherwise blocks inactive)
Add individual collection cards to display on collections list page. Each block represents one collection card.
### When to Use
**Blocks only active when:**
* Section setting "Collections to show" set to "Show selected collections"
* If set to "Show all collections," blocks are ignored
**Use Collection blocks to:**
* Manually curate which collections appear
* Control exact order of collections
* Override collection featured images (custom imagery per card)
* Override collection titles (custom names per card)
### Block Settings
**Collection (Collection picker - Required)**
* Select which collection this block represents
* Dropdown shows all collections from Shopify Admin
* Must select a collection (required field)
**Image (Image picker - Optional)**
* Override collection's featured image (from Shopify Admin)
* If blank: Uses collection's default featured image from Admin
* If uploaded: Uses custom image instead for this card only
* **Use when:** Collection featured image unsuitable for collections page (wrong aspect ratio, poor quality, off-brand)
**Title (Text input - Optional)**
* Override collection's title (from Shopify Admin)
* If blank: Uses collection's default title from Admin
* If filled: Displays custom title for this card only
* **Use when:** Collection title in Admin is technical/long, want shorter/different title for display
### Adding Collection Blocks
**Steps:**
1. Set "Collections to show" to "Show selected collections"
2. Click "Add Collection" block button
3. Select collection from dropdown
4. Optionally upload custom image (override featured image)
5. Optionally enter custom title (override collection title)
6. Repeat for each collection you want to display
7. Drag-and-drop blocks to reorder
### Use Cases for Image Override
**Scenario 1: Featured image wrong aspect ratio**
* Collection featured image in Admin is 1200x600px (wide rectangle)
* Collections page cards are square (crops awkwardly)
* **Solution:** Upload square 800x800px image in block (override)
**Scenario 2: Consistent aesthetic**
* Collections have varied featured images (some lifestyle, some product shots, some text graphics)
* Want uniform style for collections page (all lifestyle images)
* **Solution:** Upload consistent lifestyle images for each block
**Scenario 3: Branded imagery**
* Admin featured images are generic product grids (created quickly during setup)
* Ready to upgrade to professional branded photography
* **Solution:** Upload branded images in blocks without changing Admin images (Admin images still used elsewhere)
### Use Cases for Title Override
**Scenario 1: Long collection titles**
* Collection title in Admin: "Spring 2024 Limited Edition Women's Apparel"
* **Card title override:** "Spring 2024 Limited" (shorter, fits card better)
**Scenario 2: Technical titles**
* Collection title in Admin: "CAT-MENS-CASUAL-SHIRTS" (technical, for internal use)
* **Card title override:** "Men's Casual Shirts" (customer-friendly)
**Scenario 3: Multilingual**
* Collection title in Admin in English, but theme locale file doesn't translate
* **Card title override:** Manually enter translated title for non-English stores
### Best Practices
**Block order:**
* Drag-and-drop to reorder blocks (top block = first card on page)
* Strategic ordering: Best Sellers → New Arrivals → Seasonal → Evergreen categories
* Most important collections first (above the fold)
**Image consistency:**
* If overriding images, override for ALL collections (consistent style)
* Mixing default Admin images + custom overrides looks inconsistent
* Use same aspect ratio for all images (all square or all 3:2 ratio)
**Title length:**
* Keep titles under 30 characters (long titles wrap awkwardly on cards)
* Test on mobile (titles truncate on small screens)
**Don't duplicate:**
* Don't add same collection twice unless intentional (e.g., different images for sub-categories)
* Duplicates confuse customers
**Max 50 blocks:**
* Theme limits blocks to 50 (performance)
* If you have 50+ collections, use "Show all collections" instead (no limit)
**Recommendation:** Add Collection blocks ONLY when using "Show selected collections." Use image overrides for consistent aesthetic, use title overrides for customer-friendly display names.
## Best practices
Use "Show all collections" (default) for low-maintenance, comprehensive display. Switch to "Show selected" only when curation or custom order required.
Keep pagination at 12 collections (default) for fast page load and mobile-friendly scrolling. Increase to 16-24 only for desktop-heavy stores.
If using "Show selected," order blocks strategically: Best Sellers → New Arrivals → Seasonal → Core categories. First 12 most important (page 1).
Ensure all collection featured images have same aspect ratio (square recommended). Inconsistent aspect ratios create uneven grid.
Use concise, customer-friendly titles (under 30 characters). "Women's Shoes" better than "WOMENS-SHOES-SPRING-2024-CLEARANCE".
Preview collections page on mobile—grid becomes 1-2 cards per row. Ensure images clear, titles readable, pagination easily tappable.
Use "Show selected collections" to exclude internal/test collections. Customers shouldn't see "Staff Picks" or "DO NOT DELETE" collections.
Use "Page width" section width (default) for balanced layout. Narrow for minimal aesthetic, Full-width for many collections (30+).
## Common Use Cases
### Auto-Display All Collections
**Settings:** Title "Collections", Show all collections, 12 per page, Page width
**Setup:** Zero-maintenance collections directory. All collections auto-appear, alphabetical order, pagination for stores with 20+ collections.
**Best for:** Standard stores with organized collection structure, 10-40 collections
### Curated Collections Showcase
**Settings:** Title "Shop by Category", Show selected collections, 16 per page, Page width
**Setup:** Hand-picked 15 primary collections in strategic order (exclude internal collections). Custom order: Women → Men → Kids → Accessories.
**Best for:** Stores with many collections but want to highlight primary categories
### Minimal Collection Grid
**Settings:** Title "Collections", Show all collections, 12 per page, Narrow width
**Setup:** Small store with 8 collections, narrow grid creates elegant spacing, all collections fit on one page.
**Best for:** Boutique stores, few collections (\<10), minimal aesthetic
### Visual Fashion Gallery
**Settings:** Title "Explore", Show selected collections, 24 per page, Full-width
**Setup:** 30 fashion collections with professional imagery, full-width grid showcases images, 24 per page for comprehensive view.
**Best for:** Fashion brands, image-focused, many collections (30+)
### Custom Branded Directory
**Settings:** Title "Shop Our Brands", Show selected collections, 12 per page, Page width, Image overrides on all blocks
**Setup:** Collections represent brands, upload custom brand logo images (override featured images), display as branded directory.
**Best for:** Multi-brand retailers, collections organized by brand
## Layout Behavior
### Desktop Layout
**Collection cards grid:**
* **Page Width:** 3-4 cards per row (1200-1400px container)
* **Narrow:** 2-3 cards per row (900-1000px container)
* **Full-Width:** 4-5+ cards per row (edge-to-edge)
**Card contents:**
* Collection featured image (square or 3:2 ratio typical)
* Collection title below image
* Product count (e.g., "24 products") below title
**Pagination:**
* Displays below grid if total collections exceeds "Collections per page" setting
* Links: `< 1 2 3 4 ... 10 >`
### Mobile Layout
**Responsive behavior:**
* Mobile (\< 768px): 1-2 cards per row (usually 1 on narrow screens, 2 on wide phones)
* Section width setting minimally affects mobile (cards span nearly full width)
* Vertical scrolling (pagination links below grid)
**Card sizing:**
* Cards larger on mobile (fewer per row = more screen space per card)
* Images remain clear (not too small)
### Empty State
**If no collections:**
* Page displays title but no cards
* (Shopify requires at least 1 collection, so empty state rare)
**If all collections hidden:**
* "Show selected collections" with no blocks added
* Page shows title, no cards (add Collection blocks to fix)
## Related Sections
* **[Collection Banner (Template)](/themes/mojave/sections/main-collection-banner)** - Hero banner on individual collection pages
* **[Featured Collections Links](/themes/mojave/featured-collections-links)** - Collection grid for homepage
* **[Featured Collection](/themes/mojave/featured-collection)** - Single collection products showcase
* **[Collection Product Grid (Template)](/themes/mojave/collections/collection-page)** - Product grid within collection pages
## Technical Notes
### Collections Source
**Shopify Admin collections:**
* Products → Collections → All collections listed here
* Collections List page pulls from this source
* **Published collections only:** Unpublished collections don't appear (even in "Show all" mode)
**Collection visibility:**
* Check collection settings in Admin → Collection → Sales channels
* Must be published to "Online Store" channel to appear
### Collection Cards Data
**Each card displays:**
* **Image:** Collection featured image (Admin → Collection → Featured image), or block override
* **Title:** Collection title (Admin → Collection → Title), or block override
* **Product count:** Auto-calculated (e.g., "15 products")
* **Link:** Clicks go to collection page (`/collections/collection-handle`)
### Pagination Logic
**URL structure:**
* Page 1: `/collections` (no query param)
* Page 2: `/collections?page=2`
* Page 3: `/collections?page=3`
**SEO:**
* Pagination query params are SEO-friendly (Google crawls paginated pages)
* Each page has unique URL, indexed separately
### Dynamic Collection Count
**"Show all collections" mode:**
* If you add new collection in Shopify Admin, it auto-appears on page
* If you delete collection, it auto-disappears
* Zero maintenance (dynamic)
**"Show selected collections" mode:**
* Must manually add Collection block for new collections
* Deleted collections show error in block (remove block)
* Requires maintenance
### Performance
**Image loading:**
* Collection featured images lazy load (below fold cards load as scrolling)
* First 12 cards load immediately, rest on-demand
* Shopify CDN auto-optimizes images (WebP format for supported browsers)
**Pagination improves performance:**
* 12 collections per page = 12 images loading
* vs 60 collections on one page = 60 images (much slower)
### Accessibility
**Keyboard navigation:**
* Tab through collection cards (each card focusable link)
* Enter on card navigates to collection page
* Pagination links keyboard-accessible
**Screen reader:**
* Each card announces: "Collection name, Link, X products"
* Images have alt text (collection title as alt)
**Color contrast:**
* Text overlays on images should have sufficient contrast
* Theme typically adds semi-transparent overlay to images for readability
## Troubleshooting
**Collections not showing:**
* Check "Collections to show" setting—if "Show selected," must add Collection blocks
* Verify collections published: Admin → Collection → Sales channels → Online Store enabled
* Check collection visibility (some themes have hidden collection feature)
**Wrong collections displaying:**
* If "Show all collections" enabled, shows ALL published collections (check Admin for unwanted collections)
* Switch to "Show selected collections" to exclude specific collections
**Collection images missing:**
* Add featured images in Admin: Products → Collections → \[Collection] → Featured image
* If using "Show selected" with image overrides, verify images uploaded in blocks
* Check browser console for image load errors
**Pagination not working:**
* Check "Collections per page" setting—if set higher than total collections, no pagination
* Example: 8 collections with 12 per page = no pagination (fits on 1 page)
* Reduce "Collections per page" to see pagination (e.g., set to 4 for 8 collections = 2 pages)
**Collection order wrong:**
* "Show all collections" orders alphabetically or by Shopify sort (no custom order)
* Use "Show selected collections" for custom order (drag-and-drop blocks)
**Custom images not applying:**
* Verify "Show selected collections" enabled (image overrides only work in blocks)
* Check image uploaded in Collection block (not just in Admin)
* Hard refresh browser (Cmd/Ctrl+Shift+R) to clear cache
**Custom titles not applying:**
* Same as images—only works in "Show selected collections" mode with blocks
* Verify title entered in block's "Title" field
* Check for trailing spaces (extra spaces may cause issues)
**Page load slow:**
* Too many collections per page (reduce "Collections per page" to 12)
* Collection images too large (compress images to under 300KB before upload in Admin)
* Check Shopify status (hosting issues rare but possible)
**Mobile grid looks broken:**
* Test on actual mobile device (not just browser resize—may render differently)
* Check collection image aspect ratios (all should be consistent)
* Clear mobile browser cache
**Collections page blank:**
* Verify in Theme Customizer → Templates → Collections List that section is enabled
* Check if section accidentally deleted (re-add from section library)
* Preview specific collection URL (not `/collections`) to verify collections exist
**Product count incorrect:**
* Product count auto-calculated by Shopify (# of published products in collection)
* If wrong, check collection products in Admin (may have unpublished products)
* Count only includes products published to Online Store channel
**Blocks not reordering:**
* Drag-and-drop by clicking block name/handle (not settings area)
* Ensure "Show selected collections" enabled (blocks inactive otherwise)
* Save changes, hard refresh browser to see new order
# Collection Page (PLP)
Source: https://docs.digifist.com/themes/mojave/collections/collection-page
Configure your collection page product grid with flexible layouts, filtering, and sorting options
The Product grid template (main-collection-product-grid) controls how products display on collection pages. It provides customization for grid layout, filtering options, and sorting controls to help customers browse and find products efficiently.
## What this section controls
* Products per row on mobile and desktop
* Products per page before pagination
* Product filtering controls
* Sorting dropdown options
* Filter layout (horizontal bar vs. sidebar)
* Filter button styling
## Getting started
In your Shopify admin, go to **Online Store > Themes** and click **Customize** on your active theme.
Use the page selector dropdown at the top center to select **Collections** and choose any collection to preview.
The "Product grid" section controls the main collection template. Additional sections (like collection banner) can be added above it.
## Filter layout options
Choose how filtering controls display on desktop:
Filters appear in a horizontal bar above the product grid, with full-width products below.
**Characteristics**:
* Compact filtering interface
* Maximizes product grid width
* Filter style setting (square/round) applies to buttons
* Modern, streamlined appearance
**Best for**: Stores with fewer filter options, clean minimal designs, or when product visibility is priority.
Filters display in a left sidebar with products to the right.
**Characteristics**:
* Traditional e-commerce layout
* Dedicated space for extensive filters
* Filter style setting doesn't apply (sidebar has fixed styling)
* Always visible filtering options
**Best for**: Stores with many filter options, detailed categorization needs, or customers who expect traditional layouts.
**Note**: On mobile devices, filters always use a vertical layout regardless of desktop setting.
## Template settings
Control how many products display side-by-side on mobile devices:
* **1 product**: Single column, vertical scrolling - Emphasizes each product with large images
* **2 products** (default): Two columns - Balances product size with browsing efficiency
**Recommendation**: Keep default 2-column layout for most stores. Use 1-column only for products requiring detailed image viewing (art, complex items).
Control desktop grid columns:
* **2 products**: Large product cards, maximum image size
* **3 products**: Balanced layout with good visibility
* **4 products** (default): Standard e-commerce grid, efficient browsing
**Selection guidance**:
* **2 columns**: Image-focused stores (art, photography, luxury goods)
* **3 columns**: Balanced approach for most product types
* **4 columns**: Efficient browsing, standard for apparel/accessories
* Consider 5-column option if you have many SKUs (requires custom CSS)
Set how many products display before pagination loads more (2-50 products, default: 12).
**Sizing recommendations**:
* **8-16 products**: Standard range, balances page load with browsing
* **24-36 products**: Power users, reduces pagination clicks
* **50 products**: Maximum, may slow page load on slower connections
**Tips**:
* Keep default 12 for most stores
* Increase for collections with extensive filtering (reduces filter re-application)
* Consider page load speed - more products = slower initial load
* Popular numbers: 12, 16, 20, 24 (divisible by common column counts)
Show/hide product filtering controls. Enabled by default.
**When enabled**: Customers can filter by availability, price, product type, vendor, tags, and custom metafields configured in the Search & Discovery app.
**When to disable**:
* Small collections where filtering isn't needed
* Curated collections where you want to control product order
* Landing pages with specific product selections
**Configure filters**: Manage filter options in **Shopify Admin → Search & Discovery app → Filters**. You can customize which filters appear, their order, and filter types (checkboxes, price range, etc.).
Show/hide the sorting dropdown. Enabled by default.
**Available sort options** (standard Shopify):
* Featured (manual collection order)
* Best Selling
* Alphabetical: A-Z
* Alphabetical: Z-A
* Price: Low to High
* Price: High to Low
* Date: Newest to Oldest
* Date: Oldest to Newest
**When to disable**:
* You want complete control over product order (featured only)
* Small curated collections where sorting doesn't add value
* Product order is part of your storytelling/merchandising
Control filter layout on desktop devices. Disabled by default (uses horizontal bar).
**Disabled (horizontal bar)**:
* Filters in compact horizontal bar above products
* Full-width product grid
* Modern, clean appearance
* Filter style (square/round) setting applies
**Enabled (sidebar)**:
* Filters in dedicated left sidebar
* Product grid uses remaining width
* Traditional e-commerce layout
* More space for extensive filter options
* Filter style setting doesn't apply
Choose based on number of filters and store aesthetic preferences.
Choose visual style for filter buttons when horizontal bar is active. Doesn't apply to sidebar layout.
* **Square** (default): Clean, modern rectangular buttons
* **Round**: Softer, rounded button edges
**Effect**: Only visible when "Show in sidebar on desktop" is disabled (horizontal bar mode).
Match filter style to your overall design system - square for modern/minimalist themes, round for softer/friendly aesthetics.
## Configuring filters
Product filters are managed through Shopify's **Search & Discovery** app, not in the Theme Customizer.
In Shopify admin, go to **Apps → Search & Discovery** (or install if not present).
Click on **Filters** in the left sidebar.
* Add/remove filter options (price, availability, product type, vendor, tags, metafields)
* Reorder filters by dragging
* Configure filter types (checkbox, swatch, price range)
* Set filter labels and display names
Save changes and test on your storefront collection pages.
Available filter types:
* **Availability**: In stock / Out of stock
* **Price**: Range slider or preset ranges
* **Product type**: Automatically from product types
* **Vendor**: Filter by brand/manufacturer
* **Tags**: Product tags as filters
* **Metafields**: Custom product properties (color swatches, materials, etc.)
## Best practices
Use 4 columns on desktop for standard browsing efficiency. Consider 3 columns for products requiring larger images (jewelry, art) or 2 columns for luxury/high-detail items.
Keep at 12-24 products for best performance. Higher values reduce clicks but slow page load. Test with your target audience's connection speed.
Most customers expect both options. Only disable when you have strong merchandising reasons to control the exact product order.
Use horizontal bar for smaller stores (5-10 filter options). Use sidebar for extensive filtering needs (15+ options) or traditional customer expectations.
In Search & Discovery, enable only relevant filters. Too many filters overwhelm customers. Focus on filters that genuinely help narrow choices (size, color, price).
Test 2-column mobile layout across devices. Single column rarely adds value unless products require extremely detailed views.
Use numbers divisible by your column count (12 for 3-4 columns, 16 for 4 columns, 18 for 3 columns) for balanced final rows.
Square filters suit modern/minimalist themes, round filters suit friendly/approachable brands. Maintain consistency with button styles elsewhere.
Use "Featured" sort (manual collection order) to highlight seasonal items, bestsellers, or high-margin products at the top of collections.
Track which filters customers use most (via analytics). Remove unused filters to reduce interface complexity and improve experience.
# Search Template (main-search)
Source: https://docs.digifist.com/themes/mojave/collections/search
Configure your search results page with product grid, blog results, and page results display options
The Search template (main-search) controls how search results display, combining products, blog articles, and pages with filtering and customizable metadata display.
## What this section controls
* Product grid layout and density
* Product filtering and sorting
* Blog article result display with metadata
* Page result display options
* Results per page pagination
* Label and tag display for mixed results
## Getting started
In your Shopify admin, go to **Online Store > Themes** and click **Customize** on your active theme.
Use the page selector dropdown to select **Search** or perform a search on your live site.
The "Search" section controls the search results template.
## Template settings
Control product grid columns on mobile (1-2 products, default: 2).
Same as collection page - 2 columns recommended for balanced browsing.
Control product grid columns on desktop (2-4 products, default: 4).
4 columns maintains consistency with collection pages and efficient browsing.
Total items (products + articles + pages) before pagination (4-48 items, default: 24).
**Note**: Mixed result types - 24 items might be 20 products, 3 articles, 1 page.
Shows product filtering controls (enabled by default). Filters managed through Search & Discovery app.
**Mixed results behavior**: Filters only apply to products, not blog articles or pages.
Shows sorting dropdown for products (enabled by default). Standard sort options apply.
**Note**: Sorting affects product results only.
Moves filters to sidebar on desktop (disabled by default - uses horizontal bar).
Same options as collection page.
Square or round filter buttons (default: square). Only applies to horizontal bar layout.
Controls label display for blog articles in search results:
* **Show blog post label** (default): Displays "Blog post" badge
* **Show tags**: Displays article tags instead
* **Show none**: No labels
Helps distinguish blog articles from products and pages in mixed results.
When showing tags:
* **Show all** (default): All article tags
* **Show first**: First tag only
Display article preview text (disabled by default). Helps users decide relevance.
Display article publish date (enabled by default).
Display article author name (enabled by default).
Display "Page" badge on page results (enabled by default).
Distinguishes standard pages from products and articles.
Display page content preview (disabled by default).
Enable to help users identify relevant pages quickly.
Display "Read more" link on pages (enabled by default).
Provides explicit call-to-action for page results.
## Search result types
The search template displays three types of results in mixed format:
**Products**: Displayed in grid matching collection pages, with images and purchase options.
**Blog articles**: Card format with optional metadata (date, author, excerpt, tags).
**Pages**: Simple list format with title, optional excerpt, and "Read more" link.
**Result ordering**: Shopify's search algorithm determines relevance and ranking across all result types.
## Best practices
Show "Blog post" and "Page" labels to help users distinguish different content types in mixed results.
Turn on blog excerpt display - helps users quickly determine article relevance from search results.
Use same product grid settings (4 columns, filtering, sorting) as collection pages for consistency.
Keep date and author enabled for blog results - provides context about content freshness and source.
Consider enabling page excerpts if you have many pages - helps users identify right page in results.
Search for terms that return products, articles, and pages to ensure all result types display correctly.
24 items balances browsing with performance. Adjust if users frequently paginate or complain about slow loading.
Use Search & Discovery app to customize which product filters appear on search results.
# Footer
Source: https://docs.digifist.com/themes/mojave/footer/footer
Build a comprehensive site footer with navigation, social links, payment icons, and localization options
The Footer section appears at the bottom of every page on your store, providing essential navigation links, brand information, social media connections, and trust signals like payment icons. It supports up to 3 content blocks with flexible layout options.
## What this section controls
* Footer navigation menus with organized columns
* Brand logo and descriptive content
* Social media icon links
* Copyright information and legal links
* Payment method icons
* Language and currency selectors
* Follow on Shop integration
* Two visual style variations
## Getting started
In your Shopify admin, go to **Online Store > Themes** and click **Customize** on your active theme.
The Footer section is located at the bottom of your site and remains consistent across all pages.
## Footer styles
Choose between two visual style variations:
Standard footer layout with traditional styling and expanded localization controls.
**Characteristics**:
* Full-size localization selectors
* Classic visual hierarchy
* Standard spacing and typography
Alternative footer layout with compact styling and streamlined appearance.
**Characteristics**:
* Compact localization selectors
* Modified visual treatment
* Adjusted spacing and presentation
## Key settings
Extends the footer to full browser width, removing container constraints. When disabled, footer content stays within the theme's standard container width.
**Visual impact**:
* **Enabled**: Edge-to-edge footer spanning entire viewport
* **Disabled**: Footer contained within standard width, creating margins on wide screens
Select between Style 1 (default) or Style 2 for different visual presentations of your footer.
Style variants affect layout, spacing, localization display, and overall visual treatment. Test both to see which better matches your store aesthetic.
Displays copyright text in the footer bottom area, including:
* Current year (auto-updates annually)
* Your shop name with link to homepage
* "Powered by Shopify" attribution
This setting is enabled by default and recommended for legal protection and brand attribution.
Select a menu to display in the footer bottom alongside copyright text. Commonly used for legal and policy links.
**Typical links included**:
* Privacy Policy
* Terms of Service
* Refund Policy
* Shipping Policy
* Accessibility Statement
Create this menu at: **Shopify Admin → Online Store → Navigation**
Displays icons for payment methods enabled in your Shopify Payments settings. Icons automatically populate based on available payment providers.
**Benefits**:
* Builds customer trust by showing accepted payment methods
* professional appearance signaling secure checkout
* No manual updates required - syncs with your payment settings
Enabled by default. Icons only appear if you have payment methods configured in Shopify admin.
Shows "Follow on Shop" button allowing customers to follow your store in the Shop app for updates and easy reordering.
**Requirements**:
* Shop Pay must be enabled in your payment settings
* Feature must be available for your store
When customers follow your store, they receive notifications about new products, back-in-stock items, and order updates through the Shop app.
Learn more: [Follow on Shop Help](https://help.shopify.com/manual/online-store/themes/customizing-themes/follow-on-shop)
## Block settings
Add up to **3 blocks total** in any combination to build your footer content. Blocks can include brand content, navigation menus, and social links.
Display your brand logo and descriptive content about your store, mission, or unique value proposition.
Upload a logo image to display in the footer. The logo can be different from your header logo if desired.
**Logo considerations**:
* Often displayed in monochrome or alternative colorway in footer
* Should maintain legibility against footer background
* Can be same as header logo or a footer-specific variant
Control logo size as a percentage of the container width (25-100%). Default is 50%.
**Sizing guidance**:
* **25-40%**: Small, subtle logo presence
* **45-55%**: Balanced size (default: 50%)
* **60-75%**: Prominent logo emphasis
* **80-100%**: Maximum visibility
Adjust based on your footer layout and content density.
Add rich text describing your brand, mission statement, tagline, or unique value proposition.
**Content ideas**:
* Brief brand story or mission statement
* Unique selling points or commitments (e.g., "Sustainably sourced")
* Customer service highlights (e.g., "Free shipping over \$50")
* Quality guarantees or certifications
Keep content concise - footers are scanned quickly, not read in detail.
Add footer navigation menus with organized columns. Menu structure determines column layout automatically.
Select a menu to display in the footer. The menu structure determines how content is organized:
**Menu structure rules**:
* **Top-level links with no children**: Display as standalone column headers
* **Top-level links with children**: Column header with listed sublinks
* **Maximum 3 columns**: Footer automatically limits to 3 columns per navigation block
**Example structure**:
```
Footer Menu
├── Shop (Column 1 header)
│ ├── New Arrivals
│ ├── Best Sellers
│ └── Sale
├── About (Column 2 header)
│ ├── Our Story
│ ├── Contact Us
│ └── Careers
├── Help (Column 3 header)
├── FAQs
├── Shipping
└── Returns
```
**Responsive behavior**:
* **Desktop**: Columns always expanded and visible
* **Mobile**: Collapsible accordions for links with children, simple links for standalone items
Create and manage menus at: **Shopify Admin → Online Store → Navigation**
**Note**: You can add multiple Navigation blocks (up to the 3 block total limit) to display different menus in separate footer sections.
Display social media icon links to your social profiles. Icons automatically populate from theme settings.
Optional heading text displayed above social media icons (e.g., "Follow Us", "Connect With Us", "Stay in Touch").
Leave blank for icons without a heading.
Social icons are controlled by **Theme Settings → Social Media**. Configure your social media URLs there, and they'll automatically appear in footer social blocks.
**Supported platforms** (configure in theme settings):
* Facebook
* Instagram
* Twitter/X
* Pinterest
* TikTok
* YouTube
* Snapchat
* Tumblr
* Vimeo
Only platforms with configured URLs will display icons.
To configure: **Theme Customizer → Theme Settings → Social Media**
## Language and currency selectors
If you've enabled multiple languages or currencies for your store, localization selectors appear automatically in the footer above the bottom bar.
Appears when multiple languages are configured, allowing customers to switch between available languages.
To enable: **Shopify Admin → Settings → Languages → Add language**
Appears when multiple currencies are enabled, allowing customers to view prices in their preferred currency.
To enable: **Shopify Admin → Settings → Payments → Currency formatting**
The display style adapts based on your selected footer style (compact for Style 2, full for Style 1).
## Best practices
Group related links under clear column headers. Limit to 3-6 links per column for easy scanning. Common groups: Shop, About, Help, Legal.
Footer text should be scannable, not detailed. Aim for 1-3 sentences maximum. Save detailed content for dedicated pages.
Maximize footer value by using all 3 available blocks. Common combination: Textual + Navigation + Socials for comprehensive footer content.
Use copyright navigation menu for Privacy Policy, Terms, and other required legal pages. Protects your business and builds customer trust.
Always show payment icons to build trust and set expectations about accepted payment methods before customers reach checkout.
Set up social media URLs in theme settings before adding Socials block. Only configured platforms will display - test to avoid empty blocks.
Test both style options to see which better complements your overall store design. Style affects spacing, typography, and visual hierarchy.
Enable Follow on Shop if you use Shop Pay. It helps retain customers by making reordering and order tracking easier through the Shop app.
Footer automatically adapts for mobile with collapsible navigation. Test on mobile devices to ensure accordions work smoothly and content remains accessible.
Footer logos typically display smaller than header logos (50% default). Adjust based on content density and brand emphasis desired.
# Header
Source: https://docs.digifist.com/themes/mojave/header/header
Configure your store's main navigation header with flexible layouts, transparent options, and megamenu capabilities
The Header section controls your store's primary navigation, branding, and utility functions. It supports multiple layout configurations including transparent header modes, powerful megamenu dropdowns with featured content, and responsive mobile navigation.
## What this section controls
* Logo display and positioning
* Main navigation menu and dropdown styles
* Transparent header on homepage and collection pages
* Megamenu dropdowns with multi-column layouts and featured content
* Search, account, and cart utility icons
* Sticky header behavior
* Mobile menu drawer with footer links
## Getting started
In your Shopify admin, go to **Online Store > Themes** and click **Customize** on your active theme.
The Header section is located at the very top of your site and remains consistent across all pages.
## Menu styles
Choose how navigation menus behave on desktop devices:
Dropdown menus open automatically when customers hover over navigation links. Provides quick access to submenu items with minimal interaction required.
**Best for**: Stores with organized navigation hierarchies where customers browse multiple categories.
Dropdown menus open only when customers click navigation links. Requires explicit interaction to reveal submenus.
**Best for**: Touch-enabled devices, accessibility-focused designs, or when you want deliberate navigation interaction.
Uses mobile-style drawer menu on all devices, sliding in from the side. Provides a consistent experience across desktop and mobile.
**Best for**: Minimalist designs, mobile-first stores, or navigation systems with many levels.
## Key settings
Extends the header to the full browser width, removing container constraints. When disabled, header content stays within the theme's standard container width.
**Visual impact**:
* **Enabled**: Edge-to-edge header spanning entire viewport
* **Disabled**: Header contained within standard width, creating margins on wide screens
Upload your store logo. If no image is uploaded, your shop name displays as text with automatic sizing that adapts to text length.
**Logo sizing recommendations**:
* Maximum width: 200px (desktop), 180px (mobile)
* Transparent PNG or SVG recommended for best quality
* Consider creating an alternative logo for transparent header mode
**Automatic text logo scaling**: Without an image, shop name size adjusts dynamically - shorter names display larger, longer names reduce to fit comfortably.
Control logo image width on desktop devices (50-200px). This setting only applies when a logo image is uploaded.
**Sizing tips**:
* **Small logos (50-100px)**: Subtle branding, emphasizes navigation
* **Medium logos (100-150px)**: Balanced presence (default: 145px)
* **Large logos (150-200px)**: Strong brand emphasis, prominent identity
Independently control logo size on mobile devices (50-180px). This allows optimization for smaller screens without affecting desktop appearance.
Typically set 10-20px smaller than desktop to maintain proportion on mobile viewports.
Choose logo placement and navigation layout:
* **Start**: Logo positioned at the left/start of the header with navigation alongside
* **Center**: Logo centered with navigation items distributed around it
* **Center with menu below**: Logo centered at top, full navigation menu displayed below the logo
**Note**: "Center with menu below" option only works with hover or click menu styles (not available with drawer menu).
Select which navigation menu displays in the header. Choose from menus created in **Navigation** settings. By default uses "main-menu".
Create and manage menus at: **Shopify Admin → Online Store → Navigation**
Control how dropdown menus open on desktop:
* **Hover**: Menus open on mouseover (default)
* **Click**: Menus open on click only
* **Drawer**: Mobile-style slide-out drawer on all devices
All three styles automatically use drawer navigation on mobile devices.
Adds a bottom border line to the header, visually separating it from page content below. Enabled by default.
When enabled, the header remains fixed at the top of the viewport as customers scroll down the page. This keeps navigation always accessible.
**User experience benefits**:
* Quick access to navigation without scrolling back to top
* Persistent search and cart access throughout shopping experience
* Reinforces branding with consistent logo visibility
Makes the header background transparent on your homepage, allowing hero images or videos to display beneath it. This creates an integrated, immersive homepage experience.
**Requirements for proper display**:
* First homepage section must be: Hero, Banner - Fullwidth, or Video section
* These sections need sufficient height to accommodate transparent header
* Logo and text must have sufficient contrast against background images
**Design considerations**:
* Test visibility with all hero images you use
* Consider using the transparent logo option for better contrast
* Ensure hero images have suitable composition (clear space for header content)
Activates transparent header on collection pages, integrating with collection banner sections.
**Requirement**: The first section on collection template must be a Collection banner section for proper integration.
Works similarly to homepage transparency but specifically optimized for collection page layouts.
Upload an alternative logo that displays specifically when transparent header is active. This allows you to use a different colored logo that contrasts better against hero backgrounds.
**Common use cases**:
* White logo for dark hero images
* Dark logo for light hero images
* Different color variations for brand flexibility
The default logo automatically swaps to this alternative when transparency is enabled and active on qualifying pages.
Controls the font size of top-level navigation links using preset size options: XS, S, M, L, XL (default: L).
These are the main menu items visible in your header navigation bar.
**Sizing guidance**:
* **L-XL**: Prominent navigation, easy to see and click
* **M**: Balanced presence (good for many menu items)
* **XS-S**: Subtle navigation, maximizes space
Controls font size for dropdown menu content including column headers and submenu links. Options: XS, S, M, L, XL (default: M).
This affects text within megamenus and standard dropdown menus.
Typically set smaller than top-level links to create visual hierarchy (default M vs. default L).
Select a page to link in the mobile menu footer. Appears below navigation links when customers open the mobile menu drawer.
Provides quick access to contact information from any page on mobile devices.
Select a FAQ or help page to link in the mobile menu footer, appearing alongside the contact link.
Gives mobile customers easy access to self-service support resources.
## Block settings
Add blocks to create enhanced dropdown menus with featured content. Two block types are available: featured images for standard dropdowns and megamenus for multi-column layouts.
Add promotional images to standard dropdown menus for specific navigation links.
**Critical**: Enter the exact title of a top-level navigation link to associate this featured image with that link's dropdown menu.
For example, if you have a main menu link called "Women's Clothing", enter exactly "Women's Clothing" here to attach the featured image to that dropdown.
**Title must match exactly** (case-sensitive) to function properly.
Upload the featured image to display in the dropdown menu.
**Recommended specifications**:
* Ratio: Portrait orientation
* Size: 720 x 900 pixels
* Format: JPG or PNG
The image displays alongside standard dropdown menu links.
Optional URL to make the featured image clickable. When customers click the image, they navigate to the specified link.
Typically links to featured collection, seasonal promotion, or highlighted product.
Create rich multi-column dropdown menus with organized navigation, collections, labels, and featured imagery.
**Critical**: Enter the exact title of a top-level navigation link to convert its dropdown into a megamenu.
For example, to create a megamenu for "Shop All", enter exactly "Shop All" here.
**Title must match exactly** (case-sensitive) for the megamenu to appear.
Select a menu with **at least 2 levels** of hierarchy to populate the megamenu columns.
**Structure requirements**:
* **Tier 1 links** (top level) create column headers
* **Tier 2 links** (sublinks) populate items within each column
**Example structure**:
```
Categories (Menu name)
├── New Arrivals (Column 1 header)
│ ├── Dresses (link)
│ ├── Tops (link)
│ └── Accessories (link)
├── Best Sellers (Column 2 header)
│ ├── Summer Collection (link)
│ └── Winter Collection (link)
```
Create hierarchical menus at: **Shopify Admin → Online Store → Navigation**
Optionally feature a specific collection in the megamenu. The collection can be highlighted with products or visual emphasis depending on theme implementation.
Add a badge or label text to display on the megamenu, useful for highlighting "New", "Sale", "Popular", or seasonal content.
Add a featured image to the megamenu for visual interest and promotional content.
**Recommended specifications**:
* Ratio: Portrait orientation
* Size: 720 x 800 pixels
* Format: JPG or PNG
Displays prominently within the megamenu layout alongside navigation columns.
Make the megamenu featured image clickable by adding a destination URL. Useful for directing customers to featured collections, promotions, or landing pages.
## Best practices
Keep logos between 100-150px for balanced visual weight. Too large dominates the header, too small reduces brand recognition.
When using transparent header, test with all hero images to ensure logo and navigation remain readable against various backgrounds.
Create a transparent header logo variant with inverted colors for better contrast against hero images (e.g., white logo for dark images).
Plan megamenu hierarchy carefully - tier 1 links become column headers, so organize categories logically. Aim for 3-5 columns maximum.
Featured image and megamenu blocks require exact title matches (case-sensitive) to function. Double-check spelling and capitalization.
Keep sticky header enabled for better user experience - customers can access navigation, search, and cart without scrolling to top.
Populate Contact and FAQ links in mobile menu settings to provide easy access to support resources on mobile devices.
Choose menu style based on your audience: hover for desktop-first, click for accessibility, drawer for mobile-first or minimalist designs.
Avoid overly deep menu hierarchies (more than 3 levels). Use megamenus to organize large catalogs into scannable column layouts.
Maintain visual hierarchy by keeping parent link size smaller than main navigation link size (default: M vs L).
# Password Header
Source: https://docs.digifist.com/themes/mojave/header/password-header
Simplified header for password-protected storefront pages
## What It Does
The **Header (Password Page)** section displays a simplified header on password-protected storefront pages (when your store is password-protected or in "Coming Soon" mode). This header typically shows your store logo and basic branding without navigation menus or cart functionality.
Configure logo appearance, positioning, transparency, and separator line to maintain brand consistency even before customers enter your store.
This header **only appears on password pages** (pre-launch, maintenance mode, or password-protected stores). Regular storefront uses the main Header section. Switch between headers automatically based on page type.
## Getting Started
In Shopify Admin → Online Store → Preferences → Enable password protection. This activates the password page and this header section.
In Theme Customizer → Password page template → Header section → Upload your store logo (same logo as main header recommended for consistency).
Adjust logo width slider (50-250px) until logo looks properly sized. Start at 145px (default), adjust as needed for your logo dimensions.
Select logo position (left or center), enable transparent header if desired, and enable/disable bottom separator line.
## Settings
**Type:** Checkbox\
**Default:** Disabled (unchecked)\
**Label:** "Transparent - Password page"
Makes the header background transparent, allowing password page background content to show through.
### When Disabled (Default - Solid Header)
* Header has solid background color (typically white or theme brand color)
* Logo and elements sit on opaque header bar
* Clear separation between header and page content below
* Traditional, professional header appearance
### When Enabled (Transparent Header)
* Header background fully transparent (no solid bar)
* Logo appears to "float" over password page background image/color
* Creates seamless, editorial aesthetic
* Password page background visible behind header
### Use Cases
**Transparent header when:**
* Password page has strong hero image/video that should extend to top of page
* Modern, editorial, high-fashion aesthetic
* Want immersive brand experience on coming-soon page
* Logo contrasts well with password page background
**Solid header when:**
* Password page background is busy/complex (transparent header logo hard to see)
* Traditional, e-commerce aesthetic
* Logo needs consistent background for readability
* Professional, corporate brand
### Contrast Considerations
**Critical:** Logo must contrast with password page background when header transparent.
**Testing process:**
1. Enable transparent header
2. Preview password page
3. Check logo visibility
4. **If logo hard to see:** Add dark overlay to password page background, or disable transparent header
**Example scenarios:**
* Dark logo + light background image = Good contrast
* Dark logo + dark background image = Poor contrast (logo invisible)
* Light logo + dark background image = Good contrast
* Light logo + light background image = Poor contrast
**Solution for contrast issues:**
* Upload alternate logo version (e.g., white logo for dark backgrounds)
* Add dark overlay to password page background image (in section-password settings)
* Use solid header instead (disable transparent)
### Best Practices
**When using transparent header:**
* Test logo visibility on multiple devices (mobile/desktop)
* Ensure logo remains readable as background content scrolls (if password page scrolls)
* Consider sticky positioning (logo stays visible when scrolling)
**Password page coordination:**
* Header transparency setting works in conjunction with Password page section background
* Design both sections together (transparent header + hero image password page = cohesive look)
**Recommendation:** Use solid header (default) for most stores unless you have strong branded password page background. Transparent works best for fashion, lifestyle, creative brands with curated coming-soon pages.
**Type:** Image picker\
**Required:** Upload recommended (optional, but password header looks empty without logo)
Upload your store logo to display in the password page header.
### Logo Specifications
**File format:**
* **PNG** (recommended) - Supports transparency, clean edges, best for logos
* **SVG** (ideal) - Vector format, scales perfectly, smallest file size
* **JPG** - Only if logo is photographic (rare for logos)
**Image size:**
* **Width:** 300-800px (Shopify auto-resizes, but upload at intended display size for quality)
* **Height:** Proportional to width (maintain aspect ratio)
* **File size:** Under 100KB (logos should be small files)
**Content:**
* Your store/brand logo (same logo as main header recommended)
* Horizontal logo works best (vertical logos may need width adjustment)
* Transparent background preferred (PNG with transparency)
### Uploading Logo
**Steps:**
1. Theme Customizer → Password page → Header section
2. Click "Logo" image picker
3. Upload logo file or select from media library
4. Adjust "Logo width" slider below to size appropriately
### Logo Visibility
**Without logo:**
* Header displays store name (from Shopify settings) as text
* Less professional, less branded
* Fallback if logo not uploaded
**With logo:**
* Brand logo displays prominently
* Professional appearance
* Stronger brand recognition
### Best Practices
**Same logo as main header:**
* Use identical logo for password header and main header (consistency)
* Customers should see same branding when they enter store
* Upload once, select from library for both headers
**Logo variants:**
* If using transparent header on password page, may need logo variant for contrast
* Example: Dark logo for solid header, white logo for transparent header over dark background
* Upload alternate logo version if needed
**High-resolution:**
* Upload logo at 2x actual display size for Retina displays
* Example: If logo displays at 145px wide, upload 290px wide source file
* Ensures crisp logo on high-DPI screens
**Transparency:**
* PNG with transparent background adapts to any header background color
* JPG with white background only works on white headers
* Always prefer PNG for logos
**Recommendation:** Upload high-resolution PNG logo with transparent background. Use same logo as main header for brand consistency.
**Type:** Range slider\
**Range:** 50px - 250px\
**Step:** 5px\
**Default:** 145px\
**Unit:** Pixels (px)
Controls the width of the logo image in the header.
### How Width Works
* Logo scales proportionally (height adjusts automatically to maintain aspect ratio)
* Example: 200x100px logo at 100px width = 100x50px displayed size
* Larger width = larger logo (more prominent)
* Smaller width = smaller logo (more subtle)
### Choosing Logo Width
**Small (50-100px):**
* Subtle, minimal branding
* Best for: Simple text logos, minimal aesthetic
* Risk: Logo may be too small to read (especially mobile)
**Medium (100-150px):** ← **Default: 145px**
* Balanced, professional size
* Best for: Most logos, standard branding
* Works well for horizontal wordmark logos
**Large (150-250px):**
* Prominent, bold branding
* Best for: Icon logos, very simple logos, strong brand focus
* Risk: Logo may dominate header (especially mobile)
### Adjusting for Logo Type
**Horizontal wordmark logos:**
* Need wider width (120-180px) for text readability
* Example: "COMPANY NAME" stretched horizontally
**Square icon logos:**
* Need less width (80-120px) since height grows proportionally
* Example: Circle logo, badge logo
**Vertical logos:**
* Tricky in horizontal header (consider horizontal variant)
* May need smaller width (60-100px) to prevent excessive height
**Complex logos:**
* Larger width (150-200px) for detail visibility
* Ensure intricate elements remain clear
### Testing Process
1. Upload logo
2. Set width to 145px (default starting point)
3. Preview password page on desktop and mobile
4. **If logo too small/hard to read:** Increase width (try 160px, 180px, 200px)
5. **If logo too large/dominating:** Decrease width (try 120px, 100px, 80px)
6. **Mobile check:** Logo should be readable but not overwhelming on small screens
### Mobile Considerations
**Responsive behavior:**
* Logo width may scale down on mobile (theme-dependent)
* Some themes use same width mobile/desktop, others scale to \~80% on mobile
* Test on actual mobile device (not just browser resize)
**Mobile-specific width:**
* This setting typically applies to both desktop and mobile
* If logo too large on mobile, reduce width (affects both)
* Advanced: Custom CSS can set different mobile width if needed
### Best Practices
**Readability first:**
* Logo must be legible at chosen size (text readable, details visible)
* Test at arm's length (typical viewing distance)
**Mobile priority:**
* If logo looks good on mobile, usually looks good on desktop
* If choosing between too large on desktop vs too small on mobile, prioritize mobile
**Consistent with main header:**
* Use same logo width as main header (brand consistency)
* Password page → main store transition feels seamless
**Header balance:**
* Logo shouldn't dominate entire header (leave breathing room)
* If header feels cramped, reduce logo width or increase header height
**Recommendation:** Start at 145px (default), adjust ±20px based on logo type. Horizontal wordmarks may need 160-180px, icon logos may need 100-120px.
**Type:** Select dropdown\
**Options:** Left, Center\
**Default:** Left
Controls horizontal alignment of the logo within the header.
### Position Options
**Left (Default):**
* Logo aligns to left side of header
* Standard e-commerce header convention
* Creates asymmetrical layout (logo left, rest of header open/right-aligned elements)
* Professional, familiar positioning
**Center:**
* Logo centers horizontally in header
* Symmetrical, balanced layout
* Creates editorial, high-fashion aesthetic
* More formal, intentional appearance
### Choosing Logo Position
**Left when:**
* Standard e-commerce aesthetic (most online stores use left)
* Multi-element header (logo left, navigation/cart right—though password header has no nav)
* Western reading pattern (eyes start top-left)
* Preparing for main store with left-logo header (consistency)
**Center when:**
* Minimal, editorial aesthetic (fashion, luxury, lifestyle)
* Symmetrical design preference
* Password page is coming-soon/brand launch (more formal)
* Logo is primary/only header element (no nav/cart on password page makes centering work well)
### Use Cases by Brand Type
**E-commerce retail (apparel, home goods, general):**
* **Left** - Standard, expected, professional
**Fashion/luxury brands:**
* **Center** - Editorial, high-end, fashion-forward
**Tech/SaaS companies:**
* **Left** - Functional, familiar, web convention
**Creative/lifestyle brands:**
* **Center** - Unique, artistic, intentional
**Small business/local shops:**
* **Left** - Safe, standard choice
### Transitioning to Main Store
**Consistency consideration:**
* If main store header has left-aligned logo, password header should too (seamless transition)
* If main store header has centered logo, password header should too
* Customers entering store shouldn't experience jarring layout shift
**Checking main header:**
1. Theme Customizer → Main header section (not password header)
2. Check logo position setting
3. Match password header position to main header
### Best Practices
**Default recommendation:**
* Left-aligned logo is safe, standard choice (works for 80% of stores)
**Center for brand statement:**
* Use center position to make password page feel more special/intentional
* "Coming soon" pages often benefit from centered logos (formal launch vibe)
**Mobile behavior:**
* Centered logos remain centered on mobile (expected)
* Left-aligned logos remain left on mobile (standard)
* Both work well on small screens
**Test with transparency:**
* If using transparent header, logo position affects visual balance with password page background
* Centered logo with centered password content feels cohesive
* Left logo may feel unbalanced if password content centered
**Recommendation:** Use Left (default) for standard e-commerce stores. Use Center for fashion, luxury, or coming-soon pages with formal/editorial aesthetic.
**Type:** Checkbox\
**Default:** Enabled (checked)
Controls whether a horizontal border line displays below the header.
### When Enabled (Default)
* Thin horizontal line appears at bottom edge of header
* Separates header from password page content below
* Creates clear visual boundary
* Typically subtle (1px line, light gray or theme color)
### When Disabled
* No separator line
* Header blends seamlessly into page content
* Cleaner, more minimal appearance
* Works well with transparent headers
### Use Cases
**Enable separator when:**
* Header background color similar to password page background (separator adds definition)
* Traditional, structured design aesthetic
* Want clear header boundaries
* Solid (non-transparent) header (separator reinforces header bar)
**Disable separator when:**
* Transparent header (separator can look awkward floating over background)
* Minimal aesthetic preference (cleaner without lines)
* Password page background contrasts strongly with header (separator redundant)
* Modern, seamless design
### Visual Impact
**With separator:**
```
[ LOGO ]
––––––––––––––––––––––––––––– ← Separator line
[ Password page content ]
```
**Without separator:**
```
[ LOGO ]
[ Password page content ] ← No line, seamless transition
```
### Best Practices
**Transparent headers:**
* Usually disable separator (floating line looks disconnected)
* Exception: If password background is very busy, separator can help anchor header
**Solid headers:**
* Usually enable separator (defines header bottom edge)
* Exception: If header color contrasts strongly with page background, separator may be redundant
**Minimalist brands:**
* Disable separator (fewer visual elements = cleaner)
**Traditional brands:**
* Enable separator (structured, defined sections)
**Testing:**
* Toggle setting and preview both states
* Check on mobile (separator may be more or less prominent on small screens)
* Ensure separator color contrasts enough to be visible but not harsh
**Recommendation:** Leave enabled (default) for solid headers, disable for transparent headers or minimal aesthetic.
## Best practices
Use identical logo on password header and main header for brand consistency. Customers should see same branding when entering your store.
If using transparent header, ensure logo contrasts with password page background. Dark logo needs light background, light logo needs dark background.
Start with 145px logo width (default), adjust ±20px based on logo type. Horizontal wordmarks need 160-180px, icon logos need 100-120px.
Align password header logo position (left/center) with main header. Seamless transition when customers enter store.
Turn off line separator when using transparent header (floating line looks disconnected). Keep enabled for solid headers.
Use PNG logo format with transparent background. Adapts to any header color and looks professional on all backgrounds.
Always preview password page on mobile devices. Logo size and position may appear different on small screens—adjust accordingly.
Design password header and password page section together. Transparent header + hero image or solid header + simple background.
## Common Use Cases
### Standard Coming Soon Page
**Settings:** Logo uploaded (145px width), Left position, Solid header (transparent disabled), Separator enabled
**Setup:** Professional coming-soon page with left-aligned logo, clear header separation, works for most e-commerce stores.
**Best for:** General retail, standard store launches, traditional brands
### Fashion Launch (Editorial Style)
**Settings:** Logo uploaded (120px width), Center position, Transparent header, Separator disabled
**Setup:** Centered logo over hero image background, no separator for seamless look. High-fashion, editorial aesthetic.
**Best for:** Fashion, luxury, lifestyle brands with branded coming-soon pages
### Minimal Brand Launch
**Settings:** Logo uploaded (100px width), Center position, Solid header, Separator disabled
**Setup:** Small centered logo, clean white/solid header, no separator for minimal look. Focus on simplicity.
**Best for:** Minimal brands, modern startups, clean aesthetic
### Maintenance Mode
**Settings:** Logo uploaded (145px width), Left position, Solid header, Separator enabled
**Setup:** Standard header matching main store. Simple message page during maintenance. Looks like regular store.
**Best for:** Temporary password protection, maintenance downtime, gradual store changes
### Exclusive/VIP Access
**Settings:** Logo uploaded (180px width), Center position, Transparent header over dark background, Separator disabled
**Setup:** Large centered logo, dramatic dark background, premium feel for exclusive access.
**Best for:** VIP launches, exclusive memberships, luxury brand soft launches
## Layout Behavior
### Desktop Layout
**Solid header:**
* Full-width header bar with background color
* Logo positioned left or center (based on setting)
* Header height: \~80-100px (varies by theme)
* Separator line below (if enabled)
**Transparent header:**
* No background bar (logo floats over password page background)
* Logo positioned left or center
* Separator disabled recommended (or very subtle if enabled)
### Mobile Layout
**Responsive behavior:**
* Header typically full-width on mobile (same as desktop)
* Logo may scale slightly smaller on mobile (theme-dependent)
* Position (left/center) maintained on mobile
* Separator scales to full mobile width
**Logo sizing:**
* Same logo width setting as desktop (some themes scale to \~80% on mobile)
* Test to ensure logo readable on small screens
* May need to reduce logo width if too large on mobile
### Header Height
**Auto-calculated:**
* Header height adjusts to logo height + padding
* Larger logo = taller header
* Smaller logo = shorter header
* Typically minimum height \~60px, maximum \~120px
## Related Sections
* **[Header (Main)](/themes/mojave/header/header)** - Main storefront header (after password entry)
* **[Password Page (Template)](/themes/mojave/pages-templates/password)** - Password page content section
* **[Footer](/themes/mojave/footer/footer)** - Footer (also appears on password page)
## Technical Notes
### When This Header Displays
**Password protection enabled:**
* Shopify Admin → Online Store → Preferences → Password protection → Enabled
* Sets entire storefront to password-protected
* All pages show password page until correct password entered
* Password header displays instead of main header
**Password protection disabled:**
* Main header displays on all pages
* Password header not visible
* To test password header: Enable password protection, view storefront in private window
### Switching Between Headers
**Automatic switching:**
* Theme automatically uses password header on password pages
* Uses main header on all other pages (after password entry)
* No manual configuration needed
**Template structure:**
```liquid theme={null}
{% if template == 'password' %}
{% section 'header-password' %}
{% else %}
{% section 'header' %}
{% endif %}
```
### Transparent Header Implementation
**CSS class:**
```css theme={null}
.header-password--transparent {
background-color: transparent;
position: absolute; /* Overlays password page content */
}
```
**Layout shift:**
* Transparent header position: absolute (doesn't push content down)
* Solid header position: relative (pushes content down by header height)
* Password page must account for header overlap when transparent
### Logo Rendering
**Liquid code:**
```liquid theme={null}
{% if section.settings.logo %}
{% else %}
{{ shop.name }}
{% endif %}
```
**Fallback:**
* If no logo uploaded, displays store name as text (from Shopify settings → Store details → Store name)
### Accessibility
**Logo alt text:**
* Automatically set to store name (e.g., `alt="My Store"`)
* Screen readers announce store name when logo focused
* Important for brand recognition
**Skip link:**
* Many themes include "Skip to content" link before header
* Allows keyboard users to bypass header, jump to password input
* Hidden visually, appears on Tab focus
**Keyboard navigation:**
* Logo typically keyboard-focusable (Tab to logo, Enter to go to homepage)
* On password page, logo may not link anywhere (just branding)
### SEO Implications
**Password page:**
* Not indexed by search engines (blocked by password protection)
* No SEO value until password protection disabled
* Header content (logo alt text) not relevant for SEO while password-protected
**Pre-launch best practice:**
* Add meta description and title in Shopify → Preferences even before launch
* When password removed, SEO content already configured
## Troubleshooting
**Password header not showing:**
* Verify password protection enabled: Shopify Admin → Online Store → Preferences → Password protection
* Check you're viewing password page (logged-out state, private browser window)
* If logged in as staff, you bypass password page (log out or use private window)
**Logo not displaying:**
* Verify logo uploaded in section settings
* Check logo file format (PNG, JPG, SVG supported)
* Try re-uploading logo (may have failed to save)
* Check browser console for image load errors
**Logo too large/small:**
* Adjust "Logo width" slider (50-250px range)
* Preview on desktop and mobile—may need compromise size
* Check logo's original dimensions (very tall logos may need different width)
**Logo hard to see (transparent header):**
* Increase contrast: Upload alternate logo color (white logo for dark background)
* Add dark overlay to password page background image
* Disable transparent header (use solid background)
* Adjust password page background to be lighter/darker
**Logo position not changing:**
* Hard refresh browser (Cmd/Ctrl+Shift+R) to clear CSS cache
* Check theme code for CSS overrides (some themes hard-code position)
* Try toggling position, save, preview again
**Separator line not showing:**
* Ensure "Show line separator" enabled in settings
* Line may be very subtle (check separator color in theme settings)
* If header background same color as line, appears invisible
* Inspect element to see if separator present but color-matched
**Header looks different than main header:**
* Check main header settings (logo width, position, transparency)
* Match password header settings to main header for consistency
* May be intentional design (password header often simpler)
**Mobile header too tall:**
* Reduce logo width (logo height determined by width proportionally)
* Check theme's mobile-specific header padding (may be excessive)
* Test on actual mobile device (not just browser resize)
**Transparent header not working:**
* Clear browser cache (Cmd/Ctrl+Shift+R)
* Check password page template—may have inline styles overriding transparency
* Verify password page section background image/color set (transparent header needs background to show through)
* Inspect element—check for CSS `background-color` overrides
**Logo blurry/pixelated:**
* Upload higher resolution logo (2x display size minimum)
* Use SVG format for perfect scaling (vector graphics)
* Check original logo file quality
* Ensure logo width not enlarged beyond original file dimensions
# Introduction
Source: https://docs.digifist.com/themes/mojave/index
Contemporary design with proven functionality that converts to sales.
Mojave is a Shopify theme for brands that want a clean, conversion-focused storefront with a calming aesthetic. It includes a flexible section system, essential product features, and a full set of customizable templates.
## Presets
Mojave comes with 3 ready-made designs for your store.
A dark, high-impact design with dramatic imagery, built for fashion and apparel brands.
A soft, minimal design with neutral tones, ideal for skincare and wellness brands.
A bold, structured design with vibrant accents, crafted for home decor and furniture stores.
## Products
Flexible block-based product page with media gallery, variants, and dynamic checkout.
Branding configuration for digital gift card pages.
## Collections
Product grid with filtering, sorting, and promotional card injection.
Display all or selected collections with custom imagery and pagination.
Full search results with filtering, sorting, and multi-type results.
## Pages & Templates
Customizable error page that guides lost visitors back to your store.
Article feed with tag filtering and block-based individual article layout.
Full-page cart with item management, discounts, and express checkout.
Account dashboard, login, register, addresses, and order details.
Generic content template for About, policies, and more.
Coming soon page with email signup for pre-launch stores.
## Sections & Theme Settings
Browse the full library of sections available for any page in your store.
Set up navigation, announcement bar, logo, and footer content.
## Resources
See what's new and what's changed in each Mojave release.
# Page (Template Wrapper)
Source: https://docs.digifist.com/themes/mojave/page
Empty template wrapper for basic pages
## What It Does
The **Page** template is an empty section file used as a wrapper for basic Shopify pages (created in Admin → Online Store → Pages). This file contains no content or settings—it serves only as a template assignment placeholder.
This is an **empty template wrapper** with no content or customizable settings. Page content comes from Shopify Admin pages, not this template file.
## How It Works
### Template Purpose
**Standard Shopify architecture:**
* Pages created in Admin → Online Store → Pages
* Each page assigned a template (default: `page.json` or `page.liquid`)
* Template wraps page content with header, footer, and sections
**page.liquid section:**
* Empty file (no liquid code, no schema)
* Acts as placeholder for template system
* Actual page content rendered by Shopify's page object (`{{ page.content }}`)
* Header and footer sections wrap page automatically
### Page Content Source
**Content comes from Admin:**
1. Shopify Admin → Online Store → Pages
2. Create/Edit page
3. Enter title, content (rich text editor)
4. Publish page
5. Page displays on storefront at `/pages/[page-handle]`
**Template just wraps it:**
* Header (navigation)
* Page content (from Admin)
* Footer (footer links, copyright)
## Creating & Editing Pages
### In Shopify Admin
**Steps:**
1. Online Store → Pages → Add page
2. Enter page title (e.g., "About Us," "Shipping Policy")
3. Write content in rich text editor (supports formatting, images, links)
4. Set SEO metadata (title, description)
5. Select template (usually "Default page" which uses page.liquid)
6. Set visibility (Published / Hidden)
7. Save
**Result:** Page accessible at `yourstore.com/pages/[page-handle]`
### Common Page Types
**Standard store pages:**
* About Us
* Contact Us (or use Contact form section instead)
* Shipping Policy
* Return Policy / Refund Policy
* Privacy Policy
* Terms of Service / Terms & Conditions
* FAQ / Help Center
* Sizing Guide
* Store Locator (or use dedicated section)
## Best practices
Shopify rich text editor supports formatting, images, links. No HTML/code needed for basic pages.
Set page title and meta description in Admin. Helps search engines index pages, improves SEO.
Add important pages to main navigation (Header menu). Customers can easily find About, Policies, Contact pages.
Add policy pages (Privacy, Terms, Refund) to footer. Standard e-commerce practice, builds trust.
## Related Pages
* **\[Main Page Template]\(/themes/mojave/pages-templates/page** - Main page template (if different from this empty wrapper)
* **[Contact Page](/themes/mojave/sections/contact-form)** - Contact form template
* **[Header](/themes/mojave/header/header)** - Navigation that links to pages
* **[Footer](/themes/mojave/footer/footer)** - Footer that links to policy pages
## Technical Notes
### Empty File
**File contents:**
* page.liquid contains no code (empty file)
* Template system expects file to exist (placeholder)
* Actual page rendering handled by Shopify core (not theme)
**Why empty:**
* Theme may use `page.json` (JSON template) instead of `page.liquid`
* Or uses different page template structure
* This file exists for backwards compatibility or template assignment
### Template Assignment
**Each page can use different template:**
* Default: `page` (uses page.liquid or page.json)
* Custom: `page.contact`, `page.about`, etc. (custom page templates)
* Selected in Admin → Pages → \[Page] → Template dropdown
**Custom page templates:**
* Create custom templates for specific pages (e.g., `page.about.liquid`)
* Add custom sections, layouts
* Assign to specific pages in Admin
## Key Takeaways
* **Empty template file** - No content, no settings, acts as wrapper placeholder
* **Page content in Admin** - Create/edit pages in Online Store → Pages
* **Automatic wrapping** - Header and footer wrap page content automatically
* **No customization here** - To modify page layout, edit template JSON/Liquid or use custom page templates
* **Standard pages** - About, Policies, FAQ, etc. created as Shopify pages using this template
* **SEO important** - Set page title/description in Admin for search engine optimization
To create pages, go to Shopify Admin → Online Store → Pages → Add page. For custom page layouts, create custom page templates or use page sections.
# 404 Error Page
Source: https://docs.digifist.com/themes/mojave/pages-templates/404
404 error page template for page not found errors
## What It Does
The **404 Page** template displays when visitors navigate to a non-existent page on your store (broken link, deleted product, mistyped URL). This template provides a user-friendly error message and navigation options to help customers find what they're looking for.
This is a **static template section** with no customizable settings. Content and layout are coded in the template file. To customize, edit the template code directly or use theme customization apps.
## Template Structure
### Default Content
**Typical 404 page includes:**
* **Error message** - "404 Page Not Found" or similar heading
* **Explanation text** - Brief message (e.g., "The page you're looking for doesn't exist")
* **Search bar** - Allows customers to search for products/pages
* **Navigation links** - Links to homepage, collections, or popular pages
* **Visual element** - Icon, illustration, or branded imagery
### User Experience
**When 404 page displays:**
1. Customer clicks broken link or types wrong URL
2. Server can't find page (404 error)
3. Theme displays 404 template instead of blank error
4. Customer sees friendly message and navigation options
5. Customer searches or clicks link to continue browsing
## Common Scenarios
### Broken External Links
**Scenario:** Customer clicks old link from Google search or external blog\
**Solution:** 404 page helps customer search for product or navigate to collections
### Deleted Products/Collections
**Scenario:** Product discontinued and deleted, but link still circulating\
**Solution:** 404 page prevents dead end, offers alternatives
### Mistyped URLs
**Scenario:** Customer types incorrect URL manually\
**Solution:** 404 page politely corrects course with navigation
### Moved Pages
**Scenario:** Store restructured, URLs changed\
**Solution:** 404 page catches old URLs before implementing redirects
## Best practices
Use friendly, non-technical language. "Oops! Page Not Found" better than "Error 404: HTTP Not Found".
Include search bar prominently. Customers can find what they need without leaving 404 page.
Add links to homepage, collections, popular category pages. Give customers clear next steps.
For known broken URLs (moved/deleted pages), set up redirects in Shopify Admin → Navigation → URL Redirects.
Monitor which URLs trigger 404s (Google Analytics, Shopify apps). Identify patterns and fix broken links.
Match 404 message to brand personality. Playful brands can use humor, professional brands stay formal.
Visit non-existent URL on your store to preview 404 page. Ensure search works and links are current.
404 page should be fully responsive. Buttons easily tappable, search bar functional on mobile.
## Customization Options
### Via Theme Customizer (Limited)
**No settings available in this section**, but other sections may appear on 404 page:
* Header section (standard navigation)
* Footer section (standard footer)
* Additional sections (if theme allows adding sections to 404 template)
### Via Code Editing
**For developers:**
* Edit `templates/404.json` (JSON template) or `templates/404.liquid` (Liquid template)
* Modify section `/sections/section-404.liquid`
* Customize heading text, description, search styling, navigation links
* Add custom illustrations or animations
### Via Apps
**3rd-party apps:**
* "404 Page Redirect" apps can auto-redirect to relevant pages
* "Related Products" apps can show product recommendations on 404
* Check Shopify App Store for "404 customization" apps
## SEO & Technical Notes
### HTTP Status Code
**Important:** Page must return proper 404 HTTP status code (not 200)
* Shopify templates automatically return 404 status
* Tells search engines page doesn't exist (prevents indexing bad URLs)
* Preserves SEO health (broken links don't dilute site authority)
### Not Indexed by Google
**404 pages are not indexed:**
* Search engines recognize 404 status, don't add to search results
* No SEO value to optimize 404 page content for keywords
* Focus on user experience, not SEO
### URL Redirects Alternative
**Instead of showing 404 error:**
1. Shopify Admin → Navigation → URL Redirects
2. Add redirect: Old URL → New URL
3. Customer redirected automatically (no 404 page shown)
4. **Use when:** Known broken URLs (deleted products, moved pages)
## Troubleshooting
**404 page not displaying:**
* Check theme includes `/templates/404.json` or `/templates/404.liquid` file
* Some themes may have broken 404 template (reinstall theme or contact support)
**Search not working on 404 page:**
* Verify search functionality works on main site (test in header search)
* If broken on 404 only, likely template code issue (needs developer review)
**Custom content not showing:**
* If edited template/section code, clear browser cache (Cmd/Ctrl+Shift+R)
* Check for liquid syntax errors in code editor
* Preview in incognito window (avoids cache issues)
**404 page showing on valid pages:**
* URL likely broken (check spelling, ensure page published)
* Check Shopify Admin → Online Store → Pages/Products for page status
* If page exists but shows 404, may be theme template assignment issue
**Too many 404 errors:**
* Check Google Search Console for 404 report (identifies broken URLs)
* Common causes: Deleted products still linked externally, old URLs from Google
* Set up URL redirects for high-traffic broken URLs
## Related Documentation
* **[Password Page](/themes/mojave/pages-templates/password)** - Password protection page template
* **[Header](/themes/mojave/header/header)** - Navigation that appears on 404 page
* **[Footer](/themes/mojave/footer/footer)** - Footer that appears on 404 page
* **[Search Results](/themes/mojave/collections/search)** - Search results page (where 404 search directs)
## Key Takeaways
* **No settings to configure** - 404 template is static, styled by theme
* **Friendly error message** - Helps customers recover from broken links
* **Include search and navigation** - Don't trap customers on dead-end page
* **Set up redirects** - For known broken URLs, redirect instead of showing 404
* **Returns proper 404 HTTP status** - Tells search engines page doesn't exist
* **Not indexed by Google** - No SEO value, focus on user experience
* **Customization requires code editing** - Or use apps for advanced features
For custom 404 page design, contact a Shopify developer or explore 404 customization apps in Shopify App Store.
# Article Template (main-article)
Source: https://docs.digifist.com/themes/mojave/pages-templates/article
Configure your blog post article page with featured images, metadata, social sharing, and comments
The Blog post template (main-article) controls how individual blog articles display on your store. It provides customization for featured images, article metadata, social sharing, and comment pagination through a flexible block system.
## What this section controls
* Featured image display and sizing
* Article title with date and author
* Article content display
* Tag display (links or badges)
* Back to blog navigation
* Social media sharing buttons
* Comment pagination
* Third-party app integrations
## Getting started
In your Shopify admin, go to **Online Store > Themes** and click **Customize** on your active theme.
Use the page selector dropdown to select **Blog posts** and choose any article to preview.
The "Blog post" section controls the main article template. Additional sections can be added below it.
## Template settings
Displays a navigation link at the top of the article that returns readers to the parent blog. Enabled by default.
**Benefits**:
* Improves blog navigation and user experience
* Encourages readers to browse more articles
* Reduces bounce rate by providing clear exit path
**When to disable**: If you prefer custom navigation or want readers to focus only on current article without distraction.
Displays social media sharing buttons allowing readers to share the article. Enabled by default.
**Included networks** (based on theme settings social media configuration):
* Facebook
* Twitter/X
* Pinterest
* LinkedIn
* Email
**Benefits**:
* Increases article reach through social sharing
* Builds backlinks and referral traffic
* Encourages reader engagement
**Best practices**: Keep enabled for content marketing and traffic growth. Position near article end or after compelling content.
Controls how many comments display before pagination (2-20 comments, default: 5).
**Sizing recommendations**:
* **5-10 comments** (default: 5): Standard, keeps page manageable
* **15-20 comments**: High-engagement blogs, reduces pagination clicks
* **2-3 comments**: Long detailed comments, preserves page load speed
**Requirements**:
* Shopify blog comments must be enabled in blog settings
* Comments are moderated through Shopify admin
**Note**: Lower numbers improve page performance but increase pagination clicks. Higher numbers show more engagement but may slow page load.
## Block settings
Build your article page by adding and arranging blocks. Typical order: Featured Image → Title → Content → Tags.
Displays the article's featured image. Limit 1 per article page.
**Configuration**:
* **Featured image height**: Choose aspect ratio for image display:
* **Adapt to image**: Uses natural aspect ratio, no cropping
* **Small (16:9)**: Widescreen format, good for landscape photography
* **Medium (4:3)**: Balanced ratio, traditional photography format
* **Large (3:4)**: Portrait format, taller images
**Image source**: Automatically pulls from article.image set in blog post editor.
**Best practices**:
* Use 16:9 ratio for consistency across articles
* Recommended size: 1200x675px minimum for crisp display
* Optimize images before upload (compress to reduce file size)
* Choose "Adapt to image" if you have varying image dimensions
**Info**: For best results, use images with 16:9 aspect ratio. [Learn more about image aspect ratios](https://help.shopify.com/en/manual/shopify-admin/productivity-tools/image-editor#understanding-image-aspect-ratio)
Displays article title with optional metadata. Limit 1 per article page.
**Configuration**:
* **Show date**: Display article publish date (enabled by default)
* **Show author**: Display article author name (enabled by default)
**Metadata display**: Date and author appear below the article title.
**When to show metadata**:
* **Show both**: Multi-author blogs, time-sensitive content, news articles
* **Date only**: Single-author blogs where authorship is implied
* **Neither**: Timeless evergreen content where dates may reduce perceived value
**SEO note**: Title automatically includes proper heading structure (H1) for search optimization.
Displays the main article content. Limit 1 per article page.
No configuration needed - automatically renders full article content including:
* Rich text formatting
* Embedded images
* Videos
* Links
* Lists and blockquotes
**Content editing**: Edit article content in **Shopify Admin → Online Store → Blog posts → \[Article]**.
Displays article tags as clickable links or visual badges. Limit 1 per article page.
**Configuration**:
* **Tags type**: Choose visual style:
* **Links** (default): Plain text links with separators
* **Badges**: Styled pill/badge buttons
**Tag functionality**: Tags are clickable and filter the blog to show all articles with that tag.
**Tag management**: Add tags when creating/editing articles in Shopify admin. Tags help with:
* Article categorization
* Content filtering for readers
* Internal linking and navigation
* SEO through topical grouping
**Best practices**:
* Use 3-7 tags per article
* Create consistent tag naming conventions
* Use badges for modern aesthetic, links for minimal design
* Position tags at article end or near social sharing
Integration point for third-party blog apps. Unlimited blocks allowed.
**Common blog apps**:
* Comment systems (Disqus, Facebook Comments)
* Related posts recommendations
* Email subscription widgets
* Reading time calculators
* Table of contents generators
* Social proof widgets
No configuration needed - apps appear automatically when installed and configured.
## Managing blog comments
Article comments are managed through Shopify's built-in blog comment system.
Go to **Shopify Admin → Online Store → Blog posts → Manage blogs → \[Your blog] → Edit**.
Check "Comments are" and choose moderation setting:
* **Disabled**: No comments
* **Moderate**: Approve before publishing
* **Published automatically**: Immediate publishing
View and manage comments at **Shopify Admin → Online Store → Blog posts → Comments**.
You can approve, spam, or delete comments.
Set "Comments per page" in the template settings. Lower numbers (5-10) are recommended for performance.
**Comment best practices**:
* Use moderation to prevent spam
* Respond to legitimate comments to encourage engagement
* Monitor comments regularly for quality discussions
## Best practices
Use the same aspect ratio across all articles (16:9 recommended). Creates cohesive visual experience and professional appearance.
Keep social sharing enabled to amplify content reach. Position after article content when readers are primed to share valuable insights.
Show dates for time-sensitive content (news, updates). Hide dates for evergreen content to maintain perceived freshness.
Create 5-10 core topic tags and use consistently across articles. Avoid tag sprawl - consolidate similar tags (e.g., "Fashion Tips" not "fashion", "Fashion", "fashion-tips").
Compress images before upload (aim for under 200KB). Use tools like TinyPNG or ImageOptim. Large images slow page load significantly.
Use badge-style tags for contemporary design. Link-style tags suit minimalist or text-heavy blogs.
The return navigation improves user experience and keeps readers engaged with more content. Only remove if you have custom navigation.
Set comments to moderated to prevent spam. Respond to genuine comments quickly to build community and encourage future engagement.
Standard order works best: Featured Image → Title → Content → Tags → Comments. Social sharing typically appears near content end.
Keep at 5-10 comments per page for optimal performance. Long comment threads slow page load and overwhelm readers.
# Blog Template (main-blog)
Source: https://docs.digifist.com/themes/mojave/pages-templates/blog
Configure your blog listing page with hero banner, article cards, and tag filtering
The Main Blog template (main-blog) controls how your blog listing page displays articles. It features a customizable hero banner with images and filtering, plus full control over article card metadata and pagination.
## What this section controls
* Hero banner with custom images and content
* Tag-based filtering interface
* Article cards with metadata display options
* Articles per page pagination
* Article excerpts, tags, dates, and authors
* Tag count display per article
## Getting started
In your Shopify admin, go to **Online Store > Themes** and click **Customize** on your active theme.
Use the page selector dropdown to select **Blogs** and choose your blog to preview.
The "Main Blog" section controls the blog listing template.
## Template settings
Upload separate hero images for mobile and desktop. **Both images are required** for the hero to display properly.
**Main image - Mobile**:
* Recommended size: 800x600px minimum
* Portrait or square orientation works best
* Optimized for vertical mobile viewports
**Main image - Desktop**:
* Recommended size: 1920x600px minimum
* Landscape orientation
* Wide format for desktop hero banners
**Image tips**:
* Use high-quality images that represent your blog content
* Ensure sufficient contrast for overlaid text
* Consider image focal point - text appears centered
* Compress images before upload (under 500KB ideal)
Controls the darkness of the overlay on hero images (0-100%, default: 50%).
**Overlay purpose**: Creates contrast between hero image and overlaid text for readability.
**Adjustment guidance**:
* **0-30%**: Light overlay, for dark images with good text contrast
* **40-60%** (default: 50%): Balanced overlay for most images
* **70-100%**: Heavy overlay for very bright images or maximum text emphasis
Test with your specific images to ensure title and content remain readable.
Custom hero title text that replaces the default blog name.
**When to customize**:
* Create more engaging headline than blog name alone
* Add context or value proposition (e.g., "Design Inspiration & Tips")
* Maintain consistency with overall brand messaging
**Leave blank** to use default blog name from Shopify settings.
**Character guidance**: 30-60 characters works best for most displays.
Rich text description or subtitle below the hero title.
**Content ideas**:
* Brief blog description or mission statement
* What readers will find (e.g., "Weekly insights on sustainable fashion")
* Call to action (e.g., "Discover our latest stories")
* Publication frequency (e.g., "New articles every Tuesday")
**Formatting**: Supports rich text (bold, italic, links).
**Length**: 1-2 sentences (100-200 characters) for optimal readability.
Displays tag filter buttons in the hero area. Enabled by default.
**When enabled**: Readers can click tags to filter articles by topic.
**Filtering behavior**:
* Shows all tags used across blog articles
* Clicking tag filters to show only articles with that tag
* "All" button returns to full article list
**When to disable**:
* Small blogs with few articles where filtering isn't needed
* Single-topic blogs without diverse tags
* You prefer manual navigation over filtering
Recommended to keep enabled for blogs with 10+ articles and multiple topics.
Controls pagination - how many articles display before "Load more" or pagination (2-50 articles, default: 20).
**Sizing recommendations**:
* **12-20 articles** (default: 20): Standard range, balances browsing with performance
* **6-10 articles**: Image-heavy blogs, reduces page load time
* **25-50 articles**: Text-heavy blogs, reduces pagination clicks
**Performance considerations**:
* More articles = longer initial page load
* Fewer articles = more pagination interactions
* Consider featured image sizes - larger images favor fewer articles
**Best practice**: Keep at 15-25 for optimal user experience.
Control how many tags show per article in the listing.
* **Show all** (default): Display all tags assigned to each article
* **Show first**: Display only the first tag per article
**Show all** benefits:
* Complete topic visibility
* Better for content discovery
* Helps readers understand article scope
**Show first** benefits:
* Cleaner, less cluttered appearance
* Focus on primary topic
* Better for articles with many tags
Choose based on your tagging strategy and visual preference.
Show or hide article tags in listing cards. Enabled by default.
**When enabled**: Tags appear as links below article excerpt, allowing topic-based filtering.
**When to keep enabled**:
* Multi-topic blogs where categorization helps readers
* You use tags consistently across articles
* Content discovery through topics is important
**When to disable**:
* Single-topic focused blog
* Minimalist design preference
* Tags aren't consistently used
Display article excerpt (preview text) in listing cards. Enabled by default.
**Excerpt generation**: Automatically pulls first \~200 characters from article content.
**Benefits of showing excerpts**:
* Helps readers decide which articles to read
* Provides context beyond just titles
* Improves click-through rates on relevant content
* Creates more substantial article cards
**When to disable**:
* Very short articles where excerpt doesn't add value
* Image-focused blog where visuals are primary draw
* Minimalist design with title and image only
Strongly recommended to keep enabled for content engagement.
Display publish date in article cards. Enabled by default.
**When to show dates**:
* Time-sensitive content (news, updates, trends)
* Establishes recency and credibility
* Readers care about content freshness
* Regular publishing schedule you want to highlight
**When to hide dates**:
* Evergreen content where dates reduce perceived value
* Older articles you don't want marked as "old"
* Irregular publishing where dates call attention to gaps
Consider your content strategy - timely vs. timeless.
Display author name in article cards. Enabled by default.
**When to show authors**:
* Multi-author blogs where attribution matters
* Building personal brands for contributors
* Author expertise adds credibility
* Team blog highlighting different perspectives
**When to hide authors**:
* Single-author blog where attribution is implied
* Brand-focused content over personal attribution
* Minimalist card design
For single-author blogs, hiding author reduces redundancy.
## Configuring tags for filtering
Tags are managed when creating/editing blog articles in Shopify admin.
Go to **Shopify Admin → Online Store → Blog posts → \[Select article]**.
In the right sidebar under "Tags", enter tags separated by commas.
Tags automatically become filterable in your blog listing.
Create standardized tag names across articles:
* "Fashion Tips" not "fashion", "Fashion", "tips", "fashion-tips"
* Capitalize consistently
* Use 1-2 words per tag
* Aim for 5-10 core tags across your blog
**Tag best practices**:
* Limit to 3-7 tags per article
* Create core topic tags and reuse them
* Avoid one-off tags (consolidate similar tags)
* Tags should represent browseable topics, not keywords
## Best practices
Upload optimized mobile and desktop hero images. Missing either image will break hero layout. Desktop landscape (1920x600px), mobile portrait (800x600px).
Adjust overlay (40-60%) to ensure hero text remains readable against your images. Test across different devices and lighting conditions.
Use custom title and content to set expectations and intrigue readers. Bland "Blog" title wastes valuable hero space.
Keep tag filtering enabled for blogs with 10+ articles. Helps readers discover relevant content without scrolling through everything.
Keep excerpt, tags, and date enabled for content blogs. Only minimal designs or image-focused blogs benefit from hiding these.
Start with 15-20 articles per page. Adjust based on image sizes and page load performance. Monitor bounce rates.
Create 5-10 core tags and use consistently. Tag sprawl (50+ unique tags) defeats filtering purpose and looks messy.
Hide dates on evergreen content blogs to maintain perceived freshness. Older valuable content shouldn't seem outdated.
Large hero images (over 500KB) significantly slow page load. Use TinyPNG or similar before upload. Target under 300KB.
For articles with many tags (7+), use "Show first" to avoid cluttering cards. For 3-5 tags, "Show all" works well.
# Cart page
Source: https://docs.digifist.com/themes/mojave/pages-templates/cart
Main cart items template displaying shopping cart contents
The Cart items template (main-cart-items) displays the shopping cart page when customers click the cart icon (for stores not using cart drawer).
## What this section controls
* Cart items list with quantities
* Remove item functionality
* Cart total calculation
* Checkout button
* Empty cart message
## Getting started
In your Shopify admin, go to **Online Store > Themes** and click **Customize** on your active theme.
Use the page selector dropdown to select **Cart** to preview the cart page.
The "Cart items" section controls the main cart template (when not using cart drawer).
## Template settings
This section has **no customizable settings** - cart functionality is automatic and controlled by theme settings.
**Automatic features**:
* Cart item list with product images
* Quantity adjustment (+/- buttons)
* Remove item buttons
* Price calculations (subtotal, totals)
* Checkout button
* Empty cart state
* Continue shopping link
**Cart type**: Whether this page or cart drawer displays is controlled in **Theme Settings → Cart**.
## Best practices
Regularly test adding items, updating quantities, and removing items to ensure smooth cart experience.
Many stores prefer cart drawer over cart page for faster checkout flow. Configure in Theme Settings → Cart.
Use additional sections on cart template for product recommendations, shipping thresholds, or trust badges.
Track cart abandonment rates - high rates may indicate checkout friction beyond cart display itself.
# Account Dashboard
Source: https://docs.digifist.com/themes/mojave/pages-templates/customers/account
Customer account dashboard page showing order history and account overview
## What It Does
The **Account Dashboard** template displays when logged-in customers visit `/account`. This page serves as the main customer account hub, showing recent order history, account details, and navigation to other account pages (addresses, orders).
This is a **static template section** with no customizable settings. Layout and content are coded in the template. Customization requires code editing.
## Template Content
### Default Sections
**Typical account dashboard includes:**
* **Welcome message** - "Welcome, \[Customer Name]"
* **Account navigation** - Links to Orders, Addresses, Account Details
* **Recent orders** - List of recent orders (order number, date, total, status)
* **Account overview** - Email, default address summary
* **Logout button**
### User Experience
**Customer flow:**
1. Customer logs in (via `/account/login`)
2. Redirected to account dashboard (`/account`)
3. Views recent orders, account info
4. Clicks navigation links to view full order history, edit addresses, etc.
## Best practices
Account navigation should be prominent. Customers need easy access to Orders, Addresses, Account Settings pages.
Display 3-5 most recent orders on dashboard. Link to full orders page for complete history.
Account dashboard sees heavy mobile traffic. Ensure navigation tappable, orders readable on small screens.
Logout button should be easily found (typically in account navigation or top-right).
## Related Pages
* **[Login Page](/themes/mojave/pages-templates/customers/login)** - Customer login (entry to account)
* **[Orders Page](/themes/mojave/pages-templates/customers/order)** - Full order history
* **[Addresses Page](/themes/mojave/pages-templates/customers/addresses)** - Manage shipping addresses
* **[Registration](/themes/mojave/pages-templates/customers/register)** - Create customer account
## Key Takeaways
* **No settings to configure** - Template is static, no customization options in Theme Customizer
* **Account hub** - Starting point for customer account activities
* **Shows recent orders** - Quick view of order history (full history on Orders page)
* **Navigation to account pages** - Links to Orders, Addresses, Account Details
* **Requires login** - Customers must be logged in to access (redirects to login if not)
* **Customization via code** - To modify layout/content, edit template code or use apps
For custom account dashboard design, contact a Shopify developer or explore customer account customization apps.
# Activate Account
Source: https://docs.digifist.com/themes/mojave/pages-templates/customers/activate-account
Customer account activation page for email verification
## What It Does
The **Activate Account** template displays when customers need to verify their email address after registration (if email verification enabled in Shopify settings). This page allows customers to set their password after clicking the activation link sent to their email.
This is a **static template section** with no customizable settings. Activation functionality is standard Shopify behavior. This page only appears if "email verification" is enabled in Admin settings.
## When This Page Displays
### Email Verification Enabled
**Activate in Shopify Admin:**
* Settings → Customer accounts → Enable "Customers must verify email"
* After registration, customers receive activation email
* Cannot login until email verified (clicks activation link)
**Without email verification:**
* This page never displays
* Customers set password during registration, login immediately
* No email verification step
## Template Content
### Default Activation Form
**Typical activate account page includes:**
* **Heading** - "Activate Your Account" or "Set Your Password"
* **Email display** - Shows customer's email (read-only)
* **Password** input (create password for new account)
* **Confirm password** input (re-enter password)
* **"Activate account" button**
* **Instructions** - Explanation of activation process
### User Experience
**Account activation flow:**
1. Customer registers on `/account/register`
2. Sees message "Check email to activate account"
3. Receives activation email (contains secure activation link)
4. Clicks activation link in email
5. Lands on activate account page (`/account/activate/[token]`)
6. Sets password (enters twice for confirmation)
7. Clicks "Activate account" button
8. Account activated, customer logged in automatically
9. Redirected to account dashboard
## Best practices
Explain activation process on registration page ("Check email to activate account"). Sets customer expectations.
Activation emails sometimes lands in spam. Instruct customers to check spam/junk if email doesn't arrive.
Provide "Resend activation email" button/link. Customers may need new link if didn't receive or expired.
Display password requirements clearly (minimum 5 characters). Reduces form errors.
Activation links expire (typically 7 days). Communicate expiration, offer resend option.
After activation, log customer in automatically. Eliminates extra login step.
Include support link if customer can't receive activation email. Provide manual activation alternative.
Email verification adds friction. Consider disabling for most stores (enable only if spam/fake accounts are issue).
## Email Verification Settings
### Enable/Disable in Admin
**Shopify Admin → Settings → Customer accounts:**
**"Customers must verify email" (checkbox):**
* **Enabled:** Customers receive activation email after registration, must verify before login
* **Disabled (Default):** Customers set password during registration, login immediately, no verification
**When to enable:**
* High spam/fake account registrations
* B2B store requiring verified business emails
* Compliance requirements (verified customer data)
* Want to confirm customer email accuracy
**When to disable (Recommended):**
* Standard e-commerce stores (adds unnecessary friction)
* Maximize conversion (extra step reduces registrations)
* Customers purchase without accounts (guest checkout primary)
## Related Pages
* **[Registration](/themes/mojave/pages-templates/customers/register)** - Registration page (triggers activation email)
* **[Login Page](/themes/mojave/pages-templates/customers/login)** - Login page (can't login until activated)
* **[Account Dashboard](/themes/mojave/pages-templates/customers/account)** - Redirected here after activation
* **[Password Reset](/themes/mojave/pages-templates/customers/reset-password)** - Reset password (for activated accounts)
## Technical Notes
### Activation Link Token
**Security:**
* Activation link contains unique, secure token
* Token tied to customer account + email
* Expires after 7 days (default, may vary by Shopify plan)
* One-time use (token invalidated after activation)
**URL structure:**
```
yourstore.com/account/activate/[unique-token]
```
### Activation Email
**Sent via:**
* Shopify's transactional email system
* Automatically sent upon registration (if verification enabled)
* From address: `noreply@shopify.com` (or custom sender)
* Can customize: Admin → Settings → Notifications → Customer account invite
**Email content:**
* Subject: "Activate your \[Store Name] account"
* Body: Activation link button, instructions
* Customizable via Liquid templates in Admin
### Account Status Before Activation
**Unactivated account:**
* Exists in Admin → Customers list (status: "Disabled" or "Not activated")
* Cannot login (activation required)
* Cannot make purchases (must activate first)
* Not subscribed to marketing emails until activated
**After activation:**
* Status changes to "Active"
* Can login with email + password
* Full account functionality
## Troubleshooting
**Activation email not received:**
* Check spam/junk folder (most common)
* Verify email address correct during registration
* Email provider may block Shopify emails (whitelist `noreply@shopify.com`)
* Request new activation email (contact store support or re-register)
**Activation link expired:**
* Links expire after 7 days (varies by plan)
* Contact store support for manual activation or re-registration
* Store owner can send new invitation: Admin → Customers → \[Customer] → Send account invitation
**"Invalid token" error:**
* Link already used (one-time use)
* Link expired (7 day limit)
* URL malformed (email client broke link—copy entire URL)
* Request new activation link
**Can't set password (validation error):**
* Password must be minimum 5 characters
* Ensure passwords match (password + confirm password identical)
* No leading/trailing spaces
* Try simpler password, then update to stronger later
**Account shows activated but can't login:**
* Verify using correct email (registered email)
* Try password reset (may have forgotten password set during activation)
* Check Admin customer status (should show "Active")
* Contact Shopify Support if persists
## Key Takeaways
* **No template settings** - Activation page is static, no customization options
* **Only appears if verification enabled** - Admin → Settings → Customer accounts → "Customers must verify email"
* **Activation email required** - Customers click link in email to reach activation page
* **Set password on activation** - Unlike registration where password set immediately
* **Link expires (7 days)** - Security measure (request new link if expired)
* **Auto-login after activation** - Customer logged in automatically upon successful activation
* **Adds friction** - Email verification reduces registrations (disable unless necessary)
* **Customization via email templates** - Customize activation email in Admin → Notifications
**Recommendation:** Keep email verification disabled for most stores (standard behavior). Enable only if spam accounts, B2B verification, or compliance requirements justify added friction.
# Addresses
Source: https://docs.digifist.com/themes/mojave/pages-templates/customers/addresses
Customer address book page for managing shipping and billing addresses
## What It Does
The **Addresses Page** template displays when logged-in customers navigate to `/account/addresses` to manage saved shipping and billing addresses. Customers can add new addresses, edit existing ones, set a default address, and delete old addresses.
This is a **static template section** with no customizable settings. Address management functionality is standard Shopify behavior. Customization requires code editing.
## Template Content
### Default Address Management Interface
**Typical addresses page includes:**
* **Heading** - "Addresses" or "Address Book"
* **Add new address button** - Opens form to add address
* **Saved addresses list** - All customer's saved addresses displayed as cards
* **Default address indicator** - Badge/label showing default shipping address
* **Edit button** (per address) - Edit address details
* **Delete button** (per address) - Remove address from account
* **"Set as default" button** (per address) - Make this the default address
### Address Card Display
**Each saved address shows:**
* Name (First + Last)
* Address line 1
* Address line 2 (if provided)
* City, Province/State, Zip/Postal code
* Country
* Phone number (if provided)
* Default badge (if default address)
## User Experience
**Managing addresses flow:**
1. Customer logs in, navigates to account
2. Clicks "Addresses" in account navigation
3. Lands on addresses page (`/account/addresses`)
4. Views all saved addresses
5. Clicks "Add new address" → Fills form → Saves
6. Or clicks "Edit" on existing address → Updates fields → Saves
7. Or clicks "Delete" on address → Confirms deletion
8. Or clicks "Set as default" → Address marked as default for checkout
## Best practices
"Add new address" button should be easily found (top of page or prominent position). Customers need clear way to add addresses.
Clearly mark default address (badge, icon, different styling). Customers should know which address is used at checkout.
Make edit/delete buttons visually distinct. Prevent accidental deletions (use confirmation modal for delete).
Validate addresses on save (correct format, valid zip code). Reduces shipping errors, returns.
Address forms often used on mobile. Ensure form inputs large, easy to tap, appropriate keyboard types (number pad for zip code).
No hard limit on saved addresses. Customers can save home, work, gift recipient addresses without deleting old ones.
When editing, pre-fill form with existing address data. Customers only update changed fields.
Show confirmation after add/edit/delete ("Address saved!", "Address deleted"). Provides feedback.
## Address Form Fields
### Standard Fields
**Required fields:**
* First name
* Last name
* Address line 1
* City
* Country
* Province/State (if applicable to country)
* Zip/Postal code
**Optional fields:**
* Address line 2 (apartment, suite, unit)
* Company (for business addresses)
* Phone number
**Auto-populated:**
* Country (defaults to store's primary country)
* Province/State dropdown (populated based on country selection)
## Related Pages
* **[Account Dashboard](/themes/mojave/pages-templates/customers/account)** - Account hub (links to Addresses page)
* **[Orders Page](/themes/mojave/pages-templates/customers/order)** - Order history (uses saved addresses for shipping)
* **[Checkout](/themes/mojave/checkout)** - Checkout uses default address (or customer selects from saved addresses)
## Technical Notes
### Default Address
**Behavior:**
* First address added automatically becomes default
* Default address pre-selected at checkout (customer can change)
* Only one default address per customer
* Setting new default removes default status from previous address
**Checkout integration:**
* At checkout, default address auto-fills shipping address form
* Customer can select different saved address from dropdown/list
* Or enter new address (can save to account during checkout)
### Address Limits
**No hard limit:**
* Customers can save unlimited addresses (practical limit \~20-30)
* No Shopify-imposed maximum
* Theme typically displays all addresses (may paginate if many)
### Address Data Storage
**Stored in customer object:**
* Addresses saved to customer account in Shopify database
* Accessible via Liquid customer object: `{{ customer.addresses }}`
* Persists across sessions (saved until customer deletes)
### Address Validation
**Shopify provides:**
* Basic validation (required fields, format checking)
* Province/State validation (must match selected country)
* Zip/Postal code format validation (country-specific)
**Advanced validation:**
* Requires apps or custom code (e.g., Google Address Validation API)
* Verifies address exists, suggests corrections
### Edit vs Delete
**Edit:**
* Opens pre-filled form with address data
* Customer updates fields
* Saves changes (overwrites old address, same ID)
**Delete:**
* Removes address from customer account
* Cannot be undone (customer must re-add if mistake)
* If deleting default address, another address becomes default (or no default if last address)
## Troubleshooting
**Can't add new address:**
* Verify all required fields filled (First name, Last name, Address 1, City, Country, Province, Zip)
* Check zip/postal code format (must match country's format—e.g., US 12345 or 12345-6789)
* Province/State may not match country (re-select country first, then province)
* Browser console errors? May be JavaScript issue (refresh page, try different browser)
**Address not saving:**
* Check internet connection (must be online to save)
* Try submitting again (may have been temporary server issue)
* Verify logged in (session may have expired—log back in)
* Check browser console for errors (may be theme bug)
**Can't edit address:**
* Try deleting and re-adding (workaround if edit broken)
* Check theme supports address editing (older themes may have bugs)
* Clear browser cache, try again
* Contact theme support if persists
**Can't delete address:**
* Some themes don't allow deleting default address (set different default first, then delete)
* Try hard refresh (Cmd/Ctrl+Shift+R)
* Check theme code supports delete (older themes may not have delete button)
**Default address not applying at checkout:**
* Verify address set as default (badge/star indicator on address)
* Try setting default again (may not have saved properly)
* Clear browser cookies, log in again
* Check checkout page refreshed (may be showing cached address)
**Province/State dropdown empty:**
* Select country first (province dropdown populates based on country)
* Some countries don't have provinces (dropdown doesn't appear—normal)
* If country has provinces but dropdown empty, may be theme bug
**Address format looks wrong:**
* Different countries have different formats (US vs UK vs Japan address formats)
* Shopify auto-formats based on country selection
* If incorrect, may need to manually format in form (or contact theme developer)
**Mobile form not working:**
* Check form inputs large enough to tap (48x48px minimum)
* Ensure correct keyboard type (number pad for zip code, full keyboard for address)
* Test on actual device (browser mobile emulation may not match real behavior)
## Key Takeaways
* **No template settings** - Addresses page is static, no customization in Theme Customizer
* **Manage shipping addresses** - Add, edit, delete, set default address
* **Default address used at checkout** - Pre-fills shipping address form (customer can change)
* **No limit on saved addresses** - Customers can save unlimited addresses (home, work, gifts)
* **Required fields** - Name, address line 1, city, country, province, zip/postal code
* **First address is default** - Automatically becomes default when added (change later)
* **Edit pre-fills form** - Existing address data populates form for easy updating
* **Delete requires confirmation** - Prevent accidental address deletion
* **Mobile-optimized** - Form inputs should be large, easy to tap on mobile
* **Customization via code** - Modify layout or add features via theme code editing
For custom address book features (address validation, auto-complete, custom fields), explore Shopify apps or hire a developer.
# Login
Source: https://docs.digifist.com/themes/mojave/pages-templates/customers/login
Customer login page template with optional Shop Pay sign-in
## What It Does
The **Login Page** template displays when customers navigate to your store's `/account/login` page to sign in to their customer account. This template shows a login form (email + password) and optionally the "Sign in with Shop" button powered by Shop Pay for faster authentication.
Configure whether to show the "Sign in with Shop" button for streamlined login experience.
This is a **template section** for the customer login page. Most login functionality is standard Shopify behavior. This section controls optional Shop Pay integration only.
## Getting Started
Customers reach login page by clicking "Account" or "Sign In" in header navigation, or visiting `yourstore.com/account/login`.
In Theme Customizer → Login template → Enable "Enable Sign in with Shop" checkbox to show Shop Pay login button.
Create test customer account (Admin → Customers → Add customer), then test login on storefront with email/password.
If enabled, customers with Shop Pay accounts can click "Sign in with Shop" button for faster login (redirects to Shop Pay authentication).
## Settings
**Type:** Checkbox\
**Default:** Disabled (unchecked)\
**Powered by:** Shop Pay (Shopify's accelerated checkout platform)
Controls whether "Sign in with Shop" button displays on login page.
### When Disabled (Default)
* Only standard email + password login form displays
* Customers must enter email and password manually
* Traditional login experience (works for all customers)
* No Shop Pay integration on login page
### When Enabled
* "Sign in with Shop" button appears above or below standard login form
* Customers with Shop Pay accounts can click button for one-tap login
* Redirects to Shop Pay authentication (biometric or code entry on mobile)
* After authentication, customer logged into your store automatically
* Standard email/password form still available for non-Shop Pay customers
### How "Sign in with Shop" Works
**For customers with Shop Pay:**
1. Customer clicks "Sign in with Shop" button
2. Redirected to Shop Pay (mobile app or web)
3. Authenticates with Shop Pay (Face ID, fingerprint, or one-time code)
4. Shop Pay confirms identity, returns customer to your store (logged in)
5. Faster than typing email + password
**For customers without Shop Pay:**
* Button still displays, but clicking prompts to set up Shop Pay or use standard login
* No disruption to traditional login flow (email/password form always available)
### Benefits of Enabling
**Faster login:**
* Shop Pay customers log in with one tap (biometric authentication)
* Reduces friction vs typing email + password (especially mobile)
* Improves conversion (customers more likely to log in if convenient)
**Mobile-optimized:**
* Biometric auth (Face ID, Touch ID, fingerprint) works seamlessly on mobile
* No typing on small keyboards
* Familiar experience (customers use Shop Pay across Shopify stores)
**Increased trust:**
* Shop Pay is Shopify-owned (customers trust Shopify brand)
* Secure authentication (no password storage on your site)
* Reduces password fatigue (customers don't need to remember your store's password)
**Checkout acceleration:**
* Customers logged in via Shop Pay have payment info saved
* Faster checkout after login (Shop Pay pre-fills payment/shipping)
### Drawbacks of Enabling
**Confusion for some customers:**
* Customers unfamiliar with Shop Pay may not understand button
* Two login options (Shop Pay + email/password) can confuse
* May need education ("Sign in with Shop is our fast login method")
**Requires Shop Pay account:**
* Only useful for customers who've used Shop Pay before (checked out via Shop Pay on any Shopify store)
* New customers won't have Shop Pay accounts (must use standard login)
**Additional button clutter:**
* Adds visual element to login page (more buttons = busier page)
* Some merchants prefer clean, minimal login (email/password only)
### Choosing Whether to Enable
**Enable when:**
* Mobile-heavy traffic (Shop Pay biometric auth perfect for mobile)
* Customers likely have Shop Pay (your store or other Shopify stores use Shop Pay checkout)
* Priority is conversion optimization (reduce login friction)
* Modern, tech-forward customer base (comfortable with one-tap login)
**Disable when:**
* Minimal, traditional login aesthetic preferred
* Customers unfamiliar with Shop Pay (B2B, older demographics, international customers where Shop Pay less common)
* Want simplest possible login (one form, one method)
* Testing shows Shop Pay button doesn't improve login rate
### Shop Pay Requirements
**For customers to use Shop Pay login:**
* Customer must have used Shop Pay checkout previously (on your store or any Shopify store)
* Shop Pay creates account first time customer uses Shop Pay at checkout
* Account linked to customer email + phone number
* Available in Shop Pay supported regions (primarily US, UK, Canada—check Shopify docs for current list)
### Testing Shop Pay Login
**Steps to test:**
1. Enable "Sign in with Shop" setting
2. Create test customer account (or use existing account)
3. Complete test purchase using Shop Pay checkout (to create Shop Pay account)
4. Log out of customer account
5. Go to `/account/login` page
6. Click "Sign in with Shop" button
7. Authenticate via Shop Pay (app or web)
8. Verify logged into customer account successfully
**If button doesn't appear:**
* Verify setting enabled in Theme Customizer
* Hard refresh browser (Cmd/Ctrl+Shift+R)
* Check Shop Pay available in your region
* Verify theme supports Shop Pay login (older themes may not)
### Shop Pay Login vs Shop Pay Checkout
**Shop Pay Checkout:**
* Accelerated checkout at payment step (saves payment/shipping info)
* Configured in Shopify Admin → Settings → Payments → Shop Pay
* Separate from login page feature
**Shop Pay Login:**
* Accelerated login to customer accounts (this setting)
* Uses Shop Pay authentication for fast sign-in
* Requires Shop Pay Checkout to be enabled (customers create Shop Pay account at checkout)
**Both work together:**
* Customer uses Shop Pay Checkout → Creates Shop Pay account
* Later, customer uses Shop Pay Login → Fast authentication
* After login, customer proceeds to Shop Pay Checkout → One-tap purchase
### Best Practices
**Enable for mobile-first stores:**
* Shop Pay biometric auth perfect for mobile (Face ID, fingerprint)
* Desktop customers can still use standard login
**Keep both options visible:**
* Don't hide email/password form if Shop Pay enabled
* Customers should always have fallback (if Shop Pay not working or unavailable)
**Educate customers:**
* Add help text near button ("Sign in with Shop for fast login")
* Link to Shopify's Shop Pay info page
* Consider tooltip or info icon explaining Shop Pay login
**Monitor usage:**
* Track login method usage (Shop Pay vs standard)
* If Shop Pay button unused, consider disabling (reduces clutter)
* If heavily used, keep enabled and promote
**Test in your region:**
* Shop Pay availability varies by country
* Test with customer in your primary market
* If Shop Pay unavailable in your region, disable setting
**Recommendation:** Enable if your store uses Shop Pay at checkout and has mobile-heavy traffic. Disable for minimal aesthetic or if customers unlikely to have Shop Pay accounts. Test to see if button improves login conversion.
## Best practices
Shop Pay login ideal for mobile-first stores. Biometric auth (Face ID, fingerprint) faster than typing password on small keyboard.
Always show email + password form even if Shop Pay enabled. Customers need fallback if Shop Pay unavailable or unfamiliar.
Create Shop Pay account (checkout with Shop Pay), then test "Sign in with Shop" button. Ensure authentication flow works smoothly.
Add help text or tooltip explaining Shop Pay login ("Fast, secure login with biometric authentication"). Reduces confusion.
Track login method usage (Shop Pay vs standard). If Shop Pay button unused, consider disabling to simplify page.
Shop Pay primarily available in US, UK, Canada. Check if available in your primary market before enabling.
If clean, simple login preferred, disable Shop Pay button. Standard email/password sufficient for most stores.
Shop Pay Login works best when Shop Pay Checkout enabled (customers create Shop Pay accounts during checkout).
## Login Page Structure
### Default Content
**Typical login page includes:**
* **Heading** - "Customer Login" or "Sign In"
* **Shop Pay button** (if enabled) - "Sign in with Shop" button
* **Login form** - Email input, Password input, "Sign In" submit button
* **"Forgot password?" link** - Links to password reset page
* **"Create account" link** - Links to registration page
* **Guest checkout option** (optional) - "Continue as guest" button (if theme supports)
### User Flow
**Standard login flow:**
1. Customer enters email + password
2. Clicks "Sign In" button
3. Redirected to account dashboard (`/account`)
**Shop Pay login flow:**
1. Customer clicks "Sign in with Shop" button
2. Redirected to Shop Pay authentication (app or web)
3. Authenticates with biometric or one-time code
4. Shop Pay verifies identity, returns to your store
5. Customer logged in, redirected to account dashboard
**Failed login:**
* Error message displays ("Incorrect email or password")
* Customer can retry or use "Forgot password?" link
## Common Use Cases
### Mobile-First Fashion Store
**Settings:** Enable "Sign in with Shop"
**Setup:** Mobile-heavy traffic, customers use Shop Pay at checkout frequently, Shop Pay login reduces mobile typing friction.
**Best for:** Fashion, apparel, beauty stores with mobile shoppers
### Traditional Login (Disable Shop Pay)
**Settings:** Disable "Sign in with Shop"
**Setup:** Minimal login page, standard email + password form only, clean aesthetic.
**Best for:** B2B stores, older demographics, regions where Shop Pay uncommon
### Conversion-Optimized Login
**Settings:** Enable "Sign in with Shop" + guest checkout button
**Setup:** Multiple login options (Shop Pay biometric, standard email/password, guest checkout). Maximize conversion by offering choice.
**Best for:** High-traffic stores prioritizing conversion optimization
### International Store (Shop Pay Unavailable)
**Settings:** Disable "Sign in with Shop"
**Setup:** Store primarily serves regions where Shop Pay unavailable (e.g., Asia, South America). Shop Pay button wouldn't function.
**Best for:** International stores outside Shop Pay supported regions
## Related Sections & Pages
* **[Account Dashboard](/themes/mojave/pages-templates/customers/account)** - Customer account page (after login)
* **[Registration Page](/themes/mojave/pages-templates/customers/register)** - Customer registration template
* **[Password Reset](/themes/mojave/pages-templates/customers/reset-password)** - Forgot password template
* **[Header](/themes/mojave/header/header)** - Navigation with "Account" link (triggers login)
## Technical Notes
### Shop Pay Integration
**API/Authentication:**
* Shop Pay login uses Shopify's authentication API
* Customer identity verified by Shop (Shopify's consumer app)
* OAuth-like flow: Your store → Shop Pay → Authentication → Return to store
* Secure (no passwords stored on your site)
**Customer Matching:**
* Shop Pay account linked to customer email + phone
* When logged in via Shop Pay, matches to customer account in your store by email
* If no matching customer account exists, creates new account (if customer registrations enabled)
### Cookie/Session Management
**Standard login:**
* Email/password form creates session cookie
* Cookie stored in browser, grants access to customer-specific pages
* Cookie expires on browser close or logout
**Shop Pay login:**
* Shop Pay authentication creates same session cookie
* Functionally identical to standard login (customer logged in, access granted)
* Cookie persists until logout or browser close
### Guest Checkout Consideration
**Some themes offer "Continue as guest":**
* Allows checkout without login/registration
* If theme supports, "Continue as guest" button may appear on login page
* Bypasses login requirement for one-time purchases
### Backwards Compatibility
**Older themes may not support Shop Pay login:**
* "Enable Sign in with Shop" setting may not exist
* Update theme to latest version for Shop Pay login support
* Or manually add Shop Pay login button (requires developer)
### Shop Pay Availability
**Supported regions (as of 2024):**
* United States
* Canada
* United Kingdom
* Expanding to more regions (check Shopify docs for current list)
**International stores:**
* If primary market outside supported regions, Shop Pay button won't function
* Disable setting (button displays but authentication fails)
## Troubleshooting
**"Sign in with Shop" button not displaying:**
* Verify "Enable Sign in with Shop" setting enabled in Theme Customizer → Login template
* Check theme supports Shop Pay login (older themes may not)
* Clear browser cache (Cmd/Ctrl+Shift+R), refresh page
* Verify Shop Pay available in your region
**Shop Pay authentication failing:**
* Check customer has Shop Pay account (used Shop Pay checkout previously)
* Verify customer's email matches email used for Shop Pay account
* Try standard login (email/password) as fallback
* Check Shopify status page for Shop Pay outages
**Customers confused by Shop Pay button:**
* Add help text or tooltip explaining Shop Pay ("Fast login with biometric authentication")
* Link to Shopify's Shop Pay info page
* Consider disabling if confusion outweighs benefit
**Shop Pay button showing but not working:**
* Shop Pay may be unavailable in customer's region
* Customer may not have Shop Pay account (must use Shop Pay checkout first to create)
* Try creating Shop Pay account (do test checkout with Shop Pay enabled), then test login
**Login page redirecting incorrectly:**
* Check customer account exists (Admin → Customers)
* Verify account not disabled (check customer status in Admin)
* Test with different customer account (may be account-specific issue)
**Standard login not working:**
* Verify email/password correct (case-sensitive)
* Check customer account active (not disabled in Admin)
* Try "Forgot password?" link to reset password
* Contact Shopify Support if persistent (may be account issue)
**Shop Pay button doesn't match theme styling:**
* Shop Pay button styled by Shopify (limited customization)
* Some CSS customization possible (requires developer)
* If styling critical, consider disabling Shop Pay button
**Mobile Shop Pay authentication not using biometric:**
* Customer may not have biometric auth enabled on device (Face ID, Touch ID, fingerprint)
* Shop Pay falls back to one-time code via SMS
* Ensure customer's phone number linked to Shop Pay account
## Key Takeaways
* **One setting only:** "Enable Sign in with Shop" checkbox (enabled = Shop Pay button displays)
* **Shop Pay login:** Fast authentication using biometric or one-time code (Shop Pay accounts)
* **Standard login always available:** Email + password form displays regardless of Shop Pay setting
* **Mobile-optimized:** Shop Pay biometric auth perfect for mobile shoppers (Face ID, Touch ID, fingerprint)
* **Requires Shop Pay account:** Customers must have used Shop Pay checkout previously (on your or any Shopify store)
* **Regional availability:** Shop Pay primarily US, UK, Canada (check Shopify docs for current regions)
* **Enable for mobile stores:** If mobile-heavy traffic and customers use Shop Pay at checkout
* **Disable for simplicity:** If minimal login preferred or customers unlikely to have Shop Pay accounts
* **Test authentication:** Create Shop Pay account, test "Sign in with Shop" button flow
* **Works with Shop Pay Checkout:** Shop Pay Login and Shop Pay Checkout complementary features
For more about Shop Pay, see [Shopify's Shop Pay documentation](https://help.shopify.com/en/manual/checkout-settings/shop-pay).
# Order Details
Source: https://docs.digifist.com/themes/mojave/pages-templates/customers/order
Customer order history and details page
## What It Does
The **Order Page** template displays when logged-in customers view their order history at `/account` under "Orders" section, or when viewing specific order details at `/account/orders/[order-id]`. This page shows all past orders with details (order number, date, status, items, totals) and allows customers to track shipments and reorder products.
This is a **static template section** with no customizable settings. Order display functionality is standard Shopify behavior. Customization requires code editing.
## Template Content
### Order History View
**Typical orders list includes:**
* **Heading** - "Order History" or "My Orders"
* **Order cards/rows** - Each past order displayed as card or table row
* **Order number** - Unique order ID (e.g., #1001, #1002)
* **Order date** - When order placed
* **Order status** - Fulfilled, Unfulfilled, Partially Fulfilled, Cancelled, Refunded
* **Order total** - Final amount paid
* **View order button** - Links to detailed order page
### Order Details View
**Individual order page (`/account/orders/[order-id]`) includes:**
* **Order number & date**
* **Order status** - Fulfillment and payment status
* **Items ordered** - Product names, variants, quantities, prices
* **Subtotal, shipping, tax, discounts, total**
* **Shipping address**
* **Billing address**
* **Payment method** (last 4 digits of card, or payment type)
* **Tracking information** (if available) - Tracking number, carrier link
* **Reorder button** (optional) - Add all items to cart for easy reordering
## User Experience
**Viewing orders flow:**
1. Customer logs in, navigates to account dashboard
2. Clicks "Orders" in account navigation
3. Sees list of all past orders (order history)
4. Clicks "View order" on specific order
5. Lands on detailed order page
6. Views items, total, shipping address, tracking info
7. Optionally clicks tracking link to check shipment status
8. Optionally clicks "Reorder" to add items to cart
## Best practices
Display order status prominently (Fulfilled, Shipped, Delivered, Cancelled). Customers need immediate status visibility.
If tracking available, make tracking number/link prominent. Customers frequently check order pages for tracking.
Include "Reorder" button on order details (adds all items to cart). Convenient for repeat purchases.
Display order date in readable format ("January 15, 2024" not "2024-01-15"). Improves scannability.
Optionally include "Download Invoice" link (PDF invoice). Useful for business customers, expense tracking.
Include "Contact us about this order" link. Makes it easy for customers to reach support regarding specific order.
Order page sees heavy mobile traffic (customers checking orders on-the-go). Ensure all details readable, buttons tappable.
If customer has 20+ orders, paginate order history (10-20 per page). Improves page load and usability.
## Order Status Types
### Fulfillment Status
**Unfulfilled:**
* Order placed but not shipped yet
* Items being prepared/packed
* Typical for new orders (first 1-2 days)
**Partially Fulfilled:**
* Some items shipped, others pending
* Multiple shipments (backorder situations)
* Tracking available for fulfilled items
**Fulfilled:**
* All items shipped
* Tracking information available
* Final fulfillment status (delivered afterwards tracked by carrier)
**Cancelled:**
* Order cancelled (by customer or merchant)
* Payment refunded (if already charged)
* Items not shipped
**Refunded:**
* Order refunded after fulfillment
* Items may have been returned
* Payment returned to customer
### Payment Status
**Pending:**
* Payment authorization pending
* Manual payment capture required (merchant must capture)
**Paid:**
* Payment captured
* Standard status for most orders
**Refunded:**
* Full or partial refund issued
* Money returned to customer
**Voided:**
* Payment authorization voided (before capture)
* Funds never captured from customer
## Related Pages
* **[Account Dashboard](/themes/mojave/pages-templates/customers/account)** - Account hub (links to Orders page, shows recent orders)
* **[Login Page](/themes/mojave/pages-templates/customers/login)** - Must be logged in to view orders
* **[Addresses](/themes/mojave/pages-templates/customers/addresses)** - Addresses used for shipping (displayed on order page)
## Technical Notes
### Order Object
**Liquid access:**
```liquid theme={null}
{{ customer.orders }} - All customer's orders
{{ order.name }} - Order number (e.g., #1001)
{{ order.created_at }} - Order date
{{ order.fulfillment_status }} - Status
{{ order.line_items }} - Items in order
```
**Order properties available:**
* Order number, date, status
* Line items (products, variants, quantities, prices)
* Totals (subtotal, shipping, tax, discounts, total)
* Addresses (shipping, billing)
* Tracking info (if fulfilled)
### Tracking Integration
**Tracking numbers:**
* Added in Shopify Admin when order fulfilled
* Admin → Orders → \[Order] → Fulfill items → Enter tracking number + carrier
* Automatically appears on customer's order page
* Link generated to carrier's tracking page (USPS, UPS, FedEx, etc.)
**Tracking email:**
* Shopify automatically emails customers when tracking added
* Email includes tracking link
* Customer can also check tracking on order page
### Reorder Functionality
**How reorder works:**
1. Customer clicks "Reorder" button on order details page
2. All items from that order added to cart
3. Quantities match original order
4. Customer redirected to cart page
5. Can adjust quantities or proceed to checkout
**Implementation:**
* Requires custom code or theme support
* Not all themes include reorder button out-of-box
* Can be added via apps or custom development
### Order History Limits
**No hard limit:**
* All customer orders display in order history
* Can view orders from years ago (as long as customer account exists)
* Shopify retains order data indefinitely
**Pagination:**
* Themes may paginate for many orders (10-20 per page)
* Improves page load for customers with 50+ orders
### Guest Orders
**Guest checkout orders:**
* Not linked to customer account (no account at time of purchase)
* Don't appear in customer's order history (if they create account later)
* Accessible only via order status page (emailed after purchase)
**Linking guest orders:**
* If customer creates account with same email as guest order, Shopify may auto-link
* Or customer can contact support to link guest orders to account
## Troubleshooting
**Orders not showing:**
* Verify logged in to correct account (email used at time of purchase)
* Check orders placed with same email (guest orders may not show—see above)
* Verify orders actually placed (check order confirmation email)
* Contact store support if orders missing (may need manual linking)
**Can't view order details:**
* Check logged in (session may have expired)
* Try hard refresh (Cmd/Ctrl+Shift+R)
* Check order ID correct in URL (ensure viewing own order, not someone else's)
* Theme bug possible (contact theme support)
**Tracking link not working:**
* Verify tracking number entered correctly in Admin
* Check carrier link (sometimes carrier websites down)
* Try copying tracking number, paste in carrier website directly
* Allow 24 hours after fulfillment (tracking may not be active immediately)
**Order status not updating:**
* Status synced from Admin (may take a few minutes to update)
* Hard refresh browser (Cmd/Ctrl+Shift+R)
* Check Admin status (if Admin shows updated, refresh customer page)
* Allow 1-2 hours for third-party fulfillment updates
**Reorder button not working:**
* Check all products still available (out-of-stock items may prevent reorder)
* Product may have been deleted (can't reorder discontinued items)
* JavaScript error possible (check browser console)
* Try adding items manually if reorder fails
**Order page showing wrong orders:**
* Verify logged in to correct account (not shared device with someone else's session)
* Check email associated with account (Admin → Customers → \[Customer])
* May be seeing another customer's orders (security issue—report immediately)
**Mobile order page not loading:**
* Check internet connection (require online to load order data)
* Try desktop browser (test if mobile-specific issue)
* Clear mobile browser cache
* Verify logged in on mobile
## Key Takeaways
* **No template settings** - Order page is static, no Theme Customizer customization
* **View all past orders** - Order history lists all customer orders (no time limit)
* **Order details page** - Click order to view detailed breakdown (items, totals, addresses, tracking)
* **Order status displayed** - Fulfillment status (Unfulfilled/Fulfilled) and payment status (Paid/Refunded)
* **Tracking information** - Tracking numbers and carrier links appear when order fulfilled
* **Reorder functionality** - Optionally add "Reorder" button (requires theme support or custom code)
* **Guest orders separate** - Guest checkout orders don't appear in account (unless manually linked)
* **Mobile usage high** - Customers frequently check orders on mobile (ensure mobile-optimized)
* **Customization via code** - Add features (invoices, reorder, custom layouts) via theme editing or apps
For custom order page features (invoices, advanced filtering, custom order fields), explore Shopify apps or hire a developer.
# Register
Source: https://docs.digifist.com/themes/mojave/pages-templates/customers/register
Customer account registration page for creating new accounts
## What It Does
The **Registration Page** template displays when visitors navigate to `/account/register` to create a new customer account. This page shows a registration form collecting email, password, and optional additional details (name, phone) to create customer login credentials.
This is a **static template section** with no customizable settings. Form fields and layout are standard Shopify behavior. Customization requires code editing.
## Template Content
### Default Registration Form
**Typical registration page includes:**
* **Heading** - "Create Account" or "Register"
* **First name** input (optional or required based on Shopify settings)
* **Last name** input (optional or required)
* **Email** input (required - becomes login username)
* **Password** input (required - minimum 5 characters)
* **"Create account" button**
* **"Already have an account? Sign in" link** - Links to login page
### User Experience
**Customer registration flow:**
1. Customer clicks "Create Account" link (header nav or login page)
2. Lands on `/account/register` page
3. Fills out registration form (email, password, name)
4. Clicks "Create account" button
5. Account created, customer logged in automatically
6. Redirected to account dashboard (`/account`)
## Best practices
Keep required fields minimal (email + password only). Optional fields reduce friction, increase registrations.
Display password requirements clearly (e.g., "Minimum 5 characters"). Reduces form errors.
Prominent "Already have an account? Sign in" link. Prevents duplicate account attempts.
Registration often happens on mobile. Ensure form inputs large, easy to type on small keyboards.
Consider allowing guest checkout (no registration required). Many customers prefer one-time purchase without account.
Link to privacy policy near registration form. Builds trust, legal compliance.
Optionally enable email verification in Shopify settings (Admin → Settings → Customer accounts → Accounts are required).
Consider adding social login buttons (Google, Facebook) via apps. Reduces registration friction.
## Registration Settings (Shopify Admin)
### Configure in Admin
**Shopify Admin → Settings → Checkout → Customer accounts:**
**Options:**
* **Accounts are disabled** - No customer accounts (guest checkout only)
* **Accounts are optional** - Customers can checkout as guest or create account
* **Accounts are required** - Customers must create account to checkout
**Recommendation:** "Accounts are optional" (best for conversion—allows guest checkout, offers account creation)
### Form Field Requirements
**Required fields:**
* Email (always required)
* Password (always required, minimum 5 characters)
**Optional fields (configurable in theme code):**
* First name
* Last name
* Phone number
* Custom fields (requires code customization)
## Related Pages
* **[Login Page](/themes/mojave/pages-templates/customers/login)** - Customer login (for existing accounts)
* **[Account Dashboard](/themes/mojave/pages-templates/customers/account)** - Redirected here after registration
* **[Activate Account](/themes/mojave/pages-templates/customers/activate-account)** - Email verification page (if enabled)
* **[Password Reset](/themes/mojave/pages-templates/customers/reset-password)** - Forgot password page
## Key Takeaways
* **No template settings** - Registration form is standard Shopify, no Theme Customizer customization
* **Email + password required** - Minimum fields for account creation
* **Auto-login after registration** - Customer logged in automatically upon successful registration
* **Configure account requirement** - Admin → Settings → Checkout → Customer accounts (optional vs required)
* **Guest checkout recommended** - "Accounts optional" setting balances conversion vs customer data
* **Email verification optional** - Enable in Admin settings (customers verify email before login)
* **Customization via code** - Add custom fields, social login, or styling via theme code or apps
For custom registration forms with additional fields or social login, explore Shopify App Store or hire a developer.
# Reset Password
Source: https://docs.digifist.com/themes/mojave/pages-templates/customers/reset-password
Customer password reset page for recovering forgotten passwords
## What It Does
The **Password Reset** template displays when customers click "Forgot password?" link on login page and enter their email. This page allows customers to set a new password using a secure reset link emailed to them.
This is a **static template section** with no customizable settings. Password reset functionality is standard Shopify behavior. Customization requires code editing.
## Template Content
### Default Password Reset Form
**Typical password reset page includes:**
* **Heading** - "Reset Password" or "Create New Password"
* **New password** input (enter new password)
* **Confirm password** input (re-enter new password for verification)
* **"Reset password" button**
* **Success/error messages** - Confirmation or validation errors
### User Experience
**Password reset flow:**
1. Customer clicks "Forgot password?" on login page
2. Enters email, clicks "Submit"
3. Receives password reset email (contains secure reset link)
4. Clicks reset link in email
5. Lands on password reset page (`/account/reset/[token]`)
6. Enters new password (twice for confirmation)
7. Clicks "Reset password" button
8. Password updated, customer logged in automatically
9. Redirected to account dashboard
## Best practices
Password reset emails sometimes land in spam. Instruct customers to check spam/junk folders if email doesn't arrive.
Display password requirements (minimum 5 characters). Helps customers create valid passwords on first try.
Require password entry twice (confirmation field). Reduces typo errors when setting new password.
Reset links expire after 24 hours (Shopify default). Customers must request new link if expired.
Provide instructions on password reset page ("Enter new password below"). Reduces customer confusion.
After successful reset, automatically log customer in. Eliminates extra login step.
Include contact support link if customer can't receive reset email. Provide alternative recovery method.
Don't allow overly simple passwords ("12345"). Educate customers on strong passwords (mix letters/numbers/symbols).
## Password Reset Process (Full Flow)
### Step 1: Request Reset
**Customer on login page:**
1. Clicks "Forgot password?" link
2. Enters email address
3. Clicks "Submit"
4. Sees confirmation "Reset email sent"
### Step 2: Email Sent
**Shopify sends automated email:**
* Subject: "\[Store Name] - Reset your password"
* Contains secure reset link (unique token in URL)
* Link expires in 24 hours
* Sent from `noreply@shopify.com` (or custom email if configured)
### Step 3: Reset Password
**Customer clicks email link:**
1. Lands on password reset page (this template)
2. Enters new password
3. Re-enters password (confirmation)
4. Clicks "Reset password"
5. Password updated in database
6. Customer logged in automatically
7. Redirected to account dashboard
### Step 4: Login with New Password
**Future logins:**
* Customer uses email + new password
* Old password no longer valid
## Related Pages
* **[Login Page](/themes/mojave/pages-templates/customers/login)** - Customer login (has "Forgot password?" link)
* **[Account Dashboard](/themes/mojave/pages-templates/customers/account)** - Redirected here after password reset
* **[Registration](/themes/mojave/pages-templates/customers/register)** - Create new account (if customer doesn't have one)
## Technical Notes
### Reset Link Token
**Security:**
* Reset link contains unique, cryptographically secure token
* Token tied to specific customer account + email
* Expires after 24 hours (can't be reused after expiration)
* One-time use (token invalidated after successful password reset)
**URL structure:**
```
yourstore.com/account/reset/[unique-token]
```
### Email Delivery
**Reset email sent via:**
* Shopify's transactional email system
* Sent automatically upon reset request
* From address: `noreply@shopify.com` (or custom sender if configured in Admin)
* Can be customized: Admin → Settings → Notifications → Customer account password reset
**If email not received:**
* Check spam/junk folder
* Verify email address correct (typo in email entry)
* Request new reset link (old link may have expired)
* Check email provider not blocking Shopify emails
### Password Requirements
**Shopify minimum:**
* 5 characters minimum length
* No complexity requirements (letters/numbers/symbols optional)
**Recommendation:**
* Encourage 8+ characters
* Mix uppercase, lowercase, numbers, symbols
* Avoid common passwords ("password", "12345", etc.)
### Auto-Login After Reset
**After successful password reset:**
* Customer automatically logged in (session cookie created)
* No need to manually log in with new password
* Redirected to account dashboard
* Password reset email link invalidated (can't be reused)
## Troubleshooting
**Reset email not received:**
* Check spam/junk folder (most common issue)
* Verify email address entered correctly (no typos)
* Check email provider settings (some block automated emails)
* Wait 5-10 minutes (email delivery can be delayed)
* Request new reset link (via login page "Forgot password?" again)
**Reset link expired:**
* Links expire after 24 hours (security measure)
* Request new reset link from login page
* Use new link within 24 hours
**"Invalid token" error:**
* Reset link already used (one-time use only)
* Link expired (24 hour limit)
* Link malformed (email client may have broken URL)
* Request new reset link
**Password doesn't meet requirements:**
* Ensure password at least 5 characters
* Check no leading/trailing spaces
* Try simple password first (e.g., "password123"), then update to stronger later
**New password not working:**
* Hard refresh login page (Cmd/Ctrl+Shift+R)
* Clear browser cookies, try again
* Ensure using correct email (tied to reset link)
* Request new password reset (may have been system error)
**Customer can't receive any emails from store:**
* Check customer's email provider (Gmail, Outlook, etc.) settings
* Verify email not in blocked senders list
* Try alternative email address
* Contact customer via phone/support (manual account recovery)
## Key Takeaways
* **No template settings** - Password reset page is standard Shopify, no customization options
* **Secure reset link** - Emailed to customer, expires in 24 hours, one-time use
* **Minimum 5 characters** - Shopify password requirement (encourage stronger)
* **Auto-login after reset** - Customer logged in automatically upon successful password change
* **Check spam folder** - Most common issue is reset email in spam/junk
* **Request new link if expired** - Links expire after 24 hours (security)
* **One-time use** - Reset link can't be reused after successful password change
* **Customization via email templates** - Customize reset email content in Admin → Notifications
For custom password reset email design or functionality, edit email templates in Shopify Admin → Settings → Notifications → Customer account password reset.
# Page Template (main-page)
Source: https://docs.digifist.com/themes/mojave/pages-templates/page
Configure your basic page template with simple title display control
The Page template (main-page) is the simplest template, controlling how standard pages display. It provides minimal customization - primarily controlling page title visibility.
## What this section controls
* Page title visibility
* Page content display (automatic)
## Getting started
In your Shopify admin, go to **Online Store > Themes** and click **Customize** on your active theme.
Use the page selector dropdown to select **Pages** and choose any page to preview.
The "Page" section controls the main page template.
## Template settings
Controls whether the page title displays at the top of the page content. Disabled by default.
**When to enable**:
* Standard informational pages (About, FAQ, Policies)
* You want clear page identification
* Page doesn't have custom sections with title
**When to disable** (default):
* Custom landing pages where title would be redundant
* You're using page banner or other sections with custom titles
* Minimalist design where title isn't needed
**Note**: Page content always displays regardless of title setting.
## Best practices
main-page is ideal for basic content pages. For more complex layouts, add sections above/below or use page-banner section.
Keep title disabled (default) when using page-banner or other title-bearing sections to avoid duplication.
Enable title for standard pages (About, Contact, Policies) where clear identification helps users orient themselves.
Enhance pages by adding sections above/below main-page section in template editor for richer layouts.
# Password page
Source: https://docs.digifist.com/themes/mojave/pages-templates/password
Password protection page template for pre-launch and private storefronts
## What It Does
The **Password Page** template displays when your store is password-protected (pre-launch, maintenance mode, or private/exclusive access). This template shows a password entry form, optional message, and branding to visitors before they can access your store.
This is a **static template section** with no customizable settings in the section itself. To enable password protection and configure messaging, go to Shopify Admin → Online Store → Preferences → Password protection.
## When Password Page Displays
### Password Protection Enabled
**Activate in Shopify Admin:**
1. Online Store → Preferences
2. Enable "Password protection" checkbox
3. Enter password (share with authorized visitors)
4. Add message (optional - appears on password page)
5. Save
**Result:** All visitors see password page until correct password entered
### Common Use Cases
**Pre-launch (Coming Soon):**
* Store under construction, not ready for public
* Collect emails, build anticipation
* Share password with internal team for testing
**Maintenance Mode:**
* Site updates in progress
* Temporary closure (inventory, system changes)
* Prevent orders during downtime
**Private/Exclusive Access:**
* Wholesale store (password for approved buyers only)
* Members-only boutique
* Exclusive product drops (password shared with VIPs)
**Seasonal Closure:**
* Business closed during off-season
* Vacation mode for small businesses
* Password page informs customers of return date
## Template Structure
### Default Content
**Typical password page includes:**
* **Logo** - Store logo (configured in Header Password section)
* **Heading** - Store name or custom title
* **Message** - Custom text from Admin (e.g., "We're launching soon! Enter password to preview.")
* **Password form** - Input field and submit button
* **Footer** - Optional footer links, social media, copyright
### Customizing Message
**In Shopify Admin → Online Store → Preferences:**
* **Password:** The password visitors must enter
* **Message to your visitors:** Text appearing above password form
* Supports plain text (no HTML/formatting)
* Typical length: 1-3 sentences
**Example messages:**
* "Our store is launching soon. Stay tuned!"
* "Site under maintenance. We'll be back shortly."
* "This is a private store. Contact us for access."
* "Invite-only access. Enter password to shop."
## Password Page vs Main Store
### What Visitors See
**Before password entry (Password page):**
* Simplified header (logo only, from Header Password section)
* Password form
* Custom message
* Basic footer
* **No access to:** Products, collections, cart, checkout
**After correct password (Main store):**
* Full site access (products, collections, cart, checkout)
* Standard header with navigation
* All store functionality enabled
* Password saved in browser cookie (don't need to re-enter during session)
### Session Handling
**Cookie saves password:**
* Entering correct password sets browser cookie
* Cookie expires when browser closed or session ends
* Visitors must re-enter password on next visit (unless cookie persists)
**Logging out:**
* Clear browser cookies to force password page to reappear
* Or use private/incognito browsing to test password page
## Best practices
Use password page message to build excitement (pre-launch) or inform (maintenance). Include return date if applicable.
For pre-launch: Share with team, beta testers, friends/family. For private stores: Only approved customers.
Add email signup form to password page (requires app or code). Build launch list during pre-launch.
Use secure password (not "password123"). Prevents random access. Change periodically for private stores.
Visit store in incognito mode to see public password page. Ensure message, branding, password form work.
Remove password protection when ready to launch: Admin → Preferences → Uncheck "Password protection" → Save.
Add social links to password page footer. Let pre-launch visitors follow on Instagram, Twitter, etc.
Customize Header Password section (logo, positioning, transparency). Match password page to brand aesthetic.
## Customization Options
### Via Shopify Admin
**Limited customization available:**
* **Password:** Admin → Preferences → Password protection → Password field
* **Message:** Admin → Preferences → Password protection → Message to your visitors
* **Logo/Header:** Theme Customizer → Header (Password) section → Upload logo, configure styling
### Via Theme Customizer
**Header Password section:**
* Upload logo (appears on password page)
* Set logo width, position (left/center)
* Enable transparent header background
* Show/hide separator line
**Footer section:**
* Standard footer appears on password page (configure as normal)
* Add social media links, copyright text
### Via Code Editing
**For developers:**
* Edit `templates/password.json` (JSON template) or `templates/password.liquid` (Liquid template)
* Modify section `/sections/section-password.liquid`
* Customize background image, colors, typography
* Add email signup form, countdown timer, video background
* Integrate with Mailchimp/Klaviyo for launch list
### Via Apps
**3rd-party apps:**
* "Coming Soon" apps for advanced password pages (email collection, timers, animations)
* Check Shopify App Store for "password page customization" apps
## Technical Notes
### Password Storage
**How it works:**
* Password entered → Checked against password in Admin settings
* If correct → Browser cookie set with session token
* Cookie allows access to full store (bypasses password page)
* Cookie expires on browser close (or configurable duration)
**Security:**
* Password NOT stored in customer account system
* Separate from customer login passwords
* Single password for all visitors (not individual accounts)
### SEO Implications
**Password-protected stores not indexed:**
* Search engines can't access password-protected content
* No SEO value while password enabled
* Remove password protection to allow search engine crawling
**Pre-launch SEO prep:**
* While password-protected, configure SEO settings (page titles, meta descriptions)
* Add products, collections, content (ready to be indexed when password removed)
* When password disabled, search engines can immediately crawl full site
### Shopify Staff Bypass
**Staff logged in to Shopify Admin:**
* Automatically bypass password page
* Can preview store without entering password
* To see password page (testing): Log out of Shopify Admin or use incognito browsing
### Email Signup (Advanced)
**Adding email collection:**
* Requires custom code or app
* Capture emails during pre-launch
* Popular tools: Mailchimp embeds, Klaviyo forms, custom Liquid code
* Developers: Add form to `section-password.liquid` template section
## Troubleshooting
**Can't find password page settings:**
* Shopify Admin → Online Store → Preferences → Scroll to "Password protection" section
* Must enable "Restrict access with password" checkbox first
**Password page not showing:**
* Verify password protection enabled in Admin → Preferences
* Check you're logged out of Shopify Admin (staff bypass password page when logged in)
* Test in private/incognito browser window
**Password not working:**
* Check password entered correctly (case-sensitive)
* Verify password set correctly in Admin → Preferences
* Try clearing browser cookies, re-enter password
**Logo/branding not showing:**
* Upload logo in Theme Customizer → Header (Password) section
* Check Header Password section settings (logo width, position)
* Refresh browser after making changes
**Custom message not displaying:**
* Enter message in Shopify Admin → Preferences → Password protection → "Message to your visitors"
* Message supports plain text only (no HTML)
* Save changes, refresh password page
**Password page shows after disabling:**
* Ensure "Password protection" checkbox unchecked in Admin → Preferences
* Clear browser cache (Cmd/Ctrl+Shift+R)
* May take a few minutes to propagate (Shopify cache)
**Email signup form not working:**
* Verify form code added correctly (if custom)
* Check app configuration (if using app)
* Test form submission (receive test email)
**Footer links missing:**
* Configure footer in Theme Customizer → Footer section
* Footer appears on both password page and main store
* Add links, social media icons as normal
## Common Scenarios
### Pre-Launch Store
**Setup:** Enable password protection, message "Launching Spring 2024! Enter password for preview.", share password with team/testers\
**Purpose:** Build store privately, test before public launch
### Maintenance Mode
**Setup:** Enable password protection, message "We're updating our store. Back in 24 hours!", share password with staff only\
**Purpose:** Prevent customer orders during maintenance
### VIP/Exclusive Access
**Setup:** Enable password protection, message "Exclusive access for VIP members. Contact us for password.", share password with approved customers\
**Purpose:** Private store for wholesale, members-only boutique
### Seasonal Closure
**Setup:** Enable password protection, message "We're closed for the season. Reopening October 1st. Follow us on Instagram for updates."\
**Purpose:** Inform customers of closure, maintain brand presence
### Product Drop Hype
**Setup:** Enable password protection week before drop, message "New collection drops Friday! Password will be emailed to subscribers."\
**Purpose:** Build anticipation, reward subscribers with early access
## Related Documentation
* **[Header (Password)](/themes/mojave/header-password)** - Password page header section (logo, styling)
* **[Footer](/themes/mojave/footer/footer)** - Footer section (appears on password page)
* **[404 Page](/themes/mojave/pages-templates/404)** - Error page template
* **Shopify Admin** - [Password protection settings](https://help.shopify.com/en/manual/online-store/themes/password-page)
## Key Takeaways
* **No section settings** - Password page section itself has no customizable settings
* **Enable in Admin** - Shopify Admin → Preferences → Password protection
* **Custom message** - Add 1-3 sentence message in Admin (appears on password page)
* **Header customization** - Use Header (Password) section for logo, styling
* **Pre-launch use** - Perfect for building store before public launch
* **Private store use** - Restrict access to approved customers only
* **SEO blocked** - Password-protected content not indexed by search engines
* **Cookie-based access** - Correct password sets cookie, bypasses password page during session
* **Code customization** - Advanced features (email signup, timers) require code editing or apps
For custom password page designs with email collection, countdown timers, or advanced features, explore Shopify App Store "Coming Soon" apps or hire a developer.
# Gift Card
Source: https://docs.digifist.com/themes/mojave/products/gift-card
Gift card template section for customizing gift card page branding with logo images or SVG code
## What It Does
The **Gift Card** section controls the branding and visual appearance of Shopify gift card pages. Customize the logo displayed at the top of gift card pages and on the printable gift card itself, using either uploaded images or SVG code for sharp, scalable graphics.
## Getting Started
Navigate to **Online Store > Themes > Customize > Gift Cards** template (automatic template for gift card purchases)
Add your store logo using the Logo Image picker, or use SVG Code for vector graphics
Add a separate logo for the gift card graphic itself, or leave empty to use main logo
Test by creating a test gift card product and purchasing it to see the full gift card experience
## Settings
**Type:** Image picker\
**Default:** Empty
Your store logo displayed at the **top of the gift card page** (the page customers see when they receive/redeem a gift card).
### What This Logo Controls
This logo appears on the **gift card landing page**:
* Top of page (header area)
* Visible when customer clicks gift card link in email
* Shown when customer views gift card to check balance
* Brand identifier for gift card redemption experience
**Does NOT appear:**
* On the gift card graphic itself (use Logo Card Image for that)
* In email notifications (controlled by email settings)
* On printed receipts
### Image Specifications
**Recommended dimensions:**
* **Width:** 200-400px (optimal)
* **Height:** 60-120px (optimal)
* **Aspect ratio:** Horizontal logos work best (landscape orientation)
* **File format:** PNG with transparent background (recommended) or JPG
* **File size:** Under 100KB (page header images should load quickly)
### Image Guidelines
**Best practices:**
* Use your standard store logo (maintains brand consistency)
* Transparent background PNG for professional appearance
* High resolution for retina displays (2x actual display size)
* Horizontal orientation (vertical logos may appear too large)
* Simple, recognizable logo (avoids complexity at small sizes)
**Avoid:**
* Extremely small images (will appear blurry when scaled up)
* Very tall logos (can dominate header, push content down)
* Complex logos with fine details (may not be legible at header size)
* Text-heavy logos (hard to read at smaller sizes)
**Type:** Textarea\
**Default:** Empty\
**Info:** "Overwrites logo image"
Paste SVG (Scalable Vector Graphics) code for your logo instead of using an uploaded image. Provides perfectly sharp logos at any size and typically loads faster than image files.
### SVG vs Image
**Why use SVG instead of image?**
* **Perfect scaling:** Looks crisp at any resolution (retina, 4K, print)
* **Smaller file size:** Typically 20-80% smaller than equivalent PNG/JPG
* **Faster loading:** Inline SVG requires no HTTP request
* **Color flexibility:** Can be dynamically styled with CSS
* **Print quality:** Perfect for any DPI
**When to use Image instead:**
* Logo has photographic elements or gradients
* Logo uses special fonts not web-safe
* You don't have SVG version of logo
* Logo is complex with many paths (very large SVG code)
### How to Get SVG Code
**Method 1: Export from design software**
1. Open logo in Adobe Illustrator, Figma, or Sketch
2. Export as SVG (optimize for web if option available)
3. Open exported .svg file in text editor
4. Copy all code (starts with ``)
5. Paste into this field
**Method 2: Convert image to SVG**
1. Use online converter (e.g., vectormagic.com, autotracer.com)
2. Upload your logo image
3. Download SVG file
4. Open in text editor and copy code
**Note:** Traced SVGs from complex images may have large code (10,000+ characters). Hand-crafted SVGs from design software are usually cleaner.
### SVG Code Example
```svg theme={null}
```
### Important: Overwrites Logo Image
When SVG code is present, it **completely replaces** the Logo Image:
* Logo Image setting is ignored
* SVG code takes priority
* To revert to image, clear SVG code field entirely
**Best practice:** Use either Logo Image OR Logo SVG Code, not both. Choose based on logo type and quality requirements.
### SVG Code Tips
**Do:**
* Use `viewBox` attribute for responsive scaling
* Set reasonable `width` and `height` attributes
* Optimize SVG code (remove unnecessary attributes, comments)
* Test SVG displays correctly after pasting
**Don't:**
* Include external stylesheet references (may not load)
* Use JavaScript in SVG (security risk, won't execute)
* Paste very complex SVGs (5000+ lines of code—use image instead)
* Forget closing `` tag (will break rendering)
### Validating SVG Code
Before pasting:
1. Open SVG code in browser to verify it displays correctly
2. Check code starts with ``
3. Confirm no external dependencies (fonts, images, stylesheets)
4. Test on different screen sizes (SVG should scale properly)
**Type:** Image picker\
**Default:** Empty\
**Info:** "Defaults to logo image"
Logo displayed **on the gift card graphic itself**—the visual card representation customers see and can print. If empty, uses the main Logo Image.
### What This Logo Controls
This logo appears on the **gift card graphic**:
* Visual gift card design (the "card" customers see)
* Printable gift card version
* Email attachments (if theme includes card preview)
* Balance-check view
**Separate from:**
* Page header logo (controlled by Logo Image)
* Email logo (controlled by email settings in Shopify Admin)
### When to Use Separate Card Logo
**Use separate Logo Card Image when:**
**Different branding for gift cards:**
* Page header: Standard color logo
* Gift card: White/inverted logo (for dark card background)
**Size optimization:**
* Page header: Wide horizontal logo
* Gift card: Square or vertical logo (fits card dimensions better)
**Seasonal variations:**
* Page header: Year-round logo
* Gift card: Holiday-themed logo for gift-giving season
**Print considerations:**
* Page header: Standard screen logo
* Gift card: High-contrast logo optimized for printing
**Leave empty (use default) when:**
* Same logo works for both page and card
* Logo is already versatile (works on any background)
* Simpler management (one logo to maintain)
* Brand consistency is priority
### Card Logo Image Specifications
Gift cards have constrained space, so logo sizing differs from page header:
**Recommended dimensions:**
* **Width:** 200-300px (smaller than page header logo)
* **Height:** 80-150px (or proportional to width)
* **Aspect ratio:** Square or near-square works best on card
* **File format:** PNG with transparent background (essential)
* **File size:** Under 100KB
**Key difference from page logo:**
* **Smaller overall size** (card has limited space)
* **Transparent background required** (card has its own background)
* **High contrast** (needs to show clearly on card background)
### Background Considerations
Gift card templates use **background images or colors**. Your card logo must work with:
* Dark backgrounds (use light/white logo)
* Light backgrounds (use dark logo)
* Patterned backgrounds (use solid logo with contrast)
**Tip:** Check your theme's gift card background design, then choose logo color/style that provides sufficient contrast.
**Type:** Textarea\
**Default:** Empty\
**Info:** "Overwrites logo card image and defaults to logo SVG code"
SVG code for the gift card graphic logo. Provides the same benefits as Logo SVG Code but specifically for the card design.
### Fallback Hierarchy
This setting has a **multi-level fallback**:
1. **If Logo Card SVG Code is present:** Uses this SVG (highest priority)
2. **Else if Logo SVG Code is present:** Uses main Logo SVG Code
3. **Else if Logo Card Image is present:** Uses Logo Card Image
4. **Else:** Uses main Logo Image
**In simple terms:**
* Card SVG > Main SVG > Card Image > Main Image
This allows flexible logo management:
* Set all four: Maximum customization (separate vector graphics for page and card)
* Set only main logo (image or SVG): Same logo everywhere (simplest)
* Set main logo + card logo: Different styles for page vs card
* Mix and match as needed
### When to Use Separate Card SVG
**Use separate Logo Card SVG Code when:**
**Color variations:**
```svg theme={null}
```
**Size/detail variations:**
* Page header: Detailed logo with tagline
* Gift card: Simplified logo icon only (fits card space)
**Print optimization:**
* Card SVG: Simplified paths for clean printing
* Page SVG: More complex with gradients (screen-only effects)
**Leave empty (use fallback) when:**
* Main Logo SVG works for both page and card
* Simplicity is priority (fewer settings to manage)
* Logo is monochrome and versatile
### SVG Code Requirements for Cards
Same technical requirements as Logo SVG Code:
* Complete SVG code (``)
* Responsive `viewBox` attribute
* No external dependencies
* Optimized file size (under 5KB ideally)
**Additional considerations for cards:**
* **High contrast:** Ensure paths have strong color (card backgrounds vary)
* **Simplicity:** Gift cards are smaller visual space than page headers
* **Test printing:** View in print preview to confirm logo looks good printed
### Managing Multiple Logo Variants
**Strategy 1: Minimal (Easiest)**
* Set only Logo Image: One logo everywhere
* **Pros:** Simplest management, consistent branding
* **Cons:** May not be optimized for all contexts
**Strategy 2: Page vs Card (Balanced)**
* Set Logo Image (page header)
* Set Logo Card Image (gift card)
* **Pros:** Customized for each context
* **Cons:** Two logos to maintain
**Strategy 3: Vector Everywhere (Best Quality)**
* Set Logo SVG Code (page header)
* Set Logo Card SVG Code (card)
* **Pros:** Perfect quality, fast loading
* **Cons:** Requires SVG versions of logo
**Strategy 4: Hybrid (Flexible)**
* Set Logo SVG Code (page header, vector)
* Set Logo Card Image (card, image)
* **Pros:** Optimized page, simple card
* **Cons:** Mixed file types to manage
## Best practices
Always use PNG images with transparent backgrounds for logos. Opaque backgrounds (white boxes around logo) look unprofessional on gift card pages.
Use SVG code for page header logo when possible. Provides perfect sharpness on all devices and loads faster than images.
Create a test gift card product, purchase it (free in test mode), and view the actual gift card page to verify logos display correctly.
Gift cards are often printed. Ensure logos have sufficient resolution and contrast to look good printed on paper.
Check your gift card template's background color/image. Ensure logo has enough contrast to be clearly visible against that background.
Gift cards have limited space. Use simplified logo versions (icon only, no tagline) on cards if your full logo is complex.
Unless you have specific reason for different logos, use the same logo on page and card for brand consistency and simpler management.
Optimize logo images to under 100KB. Use tools like TinyPNG or ImageOptim. Smaller files load faster without visible quality loss.
## Common Use Cases
### Standard Setup (Same Logo Everywhere)
**Settings:**
* Logo Image: Store logo PNG (transparent background)
* Logo SVG Code: Empty
* Logo Card Image: Empty (defaults to Logo Image)
* Logo Card SVG Code: Empty (defaults to Logo Image)
**Result:** Simple management, same logo on page header and gift card graphic
**Best for:** Most stores, consistent branding, straightforward logo usage
### Premium Setup (SVG Everywhere for Quality)
**Settings:**
* Logo Image: Empty (not used)
* Logo SVG Code: Store logo SVG (page header)
* Logo Card Image: Empty
* Logo Card SVG Code: Same SVG as Logo SVG Code (or leave empty to use Logo SVG Code)
**Result:** Perfect logo quality on all devices and screen resolutions, fastest loading
**Best for:** Brands with vector logo assets, quality-focused stores, performance optimization
### Dark Gift Card Background (Inverted Logo)
**Settings:**
* Logo Image: Black logo PNG (page header, light background)
* Logo SVG Code: Empty
* Logo Card Image: White logo PNG (gift card, dark background)
* Logo Card SVG Code: Empty
**Result:** Logo color adapts to background—dark on light page, light on dark card
**Best for:** Gift card templates with dark backgrounds, high-contrast branding
### Seasonal Gift Card Branding
**Settings:**
* Logo Image: Standard year-round logo (page header)
* Logo SVG Code: Empty
* Logo Card Image: Holiday-themed logo or badge (October-December)
* Logo Card SVG Code: Empty
**Result:** Standard logo on page, special holiday version on gift card graphic
**Best for:** Gift-giving seasons (holidays, Mother's Day, Valentine's), special promotions
**Note:** Remember to update Logo Card Image back to standard after seasonal period.
### Simplified Card Logo for Space
**Settings:**
* Logo Image: Full logo with text and tagline (page header)
* Logo SVG Code: Empty
* Logo Card Image: Logo icon only, no text (fits card better)
* Logo Card SVG Code: Empty
**Result:** Detailed logo on page where space allows, simplified version on constrained gift card
**Best for:** Complex logos, logos with long text, maximizing card design space
## Layout Behavior
### Gift Card Page Structure
When a customer views a gift card, the page structure is:
```
[Page Header with Logo Image/SVG]
↓
[Gift Card Graphic with Logo Card Image/SVG]
↓
[Gift Card Code]
↓
[Balance Information]
↓
[Apply to Order / Print Buttons]
```
### Logo Sizing on Page
**Page Header Logo:**
* Automatically scales to fit header height (typically 60-80px tall)
* Maintains aspect ratio (width scales proportionally)
* Centered or left-aligned depending on theme design
* Responsive (smaller on mobile devices)
**Gift Card Graphic Logo:**
* Sized to fit card design (varies by theme)
* Typically smaller than page header logo (limited card space)
* Positioned on card graphic (top-center usually)
* May adjust position based on card template design
### Mobile Behavior
On mobile devices:
* **Page header logo:** Scales down to fit mobile header (typically 40-50px tall)
* **Gift card graphic:** Scales to fit mobile screen width while maintaining aspect ratio
* **Gift card logo:** Scales proportionally with gift card graphic
Both image and SVG logos are fully responsive and adapt to screen size.
### Print Behavior
When customers print gift cards:
* **Logo Card Image/SVG** renders at high resolution for print quality
* SVG logos print perfectly at any DPI
* Image logos print at uploaded resolution (why high-res images matter)
* Page header logo is typically hidden in print view (only card prints)
**Print recommendation:** Test print preview to verify logo quality before publishing.
## Related Sections
* **Header** - Main site header logo (separate from gift card logo)
* **Footer** - Footer branding (separate from gift card logo)
* Email templates - Gift card email notifications (configured in Shopify Admin, not theme)
**Note:** Gift Card section is **isolated** to the gift card template. It doesn't affect other templates or store branding.
## Technical Notes
### Gift Card Template Isolation
The Gift Card section only affects the **gift card template** (gift\_card.liquid). It has no impact on:
* Main store templates (homepage, product pages, collections)
* Email notifications (controlled separately in Shopify Admin > Settings > Notifications)
* Checkout (controlled by Shopify, not theme)
* Admin interfaces
### Image vs SVG Rendering
**Image rendering (PNG/JPG):**
```html theme={null}
```
* HTTP request to load image file
* Width/height attributes set via CSS
* May appear blurry on high-DPI screens if not 2x resolution
**SVG rendering:**
```html theme={null}
```
* HTTP request to load image file
* Width/height attributes set via CSS
* May appear blurry on high-DPI screens if not 2x resolution
**SVG rendering:**
```html theme={null}