> For the complete documentation index, see [llms.txt](https://docs.samita.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.samita.io/b2b-lock-password-protect/reference/how-it-works.md).

# How it works

A plain-language look at how Sami B2B Lock, Password Protect enforces your locks on the storefront.

You don't need to understand any of this to use Sami B2B Lock, Password Protect — [enabling the app embed once](/b2b-lock-password-protect/quick-start/enable-app-embed.md) is all the setup the app needs. But if you're curious what's actually happening when a shopper hits a locked page, or you're trying to reason about why a lock is or isn't showing, this page walks through it.

## The app embed runs on every storefront page

Sami B2B Lock, Password Protect is delivered to your storefront through a Shopify theme app extension embed, listed in your theme editor as **Sami Lock**. Once that embed is turned on for a theme, a small script from the app runs on every page a visitor loads on your storefront — the home page, product pages, collection pages, blog posts, your cart, and so on.

That script doesn't do anything on most pages. Its first job on every page load is to check whether the page matches any lock you've set up at all — and for the vast majority of page views on most stores, the answer is no, so the script gets out of the way and the page renders normally.

## Figuring out which lock applies

When the current page does match a lock — because it's the exact product, collection, page, blog article, or URL you locked, or because you've locked your whole website — the app moves on to checking your access rules for that lock.

This check happens directly in the visitor's browser, using information the app already has access to as part of running on your storefront: whether the visitor is logged in, what's in their cart, which language and country they're browsing from, and so on. Most access rules — logged-in status, customer tags, cart contents, date ranges, storefront language — can be checked immediately with that information, without waiting on anything else.

A few rule types need to look something up before they can answer yes or no:

* **Location** matches the visitor's country, which the app determines with a public IP-lookup service rather than reading it off the visitor's account — so a VPN or proxy can change what country is detected.
* **Cart conditions** (products, variants, quantity, or subtotal) are re-checked whenever the cart changes, since a visitor can add or remove items after the page first loads.
* **Purchased items** and **Order quantity** look at the signed-in customer's past orders to decide whether they've bought the right thing before, or ordered enough times.

Once every rule in at least one access key comes back satisfied, the app treats the visitor as unlocked and lets the content show normally (subject to whatever lock behavior you've configured, like hiding a price or redirecting). If no access key is fully satisfied, the app applies the lock — showing a lock screen, hiding a price or Add to cart button, or redirecting, depending on how you set it up.

{% hint style="info" %}
An access key is a group of rules that must all be satisfied before access is granted. See [Combining rules](/b2b-lock-password-protect/access-rules/combining-rules.md) for the full explanation.
{% endhint %}

## Checkout locks work differently

Everything above describes how locks on your website — products, collections, pages, blogs, URLs, and your whole storefront — are enforced. A [checkout lock](/b2b-lock-password-protect/content-to-lock/checkout.md) is enforced differently: instead of relying on a script running in the visitor's browser, it's enforced by Shopify's own checkout validation, using the conditions you set up in the app's checkout rule builder. That means a locked checkout condition can't be bypassed by disabling JavaScript or otherwise working around client-side code the way a purely visual lock theoretically could — Shopify itself refuses to let the order complete until the condition is met.

{% hint style="warning" %}
Because checkout enforcement is separate from the website-lock mechanism above, turning on the app embed is still required for your website locks, but it has no bearing on whether your checkout lock is active — that's controlled entirely by the rules you save in the checkout lock's builder in the app.
{% endhint %}

## One setup step, nothing to edit in your theme

Because the app embed handles all of this itself, there's no theme code for you to write or maintain. You don't add snippets to templates, edit Liquid files, or maintain a list of locked pages in your theme — everything lives in the app, and the embed reads your current lock configuration every time a page loads. [Enabling the app embed once](/b2b-lock-password-protect/quick-start/enable-app-embed.md) is the only setup this requires; after that, creating, editing, or removing locks in the app takes effect on your storefront automatically, with nothing further to enable in your theme.

## Related docs

* [Enable the app embed](/b2b-lock-password-protect/quick-start/enable-app-embed.md)
* [How locks work](/b2b-lock-password-protect/quick-start/how-locks-work.md)
* [Checkout](/b2b-lock-password-protect/content-to-lock/checkout.md)
* [Permissions and data](/b2b-lock-password-protect/reference/permissions-and-data.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.samita.io/b2b-lock-password-protect/reference/how-it-works.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.