Magento multi-store is where generic chatbots leak data. Two store views, one knowledge blob, and a browser-supplied store code is how Product A on Store B shows up in the wrong language with the wrong prices. Claspwell prices and isolates per store_id on purpose.
Read this before you ask for “one plan for the whole group.” The product landing page is /magento-2-ai-chatbot; security claims are on /security.
What a tenant is
A tenant is one Magento store, or an isolated store view we bind, with its own catalog, knowledge, conversation history, allow-listed origins, and encrypted Magento credentials. Session JWTs carry a verified store_id. Queries are scoped to that id. The widget cannot pick another tenant.
Why store views are usually separate subscriptions
A German and a Swedish storefront are different catalogs even when they share a Magento install. Mixing them “for convenience” is how SKUs and chat history cross borders. Essential and Growth are one store each. Scale includes up to three store tenants on one contract. Agency is quoted for larger estates.
Credentials and origins
OAuth / integration credentials are stored encrypted, per tenant. Origins are allow-listed per storefront. A staging origin does not get production catalog access because someone pasted a key in a theme. That wiring is part of the guided install.
What we still need from you
A list of stores and views in scope, which catalogs must never mix, Magento version, Hyvä yes/no, and who owns deploys. After we accept the request we schedule a discovery call by email — there is no public calendar embed in v1.
Related reading
Catalog sync mechanics: /blog/magento-ai-chatbot-catalog-sync. Pricing arithmetic: /blog/magento-ai-chatbot-pricing-tiers. Request integration when the store list is real.