Skip to content

FAQ

Open Shop is a commerce platform that lets you drop commerce into any site and scale without platform lock-in. You keep full control: your site, your brand, your rules. Unlike other closed platforms, Open Shop works with your existing site, stack, and brand through a modular, web component–based architecture.

Other platforms give you a storefront; Open Shop gives you a system. You drop or embed the e-commerce pieces you need—product cards, checkout, cart—where you need them on any site. There’s no bloat and no full rebuild. Open Shop’s web components make it simple to add only what you need while keeping full control over the commerce experience.

Can I use a site builder like Webflow to build my site?

Section titled “Can I use a site builder like Webflow to build my site?”

Yes. Open Shop is built to work with your existing site and stack—including sites created in visual site builders like Webflow, Framer, or similar tools. Because Open Shop uses web components that you embed where you need them, you can add product cards, checkout, or a cart to any page where your builder allows custom code or embeds. Your site stays in the builder; commerce is handled by Open Shop.

Can I integrate this with a custom-built site using something like Vue?

Section titled “Can I integrate this with a custom-built site using something like Vue?”

Yes. Open Shop’s web components are framework-agnostic and work with custom frontends built in Vue, React, Svelte, or any other JavaScript framework. You can drop the same commerce modules—product cards, checkout, cart—into your components or views and wire them to your existing routing, state, and styling. Your app stays yours; Open Shop handles the commerce layer.

Do I need !important to restyle an Open Shop component?

Section titled “Do I need !important to restyle an Open Shop component?”

No. Every style the Open Shop bundle injects lives in a CSS cascade layer named os-components, and cascade layers are resolved before specificity and source order — so any unlayered rule beats any layered one. Your site’s CSS is unlayered, which means a plain single-class selector like .os-cart-item-name { color: red } already wins.

If you added !important or doubled-up selectors against an older bundle, they still work and nothing regresses; you can remove them whenever it suits you. The one exception is the rule that keeps data-os-show and data-os-hide elements hidden: it is !important inside the layer, so no site rule, !important or not, can re-show an element the layer hid. See Overriding styles.

Ask Open Shop. The bundle installs a window.OpenShop object, and OpenShop.customer.current is null for a guest, a customer object for a signed-in shopper, and undefined while it is still resolving. Listen for the customer:change event to be told when it settles. If all you want is to swap a Login link for the shopper’s name, you don’t need any JavaScript — put data-os-show="guest" on one link and data-os-show="customer" on the other. There is a data-os-hide for the opposite test, such as hiding a signup nudge from signed-in shoppers, though login links should stay on the show pair. See the JavaScript API and the data attributes reference.

Do not try to read the session cookie yourself. Open Shop’s auth cookies are httpOnly, so JavaScript cannot see them; the only way to know is to ask the server, which is what OpenShop.customer does for you — once per page load.

Why do I see a 401 for /customer/me in the console?

Section titled “Why do I see a 401 for /customer/me in the console?”

That’s expected, and nothing is broken. On every page load Open Shop asks the API who is signed in. For a guest, the API correctly answers 401, and Chrome logs any non-2xx response as a failed request in the console. The bundle handles it and reports the shopper as a guest.

You’ll only see it for signed-out visitors. An expired access token is not the cause: the server silently trades the refresh cookie for a new access token inside the request, so a short-lived token running out is invisible. A 401 means the session itself has ended — the refresh token expired or was revoked — and the shopper is a guest again. Signing back in is the only fix; refetching will not bring the session back.

Can I read the shopper’s email from the page?

Section titled “Can I read the shopper’s email from the page?”

No. The customer object exposes id, firstName, lastName, accountTypeName, priceTypeName, isAffiliate, and householdRole — no email address and no phone number, deliberately.

Anything on window is readable by every third-party script on the page: your tag manager, analytics, chat widget, A/B testing tool, and anything those load in turn. A name and an account type are what a storefront needs to personalise itself; contact details are not worth handing to every tag on the page to get there. If you need a shopper’s email for something server-side, do it server-side.

Open Shop is for teams and brands that want commerce without compromise: flexibility to use their own site and stack and a modular system that grows with them. It’s especially useful if you need to add commerce to an existing site or avoid platform lock-in.

Reach out for a demo, partnership, or technical consultation at contact@openshopgo.com or visit openshopgo.com to get in touch.