plentymarkets monitoring from storefront to REST API
XICTRAQ checks the homepage, subpages, checkout and REST interface of your plentyShop LTS from the outside and reports errors such as those that appear after a plugin set is deployed. The cookieless tracker captures page views, product views and JavaScript errors on its own, while you pass the purchase through a dataLayer entry or the JavaScript API.
Check these paths first
- Uptime monitoringHomepage with keyword monitoring
/ - Uptime monitoringBasket page as a subpage of its own
/basket - Browser monitoringFrom item page to checkout without ordering
/checkout - Browser monitoringLogin with a test customer
/login - API monitoringREST response with the data field
/rest/io/session - SEO monitoringBlocking of all crawlers and changes
/robots.txt
What is left to monitor in a cloud shop
According to the vendor, plentymarkets is a cloud-based solution, and since November 2024 it has been called PlentyONE. What visitors get to see in the shop still depends to a good extent on you: on the plugin set, the theme, individual plugins, ShopBuilder content and embedded third-party scripts. plentymarkets applies changes to plugins and theme when the plugin set is deployed, and whether storefront, basket and checkout still work afterwards only becomes visible from the outside.
XICTRAQ therefore spreads the checks across several modules: uptime monitoring with subpages such as /basket and keyword monitoring, browser checks for the path from item page to checkout, API checks for the REST interface under /rest/io/, which plentyShop LTS uses to load basket and session, and script integrity for embedded third-party scripts.
The paths on this page apply to plentyShop LTS in its default setup. If a category is assigned via ShopBuilder to a route such as basket or login, that category’s address applies; enter it instead. The new PlentyONE shop, which the vendor presents as the successor to plentyShop LTS, is monitored by XICTRAQ with the same modules, but the tracker has no dedicated detection for it.
With an empty basket, plentyShop LTS redirects /checkout to the homepage. Check the checkout with a browser check that adds an item first and stops before the order is submitted, and sign in with a dedicated test customer rather than a real customer account.
What typically breaks in plentymarkets shops
Errors after a plugin set is deployed
plentymarkets applies changes to plugins and to plentyShop LTS when the plugin set is deployed; the vendor recommends checking in the preview of a copy of the plugin set, before activating it, whether they cause errors with the theme in use. Plugins included via Git from a branch are brought up to date automatically by the deployment process. Besides the homepage, uptime monitoring checks subpages such as /basket and /login, reports an outage per path with its status code and keeps the timing split into DNS, connection, TLS and first byte in the history.
Add-to-basket button or checkout stops responding
plentyShop LTS implements the add-to-basket button, quantity selection and checkout as Vue components in the browser. A JavaScript error from a plugin or the theme can break them even though every page answers with HTTP 200. A browser check adds an item to the basket, proceeds to checkout and captures a screenshot of the failed step. In addition, the tracker reports JavaScript errors from real visits as far as they reach the browser’s error event; errors that Vue catches inside a component and only writes to the console are not seen. Errors seen repeatedly can trigger an alert.
REST interface returns errors
In the standard template, plentyShop LTS loads session and basket through the REST interface under /rest/io/session after each page has loaded, and its responses contain the fields data and events. API monitoring calls the endpoint and checks status code, response time and, via JSON path, whether the data field is present. That way an error also shows up that the storefront would only reveal after the page has loaded.
Page responds, but content is missing
A homepage can answer with HTTP 200 and still no longer show what should be there, for example after a change to content or layout. Keyword monitoring searches the delivered HTML for terms you define, such as a category name or your company name, and raises an alert for missing terms. It checks the HTML as the server delivers it; content that is only loaded later in the browser is not seen by this check.
Modified third-party script in the shop
Payment, chat or marketing scripts from other providers load in the shop, often on basket and checkout pages too. For a verified website, script integrity records the SHA-256 hash of external scripts during a scan, fetches them again regularly and reports deviations. If you also scan /basket, the check covers the scripts loaded there as well. Scripts served from the shop’s own domain are not part of this check.
robots.txt blocks all crawlers
If the robots.txt contains “Disallow: /”, search engines that respect it are no longer allowed to crawl the shop, while it keeps running normally for visitors. XICTRAQ reads the robots.txt of the monitored website, raises a critical alert for “Disallow: /” and records changes to the file, including added and removed lines, in the changelog.
How XICTRAQ recognises plentymarkets
Technology detection during a scan reads the page HTML and lists plentymarkets as the shop system. Uptime, browser and API checks, maintenance detection and the tracker work independently of it.
- The scan recognises plentymarkets by the word “plentymarkets” or “plenty.shop” in the HTML. plentyShop LTS outputs a generator meta tag containing “plentymarkets” in its standard template.
- The daily technology detection of the monitoring agent does not list plentymarkets as a shop system; from the generator meta tag it only takes over the value “plentymarkets”. It leaves the scan’s shop system result in place, because there it only clears values it can detect itself.
- XICTRAQ only writes a “CMS changed” changelog entry when the detected CMS changes. XICTRAQ lists plentymarkets as a shop system, so a move to or from plentymarkets does not appear as such an entry.
- XICTRAQ recognises maintenance independently of the shop system by a 503 response that ends up on /maintenance after redirects or carries a common maintenance notice such as “undergoing maintenance” or “Wartungsarbeiten”. A 503 without such a notice remains an incident.
- If a scan gets no page content back at all, the previous detection stays in place instead of being recorded as “not plentymarkets”. If bot protection serves the scan a block page instead, the scan evaluates that page, and plentymarkets is missing until the next scan of the real page.
What the tracker captures in plentymarkets
The tracker recognises plentyShop LTS by window.ceresStore or by the #app-data block from the standard template. It sets no cookies and, in standard tracking, stores nothing in browser storage.
Captured by the tracker on its own
- Page views with referrer, UTM parameters and device type, plus load times and Web Vitals such as LCP, CLS and INP.
- Product views on the item page with name, price and currency from the structured data of the standard template, plus an identifier from SKU, GTIN-13 or MPN where the item has one.
- Clicks on the plentyShop LTS add-to-basket button, for example on the item page.
- The start of checkout as soon as a page under /checkout is opened.
- JavaScript errors from real visits that reach the browser’s error event, with message and, where the browser provides them, file and line.
Not captured automatically
- Order completion and revenue: the plentyShop LTS order confirmation carries none of the markers the tracker looks for. The purchase is only captured if a plugin places it as a purchase entry with an amount in a dataLayer or you pass it yourself.
- The basket state as well as removals and quantity changes in the basket.
- Reliable add-to-basket clicks: with the standard template the tracker reports the quantity as 1, and name and price do not reliably come from the item added. Clicks on the plus and minus buttons of the quantity selector next to it also count as add-to-basket clicks, as do clicks after which the shop adds nothing, for example because no variant has been selected yet.
- Signed-in customers: the standard template outputs no customer ID the tracker could read.
- Cancellations and refunds. There is no automatic event for them.
- Orders created without a storefront page, for example through connected marketplaces or in the plentymarkets back end.
- For the new PlentyONE shop, the successor to plentyShop LTS, there is no dedicated detection. The tracker counts page views there even when navigating without a reload, while you pass shop events through the JavaScript API.
Pass missing values through the JavaScript API: xictraq.revenue(amount, "EUR", orderNumber, { tax, shipping }) on the order confirmation page, xictraq.identify(customerId, { group }) for signed-in customers and xictraq.refund(orderNumber, amount, "EUR") for refunds.
The right modules for plentymarkets
Frequently asked questions
Does XICTRAQ capture plentyShop LTS orders automatically?
Not from the standard template. The tracker captures product views, add-to-basket clicks on the item page and the start of checkout on its own, but not the order completion, because the order confirmation carries none of the markers it looks for. If a plugin places the purchase as a purchase entry with an amount in a dataLayer, the tracker picks it up; otherwise, call xictraq.revenue() yourself on the order confirmation page.
What is left to monitor when plentymarkets runs in the cloud?
According to the vendor, plentymarkets is a cloud-based solution. What visitors get to see still depends on your plugin set, the theme, ShopBuilder content and embedded scripts as well. XICTRAQ therefore checks from the outside whether homepage, subpages, checkout and REST interface answer as expected and whether embedded third-party scripts change.
Can a browser check walk through the plentyShop LTS checkout?
Yes. A browser check can open pages, click, fill in forms, wait for elements and verify text, URLs or status codes. It has to add an item first, because with an empty basket /checkout redirects to the homepage, and it has to sign in or enter an email address as a guest, otherwise it ends up on the login page. Use a dedicated test customer for this and let the check stop before the order is submitted.
Which plentyShop LTS REST endpoint suits an API check?
An obvious candidate is /rest/io/session, which the storefront calls in the standard template after each page has loaded to fetch session and basket. The interface responses contain the fields data and events. In API monitoring you check status code, response time and, via JSON path, whether data is present; further read-only endpoints such as /rest/io/basket are set up the same way.
Does XICTRAQ recognise that my shop runs on plentymarkets?
The scan recognises plentymarkets by the word “plentymarkets” or “plenty.shop” in the HTML and lists it as the shop system; plentyShop LTS outputs a generator meta tag with this name in its standard template. The daily technology detection of the monitoring agent does not list plentymarkets as a shop system but leaves the scan result in place. Uptime, browser and API checks do not depend on this detection.
What does XICTRAQ notice after a plugin set is deployed?
If a monitored page answers with an error afterwards, uptime monitoring reports the outage per path with its status code. If a defined term is missing from the homepage, keyword monitoring raises an alert, and a browser check reports a step that no longer passes, with a screenshot. A change that none of these checks touches goes unnoticed, however, because XICTRAQ does not read the plugin set itself.