Building Partner Galleries in Brand Cloud and Multilingual MCP: Icecat Release Notes 261

Release 261 completes the partner gallery story. Release 260 delivered partner-specific galleries to every delivery channel; this release gives the people who maintain them the place to build them, with a separate gallery per taxonomy, an image order of its own for every locale, and a gallery section that stays workable while all of it is done. Icecat MCP now accepts a locale on each individual request and reports the locales an account is authorized to use, so an AI agent can work through several markets in a single conversation. Distributors receive a Skipped Products Report that lists only real gaps in the Icecat catalog, and brands can store their guarantee conditions under one agreed name that retailers can place next to the EU guarantee label. We’ve also made a round of behind-the-scenes improvements.

For additional details, please refer to the previous Icecat Release Notes.

Product Gallery

This release includes two Product Gallery updates. First, Icecat Brand Cloud now lets editors and brand users build the galleries previous releases started delivering: a separate gallery per taxonomy, with its own image order for each locale. Second, product images can now be fetched from SFTP links, so suppliers who publish on SFTP are imported the same way as those publishing on FTP.

Taxonomy Galleries and Per-Locale Image Order in Icecat Brand Cloud

Release 260 completed the delivery side: every channel now delivers the gallery that applies to each account and locale. This release completes the editing side. The gallery section on the product page in Icecat Brand Cloud now shows all of a product’s galleries on one screen, and you can set the image order per locale.

Taxonomy galleries

• A complete gallery per taxonomy. A product can have a separate gallery for each taxonomy, alongside the Icecat gallery. Each one is a full gallery: its own images, its own order and its own local galleries.
• Added from the product page. A taxonomy gallery is created from the gallery section and opens immediately, so you can add images to it.
• All galleries on one screen. Each taxonomy gallery is placed below the Icecat gallery as its own block.
• Empty galleries take no space. A taxonomy gallery that holds no images is not shown on the page.
• Deleted only after a confirmation. The confirmation names the gallery and shows how many images it contains.
• Private images stay in the Icecat gallery. A taxonomy gallery cannot hold a private image. In the Icecat gallery, it works as before.

An image order per locale

• A local gallery shows what one locale receives. Opening a locale shows everything that is exported for it: the international images and that locale’s own.
• The order is set by dragging. A single image or a selection of several can be dragged into place. Two arrows under each card do the same.
• A local order and the general order are independent. Changing the general order leaves a locale that has an order of its own untouched. A locale that still follows the general order moves with it.
• Back to the general order at any time. A locale can be returned to the general order after confirmation.
• Only used locales are shown. A locale appears on the product page once it has an order of its own; one that follows the general order takes no space. The list shows only the locales the gallery has something to show.

Working in the gallery section

• One set of group actions. Add, deactivate, activate, delete and put a locale back on the general order serve the whole section, and stay on screen while the page is scrolled.
• The actions say what they will touch. The row names the selection and where it sits – the gallery, and the locale when the selection is inside a local gallery. A selection never spans two galleries.
• Whole sections can be selected. Each section heading has a checkbox that selects every image in it; a card checkbox selects the image and all its locales, as before.
• A deactivated image says so. The card now carries the icon, not only a faded look.

Adding images

• Choose the galleries. The dialog now asks which galleries the batch goes into. The Icecat gallery is preselected, and it offers only galleries that already exist on the product.
• Drop files onto the dialog. Files can be dragged from the computer straight onto the dialog, next to the existing way of choosing them..

Brand users

• Locale rights are unchanged. The brand role remains the only role limited by locale.
• Only the locales brand users work with are shown. A locale a brand user may not work with does not appear anywhere in the gallery: not among the local galleries, not on a card, not in a dialog.
• A group action does what it can. It applies to the locales the user may change and reports the rest as skipped, instead of refusing the whole action.
• Every group action except delete. Brand users can add, activate, deactivate and put a locale back on the general order. Delete remains an editor action.
• A profile with no locale is told so. Instead of an empty gallery, the user is asked to agree with their Account Manager which locales they need.

Access

Access rights are unchanged. Everyone who can work with a gallery today keeps exactly the same rights, and the new galleries, local galleries and actions follow those same rules.

Images from SFTP Links

Product images can now be fetched from sftp:// addresses, wherever an image is added by link in Icecat Brand Cloud. A supplier who publishes images on an SFTP server is now integrated the same way as one publishing on FTP.

• The same limits apply. Everything that governs fetching an image today (the accepted formats, the size and dimension limits, how long a fetch may take and how many may run at once) applies to SFTP unchanged.
• Nothing else changed. HTTP, HTTPS, FTP and FTPS links keep working exactly as they do today.

Icecat MCP: Content in Every Locale the Account Holds

This release includes one update to the Icecat MCP server. A locale can now be named on each individual request, and a new tool reports the locales an account is authorised to use. An AI agent can now work across several markets in one conversation, without changing its configuration or starting over.

A Locale on Every Request

Until now, the locale was fixed in the connection, so working in Italian, then Spanish, then Dutch meant editing the configuration and starting the task again each time, losing the context built up in the conversation. Every product content tool now takes an optional locale that applies to that request alone.

• The connection is not touched. Naming a locale on a request changes nothing about the connection and affects no other request.
• Several markets in one conversation. A request in it_IT, then one in es_ES, then one in nl_NL are each answered in the locale they name, with nothing reconfigured or restarted in between.
• One locale at a time. A request names a single locale. Naming more than one is refused rather than served in part, because authorization applies per locale.
• The locale is written as language and country. For example it_IT, nl_BE or pt_BR, covering the eighty locales Icecat holds. Case, spacing and a hyphen instead of an underscore are all understood.
• Content figures stay global. The product analytics tool carries no locale, because it counts downloads across all of Icecat.

A Tool That Lists the Locales of an Account

A partner can see the locales their account covers in their Icecat account, but an AI agent or a direct integration can’t: it would have to guess a locale or find out by being refused. Icecat MCP now has a twentieth tool, account_locales.

• It needs no input. Locales belong to the account, so no product has to be named.
• It returns only authorized locales. The answer is the set the account may use, not the full Icecat list with some entries marked unavailable.
• It covers both subscriptions. An Open Icecat account receives all eighty locales. A Full Icecat account receives the locales its subscription includes, which may be a single one.
• It is meant to be called first. An assistant can read the list before a request so it never guesses, and an integration can read it once while being built.

Clear Reasons When a Locale Cannot Be Served

When a locale cannot be served, the AI assistant receives a message that names the locale, the reason, and where to find a locale that works:

• Not a recognized locale. The value sent is not one of the eighty Icecat locales, and the message points to account_locales.
• Not available to this account. The locale exists, but the account is not authorized for it. The message asks for it on the profile page on icecat.biz first, and names the Icecat Account Manager as the next step.
• More than one locale named. The request is repeated once per locale required.
• Temporarily undetermined. The system could not read the account’s locales at that moment, and the message asks the user to try again shortly.

A refused locale is never reported as a missing product or an invalid product code, so a partner is never left believing a product is absent from Icecat when only the locale was refused.

Compatibility and Access

• Existing connections are unaffected. A request that names no locale behaves exactly as before: the locale set in the MCP configuration is used, and where none is set, English.
• The configured locale keeps its current form. Only the locale named on a request uses the language and country form; the locale carried by a connection stays as it is.
• Tools are unchanged otherwise. Every product content tool keeps its name, its existing inputs and its output fields.
• Locale and product access are separate. Which products Icecat MCP serves is decided exactly as before: Channel Partner accounts only, with brand authorizations, product verticals and release dates applying unchanged.

Skipped Products Report

Distributors send their catalog to Icecat as a product feed. The Skipped Products Report lists the products from that feed that were not imported and names the reason for each: a summary by reason in the email, and row by row in an attached CSV. That gives a distributor predictability. They know which of their products Icecat won’t cover, and why, instead of discovering it later. The value of the report therefore rests entirely on its accuracy: a line a partner cannot act on costs them the time of looking into it.

This release includes two changes to the report, both serving that same purpose: every line should reflect a real gap in the Icecat catalog.

Products Icecat Already Holds Are Not Reported

A feed row that carries a product code, a brand and a GTIN was reported as skipped whenever its brand was not yet mapped, without the GTIN in that row being taken into account. Icecat now checks it first.

• The GTIN decides whether the row is reported. Before a row is written to the report because its brand is not mapped, Icecat checks whether a GTIN in that row identifies a product it already holds. If it does, the row is left out of the report.
• The totals follow the report. A row left out is counted neither in Total skipped products nor in any Summary by skip reason line, so the figures describe exactly the rows in the CSV. When no rows remain, the import is reported as having zero skipped products and the “no products were skipped” email is sent without an attachment.
• An unconfirmed GTIN counts. It is enough that an Icecat product carries the GTIN; it does not have to be confirmed.
• Placeholder values do not count. A GTIN whose digits are all the same, or which has fewer than five digits once leading zeros are removed, is treated as if the row carried no GTIN, and the row is reported as before.
• Rows without a usable GTIN are unaffected. A row that carries no GTIN, or a malformed one, is reported exactly as today.

A Brand That Is in the Feed but Not Yet Mapped

• Reported under “Brand mapping is missing”. A row whose brand is present in the feed but not yet mapped by Icecat is summarised under this line, whichever identifiers the row carries.
• “Brand name is missing” means what it says. That line is now used only for rows that genuinely carry no brand, so a partner reading it knows to look at the feed.
• The CSV tells the two cases apart. brand_not_mapped_no_gtin marks a row with no GTIN, and the new brand_not_mapped_gtin_not_found marks a row whose GTIN is not known to Icecat. Both are counted together in the single “Brand mapping is missing” line of the email summary.

What Stays the Same

• The import is untouched. How feed rows are matched, attached to Icecat products and turned into new products is unchanged.
• The report itself is unchanged. The CSV columns and their order, the reason labels, the email subject and body, the recipients, the distributors covered by the report and the moment of delivery all stay as they are.

Guarantee Conditions as an Other Digital Asset

When a brand offers a guarantee longer than the statutory period, it must publish the guarantee conditions with it. Until now, those conditions could only be stored under a name typed by hand, leaving every brand and retailer with different wording for the same document. Icecat Brand Cloud now offers Guarantee Conditions as a predefined short description of “other digital asset”, so the document arrives under one agreed name that a retailer can place next to the EU guarantee label.

The guarantee conditions are a document in their own right: the brand’s full guarantee terms, not a summary. They are separate from the EU GARAN Label and from the Warranty note feature on the data-sheet, and a product can carry all of them at once.

Other Developments in Release 261: Behind-the-Scenes Improvements

Release 261 also includes a round of mostly invisible work. It keeps the Product Gallery fast while editors build the new galleries, makes search and product pages on icecat.biz noticeably quicker, prepares Icecat Live for delivery through a CDN, and continues the work on development tooling and platform security.

Product Gallery Maintenance

• Product pages open without waiting for the gallery. The product page in Icecat Brand Cloud no longer holds a user while it collects the gallery date, so opening products stays quick even during heavy image processing.
• Image changes reach delivery without waiting. Whether an image is delivered, and whether it is private, is held in a record behind each image. When that record must be recalculated, the recalculation now runs ahead of large routine maintenance passes, so a user’s change takes effect right away. 
• Steadier processing of large image batches. The image processing fleet now stays at a stable size, so a large supplier batch no longer forces work to restart from the beginning.
• Gallery access decided in one place. One service now makes every decision about who can see or change an image, so the rules cannot drift apart.
• Reasons to Buy images checked. We checked the images used in Reasons to Buy content across the catalog, and corrected links that didn’t resolve.

Search and Pages on icecat.biz

• A much faster filter panel. The counts beside brands, categories, families, series, and features are now calculated for the current search instead of the whole catalog. The panel shows exactly the same values as before and loads several times faster.
• Fewer lookups per results page. Product links on a results page and in the search dropdown are now collected in one lookup instead of one per product.
• A quicker search dropdown. Autocomplete now prepares only the products it actually shows, so suggestions appear faster while typing.
• Lighter pages on mobile. Category images on the home page are loaded only when they are shown, shared icon sprites were trimmed to the icons actually in use, and page styles were reviewed, to improve how quickly pages become usable on a phone.
• Brand statistics pages are indexed correctly. Those pages now return the response search engines expect, so Google Search Console no longer reports them as Soft 404s.

Icecat Live

• Live through a CDN, one step further. A pre-production zone is now in place, so you can check every kind of Live answer through the CDN, including how it serves content when the origin is unavailable, without touching production.

Icecat Brand Cloud and Imports

• The Brand API accepts an API token. You can now use the brand information endpoint with an API token, the same way as the rest of API v2.
• Clearer messages from the Push API. When a value such as a policy isn’t accepted, the message now quotes the value exactly as received and lists the accepted ones, so you can spot a stray space at a glance.
• Feed encoding detection. A feed in UTF-8 connected with Encoding set to “Auto” is now read as UTF-8, with special characters intact.
• Importing definitions. Importing descriptions now also creates descriptions for features or categories that had none in any language, and the results screen names every row that wasn’t imported, with the reason.

Summary

Release 261 puts the partner gallery into the hands of the people who maintain it. A product can hold a gallery per taxonomy, every locale can carry an image order of its own. Icecat MCP now serves every locale an account holds without a change of configuration, so one conversation with an AI agent can cover several markets instead of being broken into one per language. Distributors spend their time on the products Icecat genuinely lacks rather than on ones it already holds, and brands can publish their guarantee conditions under a name retailers recognise and show next to the EU guarantee label. Together with faster search on icecat.biz and continued work on platform reliability and security, these changes help partners rely on Icecat content in every channel they use. Want to know how taxonomy galleries or per-request locales affect your integration? Contact the Icecat team for more information.