Frequently asked questions about PIM for Shopware

PIM (Product Information Management) is a plugin for Shopware 6 that speeds up product maintenance dramatically - with bulk edit across more than 40 actions, multilingual CSV import, variant generator and AI text generation with ChatGPT, Claude, Mistral and Gemini. Everything directly in the Shopware admin, without an ETL tool or third-party system.

Shopware 6.6 and 6.7. Since version 1.11.48 a single package covers both lines - the administration file is additionally placed under js/, from where 6.6 loads it, while 6.7 still uses the Vite manifest. Separate packages per Shopware version are no longer needed.

No. PIM runs on your Shopware server and product data does not leave it. For the licence check the plugin queries the Stone & Water licence server with plugin name, licence key and shop domain. External AI providers (ChatGPT/Claude/Mistral/Gemini/DeepL) are only contacted when you actively trigger them - and with your own API keys.

Via Shopware Store: search "PIM for Shopware" under Extensions → Store, install, activate. Or manually: download ZIP and upload under My extensions.

PHP 8.2 or newer. Database: MySQL 8 or MariaDB 10.11. Memory: at least 256 MB, 512 MB recommended for large catalogues.

More than 40 actions in up to ten tabs: master data (status, top seller, clearance sale, free shipping, EAN, release date, listing configuration, approval), assignment (manufacturer, essential characteristics, warranty, categories, tags, properties, visibility, cross-selling), prices & stock (price as fixed value, percentage, amount or purchase price markup, pseudo price, stock, tax class, order quantity, purchase steps, tier linking), shipping (dimensions, weight, delivery time, restock time, pack unit, base price, product unit), SEO (meta title, meta description, SEO URL, main category, canonical variant) and custom fields. Plus AI & texts, generate variants, clear fields and delete. Name, description, product number, purchase price and list price are not among the set actions. Details on the Bulk edit page.

Yes. From 6.7.14 Shopware has the warranty period in months and the retailer confirmation; the PIM maintains both in their own master data section, inheritable per variant and via the "warranty" action in bulk edit as well. In installations below 6.7.14 the section is visible but locked and explains why - the values are not written there either. For Shopware to output the label it needs a warranty period of more than 24 months, confirmed data and a maintained manufacturer including the manufacturer product number.

Yes. In the "clear fields" section, custom fields can be selected alongside master data, SEO and link fields. As custom fields are translatable, the existing language selection applies; the values are stored in the snapshot before clearing and stay reversible. There is deliberately no "all custom fields" switch, because a shop quickly has dozens of them.

Straight from the assignment tab in bulk edit. Options without a translation are marked and counted at the top; the pencil icon opens a dialog where the translated name can be entered for several languages at once - without leaving the Shopware property catalogue. The check runs against the languages of the sales channels the affected products are assigned to. Property translations apply per language in Shopware, not per channel.

There is no dedicated action for setting the purchase price in bulk edit. You maintain the purchase price in the detail view, in the quickview or via CSV (columns purchasePrice for gross and purchasePrice_net for net - if only one is given, PIM calculates the other from the tax rate). In bulk edit the purchase price serves as the basis for the price modes "purchase price + %" and "purchase price + €".

Before every bulk operation a snapshot of the previous values is saved automatically. In the config matrix, Snapshots tab, you can compare it with a diff and restore it. By default snapshots are kept for 90 days, at most 50; both can be adjusted.

If you choose a preset as the source, PIM shows its active filters as readable chips, for example status, stock, with/without variants, manufacturer, categories, dynamic product group, sales channel, tag, tax, delivery time, price and weight. IDs are resolved to names. "No filters active" is marked red.

Translatable fields show the "Channels & languages" selection: meta title, meta description, SEO URL (SEO tab), translatable custom fields and pack unit (shipping tab). The value is set in the default language AND written to every selected language - one action, several languages.

There is no "Limit to filter" switch. Which products are affected follows from the source (selection or preset filter). Whether the variants of chosen products are changed too is defined by "Include variants by default" in the config matrix (Bulk edit tab).

Yes. In one run you can set manufacturer + change tax rate + sales channel visibility + product unit simultaneously - all in one go with a shared snapshot.

Via the selection all checked products, via a preset filter up to 500 products by default - adjustable in the config matrix up to "Unlimited". For large batches you see progress with counter, phase (snapshot/write) and estimated remaining time - cancellable at any time.

In bulk edit, "Copy to variants" copies price tiers and cross-selling from the main product to all variants; in addition there are "Visibility to variants" and "Properties to variants". In the detail view, "Copy to variants" copies selected fields such as price, pseudo price, purchase price, stock, delivery time, free shipping, weight & dimensions, EAN and active status; images and properties have their own buttons.

Inheritance in Shopware works all-or-nothing per field: as soon as a variant has an own property, it inherits nothing at all from the master product in that field. The PIM makes this visible - such properties are highlighted in orange and counted - and the button "transfer properties to variants" adds the missing ones. A second common reason: the group has "display on product detail page" switched off; those groups are marked "not in storefront".

A dialog asks up front which fields the variants should inherit from the main product: images, name, price, weight and EAN. Inherited fields pick up later changes to the main product automatically; non-inherited ones are copied as an own value. Stock and product number stay variant-specific by system design. The duplicated master product receives its own correct SEO URL from the channel template. For simple products without variants the dialog does not appear.

Not recoverable via snapshots are generated variants (they remain), deleted variants and deleted products. The dialogs point this out.

Yes. The main export language fills the main columns such as name, further languages appear as columns trans_<channel>_<language>_<field>, e.g. trans_mainshop_en_GB_name. Language-specific custom fields are named cf_<name>__<language code>. Which channel languages appear is set in the config matrix.

Two separate columns: purchasePrice (gross, on import also as purchasePrice_gross) and purchasePrice_net. On import all combinations are possible - only gross (net is calculated from the tax rate), only net (gross is calculated) or both (taken over 1:1). Aliases such as ek_brutto or cost_net are recognised.

As separate rows. Variant export is activatable per profile or globally. Parents and variants appear with clearly identifiable productNumber in the same file.

No. Variants can be assigned to their parent via the parentProductNumber column - UUIDs are not required.

Instead of a cryptic UUID, the product unit is exported as a readable name ("Litre", "Kilogramm", "Piece"). On import, the name is automatically resolved to the correct Shopware unit ID - Excel-friendly.

No. Custom field JSON is merged, not overwritten. If only one column cf_xy is in your CSV, other custom field entries of the product are untouched.

The import runs in batches via the Shopware sync API with a progress display. Batch size, parallel image uploads, rate limit and indexing are set in the config matrix (Import / export tab) to suit the server.

There is no cancel button for a running import. With "Abort import at error count" (config matrix) the import stops after a chosen number of errors, and in strict mode all changes imported so far are reverted automatically on errors. The last import can also be undone in the change log.

Superadmins always, regular users as long as the "CSV import" function switch in the config matrix (PIM superadmin tab) is on - which is the default. There are no dedicated Shopware permissions for CSV import or export.

Practically unlimited. Tested with 100+ variants in under 10 seconds. For very many options, use the live preview to verify the exact count in advance.

A single search at the top of the variant generator filters properties and options simultaneously. Type "red" and all property groups with "red" as an option stay visible, with matches highlighted.

SKU and variant name patterns shown as separate accordions. Collapsed they show the current pattern as a chip; expanded an input plus clickable variable chips appear. Click a chip to insert directly.

From two property groups on, the matrix view shows all variants of a product in a table: rows are the options of one group, columns those of the other. In every cell you edit one value directly - price, stock or active.

{parentNumber}, {firstVariantNumber}, {parentName}, {options}, {option1} to {option3}, {group1}, {group2} and {counter}. The older {number} is read as {parentNumber}.

In bulk edit ("Generate variants" tab, "Delete variants" action) the recommended scope "Only without orders" skips variants with orders and keeps them. "Delete ALL variants" deletes those too - be careful. Deleting is irreversible.

Four providers, all usable in parallel with provider selection per generation: OpenAI ChatGPT, Anthropic Claude, Mistral AI and Google Gemini, each with their latest models. Plus DeepL for translations. In bulk edit ChatGPT, Claude and DeepL are available. The model selection is maintained continuously. New models from OpenAI, Anthropic, Mistral and Google arrive in the config matrix with the plugin updates.

Yes. You create the keys with the respective provider (console.anthropic.com, platform.openai.com, console.mistral.ai, Google AI Studio or DeepL) and enter them in the config matrix in the Texts & translations tab. The keys are stored in the plugin configuration in your Shopware database; requests run through your shop server directly to the provider.

Product name, description (HTML), meta title (max 60 chars), meta description (max 155 chars) and keywords. Individually or together, for one product or via bulk-edit for many. The product name is deliberately not preselected so that existing names are not overwritten by accident; overly long names are truncated to 255 characters.

Under "Texts & translations" in the configuration, length targets can be stored per field in words and characters. Defaults are 120 characters for the product name, 60 for the SEO title, 155 for the meta description and 250 words or 1500 characters for the description - the lengths search engines usually display in full. A value of 0 means no target. The values go into the prompt and also determine the token budget, so the response no longer breaks off mid-JSON when many fields are selected.

A central instruction in the configuration that is passed to every AI request - in the detail view, in bulk edit and when copying from the default language, regardless of the selected provider. Permanent rules can be set once, such as salutation, brand spelling, mandatory information or forbidden phrasings. Instructions in the respective dialog are preserved and complement the master prompt.

When a sales channel uses its own language, no own texts exist there at first - the storefront falls back to the inherited content, but the AI has no starting text in that language. The function copies name, description, meta title, meta description and keywords from the default language into the selected target languages. By default only empty fields are filled; overwriting can be enabled optionally. It is available in bulk edit (section AI & texts) and as a bulk action in category management.

You, directly with the provider. Stone & Water charges no additional fees or margins.

Through the budget and limits with your AI provider. In bulk edit PIM shows a fixed notice that every product is sent to the API individually. There is no cost display in euros, no bulk limit and no cost threshold with confirmation. You control the scope with the number of parallel requests and the choice of fields and languages.

Yes. When several providers are active, the generator modal lets you pick the right one per call - Claude for demanding descriptions, a flash model for fast meta data.

Professional, Casual-modern, Premium/Luxury, Technical, Emotional. Default per shop in the config matrix, override per operation.

The central control of the plugin with 13 tabs: General, Dashboard, Products, Variants, SEO URLs, Texts & translations, Import / export, Bulk edit, Approval, Change history, Snapshots, External systems and PIM superadmin. You open it via the "PIM Configuration Matrix" menu item in the Stone & Water menu; Ctrl+K searches all settings.

You set the order of the sections in the product detail view (master data, prices, media, SEO, …) and in the variant view in the config matrix in the Products and Variants tabs - with the "Move up" and "Move down" buttons.

Both SEO generators support per-sales-channel patterns: step 1 its own token pattern, step 2 its own Twig pattern. Shop patterns are a list with pencil (edit) and trash (remove). Shops without their own pattern use the default pattern. Details in the FAQ section "SEO URL system".

Yes, both generators process parent and variants. Inherited fields are resolved from the parent product (incl. translated customFields with inheritance). The tokens {options}, {properties} and {tags} deliver language-translated values - patterns like {mainCategoryPath}/{name}-{options} produce unique URLs per variant.

Via drag & drop: in master data and the variant view, the images section has a drop zone (below the images). Drop files or click for the file dialog - uploads go to the Shopware media library (product folder) and are assigned immediately, with progress display. The first image automatically becomes the cover if none is set.

An image uploaded to a variant becomes the variant's own image and overrides the inherited one. Removing the own image restores inheritance from the main product - both stay possible at any time.

An approval status that editors can set themselves - signalling to the team that someone's currently working on the product. In parallel to approve/reject/submit. Visible as badge + button in the detail view, as filter and indigo indicator in the product list and in the approval statistics.

Assigned categories are shown as removable chips below the category tree (small × to remove) - visible at a glance, without searching the tree.

Yes. In the config matrix, General tab, "Visible columns in the product list", "Add custom column" creates a column with its own name and source field - either a master data field (release date, stock, dimensions, date fields, …) or any custom field. Optionally sortable. The columns apply to all users.

Yes. In the config matrix under General → Product list you can enable "Compact variant view". Variants are then displayed space-saving - without large indentation, without preview image and with noticeably flatter rows; name and options are preserved. After changing it in the config matrix, click "Save".

Yes. The importer reads DATANORM 4.0 and 5.0 (automatic version/manufacturer detection via the V; header), accepts any volume suffix from .001 to .999 (e.g. DATANORM.500) and processes the record types A (article), B (product groups), T (long text) and P (prices/DATPREIS). After that the same mapping, validation and import logic as for CSV applies.

Feed Generator, CSV import/export and create product sit in their own row above the search - on all viewport sizes. The search field keeps its full width. The price column is sortable by clicking the header (server-side), and the manufacturer filter loads all manufacturers paginated (no more 500 cap).

Yes. The "Categories" button (left of the Feed Generator) opens a modal with a category tree per sales channel: create, rename, activate/deactivate, delete, move via drag & drop. Name/description/SEO are maintained per language (description as a WYSIWYG editor), plus type, layout (CMS experience), external link, main-navigation toggle and custom fields. An "AI texts" button generates description/meta/keywords across all four providers - optionally for the entire subtree. Secured via the "Manage categories" permission. All details in the category guide.

Yes. Each category has a cover image (media library/upload, with alt text), its own SEO URL slug per channel/language (old URL stays as 301, new becomes canonical and survives reindex) and a product assignment via a dynamic product group (stream) or a StawPim preset filter. Plus a completeness score (description/meta/image) in the tree and bulk actions with snapshot/history.

Yes. Via "Import/export" you export the channels tree as multilingual CSV (one column per language for each translatable field in the format field.locale, custom fields as cf. columns) or as a full JSON backup. The import resolves parents via the parentPath column, creates missing categories and updates existing ones - with preview, validation and a CSV backup before importing.

Both. The config matrix has a "Shopware standard SEO URL" option (separately for product detail, variant modal and Quickview). When active, the field shows the native Shopware SEO URL and is directly editable (writes via PATCH to seo_url, no duplicates). The StawPim canonical system is then hidden. So you can either work rule-based via the two generators or simply edit the native URL directly in the PIM.

The "Create product" button opens a guided modal asking for the essentials: name, article number (reserved from the number range, editable) and sales channel visibility. Price (0), default tax rate and inactive status are set silently as defaults; the product is created fully and opened directly. No more invisible, category-less orphan records - categories and price are maintained on the detail page.

On the detail page in the "Availability" section (previously under "Visibility"). It's now named consistently "release date" (Shopware's releaseDate) - instead of the former mix of "release date", "approval date" and "publication date". Settable per variant in quick-edit and in the variant detail modal (empty inherits from the parent). The former separate "available from" field no longer exists; on CSV import, an old availableAt column is still mapped to the release date if that is empty.

Yes. Alongside the field pattern (step 1 of SEO generation), a meta title pattern can be configured. It's resolved as plain text (no slugification - umlauts and capitalisation are kept) and written to the product meta title per language; respects "only empty" and truncates at 255 characters. Conversely, the maintained meta title is available as the token {metaTitle} as a source in the field pattern and in the AI templates.

When creating a new product, the first tax rate from the system is automatically preselected (sorted by position ASC). Gross/net calculations work immediately.

Save with empty required fields: a modal opens listing all errors. Clicking an error jumps to the section - it expands, the field is highlighted with an indigo outline.

Clicking a variant in the product list opens a compact modal with its master data: basic data, prices (gross/net, purchase price, pseudo price, Omnibus), description, availability & dimensions and SEO. Which fields appear is set in the config matrix in the Variants tab under "Quickview fields". The header shows the variant name large and the product number behind it.

Stock, price (gross), EAN, manufacturer number, weight and the active switch directly in the row - for variants too. The value is saved immediately when you leave the field; a message confirms it.

A feed delivers your product data under a unique, tokenised URL - automatically updated, no manual export. Typical recipients: Google Shopping, idealo, Billiger.de, ERP systems or analytics pipelines.

At the top of the Feeds tab there is the "Create feed from template / profile" selector. You pick a built-in template (master data, prices & stock, SEO, images, translations, variants, full export) or one of your own saved export profiles. One click creates a new feed with that field selection.

All feeds as a compact accordion list. Per row you see: name, status pill ("feed active" / "no feed"), feed URL preview, filter template chip, product count chip (live from the catalogue), pencil icon for editing and trash icon for deleting. Clicking the row reliably opens and closes the editor (chevron on the right rotates).

Yes. The expanded editor has a name field. The name must be unique - collisions with existing feeds or built-in profiles are rejected. The active profile, count chip and editor state automatically move to the new name.

Via the trash icon on the right of the row. A confirmation dialog appears. The delete button reacts separately from clicking the row - so you don't accidentally open the editor when deleting.

Yes. Feeds are decoupled from the source profile via an own storage key (exportFeeds). You can create any number of feeds for the same profile - e.g. a "Master data" profile as basis for multiple feeds with different filter templates per sales channel or target market.

In the feed editor you pick a saved filter template (preset). The feed then filters like the product overview. Only the approval status and "RRP invalid" cannot be mapped. Under "Applied in the feed" the editor shows which criteria take effect.

The feed now filters with the selected filter template like the product overview. The only exceptions are the approval status and "RRP invalid", which cannot be mapped in the feed. If a template contains these criteria, the feed delivers more products than the filtered list.

Each feed row has a product count chip. This value is determined live from the catalogue (via the filter template criteria) and updates when you pick a different filter template.

Existing feeds that were attached to the export profile are automatically migrated into the new list on first load. Existing feed URLs in your ERP, Google Shopping account or at price comparison portals remain valid - no re-configuration required.

CSV, XML and JSON - there is no TSV in the feed. The URL is https://your-shop.com/staw-pim/export/{token} (the suffix .csv is accepted too), alternatively https://your-shop.com/api/staw-pim/export/{token}. Encoding (UTF-8, Windows-1252, ISO-8859-1), BOM and decimal separator can be set per feed.

Feed URLs are tokenised and not publicly indexable (no entry in sitemap.xml, noindex header). Without the token, nothing is visible. The token can be regenerated by one click anytime - the old URL then becomes invalid.

Very - the feed is purpose-built for large catalogues. Four performance layers work together: (1) DBAL streaming in 2,000-batches (data is emitted row by row via PHP generator, no full memory load). (2) Keyset pagination on the product number instead of LIMIT/OFFSET (stays linearly fast, even on deep pages). (3) gzip compression with ~80-90 % reduction on text CSVs. (4) File mode with pre-generated file every 15 min. This way even catalogues with tens of thousands of products run through without memory issues.

Yes, automatically. If the client sends Accept-Encoding: gzip (all modern ERP/crawler/browser clients do), the response is server-side compressed via gzencode() and delivered with Content-Encoding: gzip + Vary: Accept-Encoding. Feed CSVs typically compress by 80-90 % - a 50 MB CSV is transferred as ~5-10 MB. The client decompresses transparently.

Live on request: Feed is generated directly from the database on every request. Always up-to-date, suitable for infrequent polling or smaller catalogues. File: A scheduled task pre-generates the file (every 15 min, atomically written), and the controller serves the ready file. No DB load, very fast response - ideal for ERPs that poll every few minutes. If the cron file doesn't exist yet, the controller automatically falls back to live generation.

Yes. The storefront feed route sets allow_maintenance, plus an early kernel subscriber answers feed requests before Shopware's storefront machinery kicks in. Google Merchant and ERP polling keep running during deployments and maintenance windows - instead of receiving a redirect page.

In addition to the storefront URL, there's the domain-independent route /api/staw-pim/export/<token>.csv (no login). Useful when the storefront URL redirects - e.g. with language-path domains or redirects. The alternative URL is shown in the feed settings.

Two steps with a custom field as bridge: step 1 "Generate URL in custom field" resolves a token pattern (e.g. {mainCategoryPath}/{name}) variant- and language-accurately and writes it to the per-shop field staw_pim_canonical_<shop>. Step 2 "Generate SEO URLs" sets a Twig pattern as Shopware's native SEO template per sales channel and reindexes through Shopware - the URLs come from the custom field and survive every reindex.

Directly written seo_url rows can be overwritten by Shopware's own indexer with the default URL on the next run. The two-step system sets the pattern as Shopware's own template - Shopware then generates the URLs itself from the custom field, fresh on every reindex. The URLs are permanently stable.

Typical Twig pattern: {% if staw_url_product_detail %}{{ staw_url_product_detail|raw }}{% else %}{{ product.customFields.staw_pim_canonical_shop|raw }}{% endif %} - migrated products keep their existing URL from the custom field, new products use the field filled by step 1. The migrated field is checked strictly in the current language, without translation inheritance.

Only if you want. The "Only generate missing SEO URLs" option leaves existing ones untouched. Changed paths remain as 301 redirects ("Keep old URLs as 301" option). For a complete rebuild there's "Remove all product URLs (reset)" - deletes all URLs of the selected channels/languages incl. Shopware's global detail URLs and rebuilds fresh.

In the modal, channels are grouped by shop - each channel card with its languages as an accordion below (initially collapsed, nothing preselected). Per group "select/deselect all" with counter, plus a global "select all" button. Per channel, badges show the product count (only products actually visible in the channel) and the missing-URL count.

Both. The preview picks sample products visible in the channel whose pattern resolves - up to three real example URLs. The dry-run runs the complete process without writing - with colour-coded result cards: new = green, change = blue, skipped = grey, warning = amber, error = red.

The number of products whose pattern outputs nothing - e.g. because neither the migration field nor the canonical field is filled. Makes it immediately clear why nothing was written for those products. Safety net: if the canonical field yields an empty result during final generation, the URL falls back to the product name instead of producing an empty path.

Paths already taken (also by other routes like a category with the same slug) are cleanly skipped and reported as "path already taken elsewhere" - no duplicate-key abort. Conflicts are shown with product numbers instead of internal IDs. Important: the same URL in different shops is not a conflict - uniqueness applies per shop + language. Fix: make the pattern more unique, e.g. {mainCategoryPath}/{name}-{options}.

The tokens {options}, {properties} and {tags} deliver the respective values translated per language. A pattern like {mainCategoryPath}/{name}-{options} produces a unique URL per variant and language. Variants resolve their per-channel canonical field incl. inheritance from the parent.

Fallback chain: requested language → parent language → system. Empty or inherited translations are skipped. Applies to token and Twig generation - an English URL no longer gets a German product name just because the English translation was empty.

Umlauts and special characters are converted (ä→ae, ß→ss, "&"/spaces → separator) - also in static pattern text like a literal "für/". Slashes and dots are preserved - category paths with "/" and .html suffixes pass through unchanged. Shopware's SEO escaper would normally slugify slashes to "-" - path fields therefore automatically get |raw injected. Preview and server generation behave identically.

No, the editor explicitly warns against it - Shopware slugifies the Twig output and strips the token braces in the process. Recommendation: either a pure Twig pattern or a pure token pattern. The editor has a live Twig syntax check: invalid Twig is flagged in red and save is blocked.

Yes, for both generators: step 1 can get its own token pattern per sales channel, step 2 its own Twig pattern. Shop patterns are a list - edit via pencil, remove via trash, "Add pattern for shop" opens the editor modal. Shops without their own pattern use the default pattern.

{mainCategoryPath} uses the main category of the respective sales channel. If none is set, the fallback deterministically prefers the deepest assigned category (longest path) instead of an arbitrary one. With an empty category.path column (indexer backlog after imports), the ancestor chain is reconstructed via parent_id.

Yes. Channel counts run via set-based aggregate queries, product lists via index-friendly UNIONs instead of OR self-joins - the dialogs open without delay, generation progresses normally even with tens of thousands of products (chunked, no timeout). Progress bar with percentage.

Yes. Browser-native virtualisation via content-visibility: auto ensures smooth scrolling. Server-side filtering, lazy-loading of variants, bulk operations in batches with progress.

Three levers: (1) product writes use Shopware's async queue indexing instead of synchronous in-request indexing, (2) the write batch size was raised from 10 to 25, (3) approval and audit-log requests are batched (one batch every 600 ms or one request per 200 products instead of one per product). Configurable via bulkIndexingBehavior (queue / disable / sync).

No. Imports use queue indexing by default - only the imported products are reindexed asynchronously. The previous full-catalogue reindex after every import is gone (only runs with importIndexingMode = 'disable').

The plugin keeps a session error log: the last 50 errors are in window._stawPimErrLog (browser console). Previously silent error paths - audit flush, batch approvals, snapshot loading - now log failures. Ideal for hosting without log access.

Product data is not. Change history and snapshots are stored in your Shopware database. For the licence check the plugin queries the Stone & Water licence server with plugin name, licence key and shop domain.

The permission group "StawPim (products)" has four roles: staw_pim.viewer (view), staw_pim.editor (edit), staw_pim.creator (create) and staw_pim.deleter (delete); the Shopware permissions on the data apply as well. Individual functions such as CSV import, bulk edit or feed generator are switched for regular users in the PIM superadmin tab of the config matrix. Superadmins see everything. Details: Permissions & superadmin.

The keys are stored in the plugin configuration in your Shopware database - protected like the rest of the shop database. The admin sends AI requests to an endpoint of your shop, which forwards them server-side directly to the provider; they do not pass through Stone & Water servers. The connection test also checks the key against the provider.

In the detail view of a product in the "Changes" tab (change history). Retention and maximum entries per product are set in the config matrix in the Change history tab. Bulk edits and CSV imports are additionally available as snapshots in the Snapshots tab.

Standard license via the Shopware Store. Updates also delivered via the Store automatically.

Updates within the same major version are free. Stone & Water continuously extends the plugin with features that emerge from real maintenance workflows.

Usually 1-2 business days. For critical bugs there's a hotfix outside the regular release cycle.

Yes, please do. Via the feature request form. Most concrete wishes land in the plugin within a few weeks.

Email to pim@stoneandwater.online or via the contact form. We happily extend the documentation for questions about the docs.