Integrations

Much of what customers see on this store comes from installed apps rather than from this repository. Their behaviour can change without a commit here.

This page covers how the theme relates to them. For a lookup table of every app and its theme files, see Third-party apps.

Categories of integration

Apps reach the storefront three ways, and which one applies decides how much control the theme has.

Some apps inject scripts through content_for_header, which Shopify renders in the layout head. The theme cannot prevent this directly, so it uses Yett to hold them back.

Some apps ship theme snippets that the theme renders explicitly, for example snippets/boost-pfs.liquid and the snippets/limoniapps-discountninja-*.liquid family. These run only where a Liquid file renders them.

Some apps expose a browser SDK that theme code calls, such as Sesami for booking. For these apps the theme code makes the calls.

Script blocking with Yett

Every layout loads Yett synchronously, before content_for_header, so it can intercept injected script tags. Each layout sets window.YETT_BLACKLIST to a list of URL patterns.

layout/theme.liquid blocks little. It holds back Appstle on pages outside the subscriptions app proxy, plus the two upsell vendors.

The MediSpa layouts block a long list of commerce apps. A comment in the layout records the reason. These pages carry paid traffic, their only call to action is a booking form, and the team has no admin access to some apps' own page-targeting settings. Klaviyo, Google Tag Manager and Meta stay unblocked because the form and the campaigns need them.

snippets/yett-unblock.liquid releases everything Yett is holding on the first touch, keypress or click. Blocked apps therefore load on interaction rather than never, which keeps the initial render fast without permanently breaking a feature.

If a script seems missing on a page, check the layout's blocklist before assuming the app is broken.

Deferred app loading, currently inert

snippets/load-apps-script.liquid implements a second layer. It reads a pipe-delimited list of URL fragments per template type and splits app URLs into critical and delayed groups.

The mechanism does nothing today. It reads settings.app_delayload_collection and settings.app_delayload_product, and neither setting is defined in config/settings_schema.json, so both resolve to blank and the delayed list is always empty. layout/theme.liquid still renders the snippet. The MediSpa layout has the render commented out.

Adding the two settings to the schema would switch the feature on across the main storefront immediately. Test the change on a preview theme before you add them.

Klaviyo

Klaviyo owns email and SMS capture, back in stock alerts, and the MediSpa booking form.

The theme holds form IDs in three places. Product page and MediSpa offer popups use IDs in theme settings under the Klaviyo group. The MediSpa booking form ID is in theme settings under the Medispa group. The sitewide signup popup IDs are compiled into src/components/popup-logic/definitions/sign-up-forms.ts, mapped per market.

The theme also coordinates when a Klaviyo popup may open, through the popup manager. Klaviyo decides what a popup contains and who qualifies for it. The theme decides when it opens. See Popups and forms.

Sesami

Sesami owns appointment availability and reservations for MediSpa treatments.

The theme calls window.SesamiSDK, which arrives as the app's own script tag. The React calendar polls for it every 50 milliseconds before mounting, because the theme cannot control the load order.

Reservations return a token that the theme attaches to the cart line as _reservation_token. Everything about the reservation's lifetime belongs to Sesami. See MediSpa booking.

Zapier

A Zapier webhook receives the booking intent when the Klaviyo form is submitted. The URL sits in theme settings under Medispa.

The payload shape is defined in src/@types/calendar.ts with keys enumerated explicitly, so the Zapier receive node sees a stable schema. The Zap itself exists only in Zapier, and this repository has no copy of it. Changing either side alone breaks the flow without an error, because a Zapier webhook accepts an unexpected payload.

Discount Ninja

Discount Ninja owns promotion display, discount codes in the cart, and the promotional bars and badges. It ships a large family of snippets under snippets/limoniapps-discountninja-*.liquid.

It writes to the Shopify cart, which is one of the reasons the mini-cart patches window.fetch. See Mini-cart.

Several of its snippets are in .prettierignore, because the app regenerates them and reformatting produces noise in every diff.

Boost

Boost owns search and collection filtering, through snippets/boost-pfs*.liquid and its own assets. Collection templates that use it look different from those that do not, which is why templates/collection.boost-sd-original.json exists alongside the others.

Google Tag Manager

snippets/gtm.liquid renders the container, gated on the GTM Tracking theme settings. Data layer events are pushed from several places, including sections/mini-cart-line-items-datalayer.liquid for cart contents.

The container ID is in theme settings, so changing it does not need a deploy.

Working with vendor files

Treat any file carrying a vendor prefix as vendor-owned. Editing one works until the app updates its theme integration and overwrites the change, at which point the fix disappears with no warning and no diff to point at.

When vendor behaviour has to change, change it in the app's own admin. When that is impossible, wrap the vendor file rather than editing it, and record why in Legacy and unused code.

Source map