Multi-store and multi-website
How the integration behaves on a Magento installation with several websites, stores and store views. Plan §11 and §20 item 11. Measured on the local stack with a default store view plus a second store view (setup-wizard.sh); a multi-website installation and a website on a non-default MSI stock have not been tested.
One installation, one workspace
One Magento installation connects to one Conviro workspace, through one Magento integration and one API key. Everything that describes the connection is installation-wide (default scope). Connecting a second installation to a workspace that already has a store replaces it — the approval page says so.
| Varies per | Settings |
|---|---|
| Installation (default only) | API key, connection, signature enforcement, AI capabilities, trust policy, cart/payment confirmations, store-view selection, sync plan |
| Website | Sync toggles: order events, product sync, lead creation, cart recovery, payment assist |
| Store view | Widget on/off, widget public key (a store view can use a different chatbot's widget), position, colour, greetings, lead form, UTM tags |
Details: configuration-scopes.md.
Choosing store views (wizard step 4)
Default: all store views, including ones created later (mode all). Unticking some saves mode selected with the ticked ids. For a store view that is not selected:
- no
customer.*,order.*,cart.*orpayment.*event is sent, and the order history and customer import skip it (admin-created accounts and admin-scope events count as the default store view); - Conviro never reads live data in it. A shopper whose widget reports an unselected store view is answered from the default store view if that is selected, otherwise from the first selected website's default store view;
- product and inventory events still flow (they are catalog-wide).
The mapping (website, store, view, code, name, locale, currency, base URL, selected, website default; at most 500 store views) is sent to Conviro and shown in the Conviro dashboard's Magento card. It is re-sent on every re-registration.
Store view in live answers
The storefront widget reports the store view (code, locale, language). Conviro uses that code only when it names an active, selected store view (the store topology is cached for 1 hour), and then reads price and stock in that view:
- Price: the storefront final price in the store view's display currency from Magento's
products-render-info(measured: 35.91 EUR final, reduced from 44.91 EUR, where thepriceattribute is 49.90 USD); when that is unavailable, thepriceattribute stated as a regular price in the base currency. No currency is named unless it could be established. - Stock: MSI salability on the website's stock (measured: salable 99 after one order while the source quantity still said 100); legacy stock where MSI is absent.
- Cached reads are keyed by the full workspace id and the store view, so two store views never share a cached price or stock.
Known limit: on a multi-website installation, a request without a shopper store code whose connected URL matches no website gets the regular (not final) price and the legacy stock flag without a quantity.
Knowledge base
The product knowledge base is one entry per SKU, not per store view. The catalog re-sync builds it from the default store view; product events use the store view of the save. Store-specific live facts (price, stock, order data) always come from the live reads above, not from the knowledge base.
Languages
The widget passes the store view's locale and derived language, so the assistant answers in the store view's language by default. Confirm / decline choices for AI actions and outcome messages are written in the conversation's language.
Signed customer identity per store view and website (1.5.0, unreleased)
1.5.0 (unreleased), read 2026-09-27 on feat/magento-1.5.0-customer-hub; not tested on a multi-website installation (unit tests only). What the feature is.
| Varies per | Identity settings |
|---|---|
| Installation | one Ed25519 key pair and installation id for all websites; key rotation; the order-listing permission (granted while My orders is on for any website) |
| Website | Enable signed customer identity, Show verified shoppers their own orders, Orders a verified shopper sees, Ask guests for a one-time code |
| Store view | whether the widget renders (Enable, Widget Public Key) — the bootstrap answers 404 where it does not |
- The store view is the store's, never the browser's. The signature names the store view that served the bootstrap request (
StoreManager); astoreCodesent by the page is ignored. Conviro accepts it only for a store view in the integration's store mapping that is active and selected in wizard step 4 (or mode all); any other store view is refused, so nobody there is verified. - A verification belongs to one store view. The verification (and the store's binding) is scoped to the store view it was made in. Moving to another store view loads a new page, and the widget verifies again there; every order read is made through that store view's REST path, and Magento refuses a binding used in another store view (
store_mismatch). - Which orders (setting Orders a verified shopper sees, per website): This store view only (default) = orders placed in the store view the shopper is in; Every store view of this website = also the website's other store views. Never another website — even when Magento shares customer accounts globally (
customer/account_share/scope), a shopper verified on website B does not see orders placed on website A. Always selected by the customer id of the binding, never by e-mail, so guest orders with the same e-mail and another account's orders are never merged. Only statuses the storefront's My Orders page shows. - Language and currency. The status label is the store view's own label; totals are in the order's currency; the widget formats dates and amounts in its language.
- One workspace. The key is registered with the workspace the installation is connected to; if another workspace has an active connection to the same store URL, Conviro refuses the key.