Previews and releases

Every push is built. Where that build ends up depends on which branch you pushed.

Push to	What happens
Any branch	Built, and loadable on your site at ?_lbx_env=<branch>
main	Built, tested, and — if the tests pass — published as what your site loads

Previewing a branch

Append the branch name to any page on your site:

https://example.com/search?q=running+shoes&_lbx_env=search-widget

The choice persists for the rest of that tab’s session, so you can navigate the site normally after setting it once. A new tab loads production again.

Two reserved values:

Value	Effect
development	Load from your local yarn dev server
stop	Turn the integration off entirely for this session

Use stop to establish whether a problem is yours or the integration’s: it removes the integration from the page without touching a deployment.

If a branch’s build cannot be loaded, the loader falls back to production and says so in the browser console rather than leaving the page with no integration at all.

Previews run on the real site, with real markup and real catalog data; there is no staging copy of your storefront to keep in sync.

Releasing

main is production. A push to it — normally a merge — is built, checked by an automated testing agent that exercises the integration against your live pages, and published if that passes. Nobody approves it in between; merging is the release decision.

The published script is served from the repository’s loader_script_url, which never changes. Your site embeds it once and every subsequent release replaces what it serves.

<script src="https://cdn.eu1.luigisbox.ai/b/lbdr_8w3k2p/loader.js"
        data-publishable-key="pub_live_eu1_CNA1QBVS7PQzKNDn"></script>

Two parts to that tag:

src	The repository’s loader_script_url. Read it from the repository record rather than assembling it — see Repositories API.
data-publishable-key	The publishable key the integration authenticates with. Not a secret, and meant to be in page source.

A working habit

Work on a branch, not on main. A testing branch exists from the start for work in progress that is not ready for its own branch.

The sequence:

1. Branch from main.
2. Push, and look at the preview URL on the pages that matter — including the ones you did not touch.
3. Have whoever owns the storefront look at the same URL.
4. Merge.

Rolling back

A release is a commit on main, so a rollback is a git operation: revert the merge and push. That builds and republishes the previous state.

Revert rather than force-push, so the history records what was live and when.

See also

• Your first integration — getting to the first preview
• Repositories API — reading a repository’s URLs and state
• Distribution