On 31 July 2026, VMTech DOO Beograd completed integrator certification and has operated as an official integrator for the Ananas marketplace from that date. For sellers, this is more than a formal status: they can discuss connecting a catalogue, prices, stock levels and orders with a team that understands marketplace requirements and can relate them to the business’s actual data sources.
One distinction matters from the start. The certification was completed by VMTech, not by the RichAnanas product. RichAnanas is VMTech’s B2B SaaS studio for sellers’ operational work on Ananas. It is not a marketplace product, not an exclusive partnership and not a guarantee that every listing will be approved or begin selling. Its practical purpose is to organise data and exchange processes so a team does not repeatedly transfer the same information manually between spreadsheets, an online shop, an accounting system and a seller account.
What official integrator status changes for a seller
Ananas integration rarely comes down to installing one module. One seller may keep a catalogue in WooCommerce, another in an ERP or PIM, and a third in several spreadsheets and folders of photographs. Prices may be calculated in an accounting system, stock held in a warehouse and promotions maintained by a manager in a separate file. Before sending data to the marketplace, the business needs to establish which system owns each field and which version is considered correct.
This is where integrator status is useful. The work is not only about sending data technically. It must be split into clear steps: review the source catalogue, choose an exchange method, map fields, prepare a test set, show the result before bulk publication and configure error control. A detailed description of the product and connection scenarios is available on the RichAnanas project page for Ananas sellers.
Responsibility does not disappear after a connection is enabled. The seller still needs to control the accuracy of names, descriptions, specifications, images, brands, identifiers and other product data. An integrator helps create a manageable data flow, but cannot automatically confirm content rights, the accuracy of commercial information or whether every product complies with category rules.
Why issues start before the API
Manual entry of a large catalogue is often the most visible problem. However, a bulk upload only transfers what is already present in the source database more quickly. If EANs are missing, units of measure are mixed up, specifications are written as free text, images are not linked to variations or identical products have been entered several times, direct synchronisation will not repair the structure by itself. It will only reveal accumulated contradictions faster.
EAN acts as a stable product identifier and is used alongside SKU and internal codes when listings are found, matched and processed. For some records, the number may be missing, entered incorrectly or assigned to the wrong variation. Before the first full synchronisation, it is useful to identify products without EANs, duplicates, invalid values and cases where a single code has been assigned to several different items. Automated validation reduces manual searching, but the final decision on disputed data remains with the seller.
The next layer is mandatory category attributes. Size, material, colour, a technical characteristic or package contents may have different names in an ERP, WooCommerce and a supplier spreadsheet. Matching field labels is not enough: the correspondence of values also needs to be defined. For example, an internal value such as “graphite” may need to be converted to an accepted colour value, while product weight must be distinguished from package weight. This correspondence is called mapping and is completed before bulk transmission.
Images and descriptions require a separate review. A listing may have a primary image, a gallery and images for variations, but in the source system these are often kept in one folder without a stable link to an SKU. A description may contain administrative or extraneous HTML markup, contact details, an outdated price or supplier text whose usage rights have not been confirmed. Catalogue preparation therefore includes more than a technical export: it also needs rules for data cleaning, choosing the primary image, forming titles and handling missing values.
Core principle: the first goal of an integration is not to send the entire catalogue as quickly as possible, but to obtain a predictable result on a controlled sample.
Three connection paths: Connector, XML/YML or API
There is no universal method. The choice depends on where source data resides, how frequently prices and stock levels change, who manages products and whether two-way order exchange is required. A file export is sufficient in some cases; in others, connecting an online shop is more sensible. A complex architecture requires API integration with an ERP, PIM or custom system.
RichAnanas Connector for WooCommerce
When a seller already maintains products in WooCommerce, RichAnanas Connector can be a natural entry point. It is a publicly available plugin for WordPress and WooCommerce that securely connects the shop to RichAnanas Studio. This route allows the existing catalogue to remain the basis rather than being built again in another interface.
A plugin does not remove the need to verify data. A shop may use non-standard attributes, additional pricing plugins, multiple warehouses, custom variation logic or fields created by a theme developer. Before exchange is enabled, the team needs to determine where price and saleable stock quantity come from, how variations are identified and which extensions affect product data. If the structure has been substantially altered, the standard connection may require additional mapping or development.
XML or YML for regular file exports
File-based exchange is appropriate when a seller’s system can regularly generate a structured feed but has no direct API, or where an API is not justified by the current scope. A file can contain product identifiers, names, specifications, prices, stock levels and image links. The data is then checked and transferred through the agreed scenario.
The strength of this approach is a relatively simple architecture. Its limitation is dependence on the schedule and contents of the file. If a feed is generated several times a day, changes made between exports will not reach the marketplace immediately. A file alone also does not resolve two-way work with orders and operational statuses. XML/YML is therefore often suitable for catalogue, price and stock data, while other processes can be connected through a separate channel where required.
API for ERP, PIM and custom systems
API integration is needed when exchange must be deeper and closer to the current state of the business. Technically, interfaces can work with product records and their statuses, use identifiers such as SKU and EAN, add or edit items in bulk, and support separate scenarios around orders and packing. The exact set of operations must not be assumed in advance: it is verified for the account, seller role and selected business process.
An API normally requires more design work. Authentication, field and status mapping, protection against duplicate sending, request logs, a retry queue and error notifications all need to be configured. If an external system is temporarily unavailable, the integration should not silently lose a record or create duplicates. For such work, VMTech designs integrations between business systems using APIs, webhooks, file exchange and databases.
A combined approach is also normal. A catalogue may arrive from a PIM through a file, operational stock from an ERP through an API, while WooCommerce remains a separate sales channel. What matters is not the number of connections but common data ownership rules. If three systems change a price at the same time, even a technically sound integration will continually overwrite values.
What is worth synchronising
The scope of exchange is defined after an audit. RichAnanas is intended to work with products, images, listing content, prices, stock levels and orders, but the actual scope depends on the seller’s source system and available interfaces. There is no reason to enable every direction simply because it exists. It can be safer to start with the catalogue and stock levels, then connect orders once identifiers and statuses have stabilised.
- Catalogue: SKU, EAN, title, brand, description, category, variations, specifications, package dimensions and other fields needed for the selected product group.
- Images: the primary image, gallery and links between photographs and specific product variations.
- Prices: the base price, current commercial value and rounding rules where they exist in the seller’s system.
- Stock levels: saleable quantity with the selected warehouse, reservations and update frequency taken into account.
- Promotions and discounts: validity periods and values where the selected scope supports this scenario and it is correctly configured in the source.
- Orders: receipt, further processing and related operational actions within the available connection functions.
- Statuses and errors: processing results, reasons for rejection or failure, and the ability to repeat an action after data is corrected.
Readable statuses are especially important. A message saying “synchronisation error” tells a manager very little. A working interface should, where possible, show which product is affected, at what stage processing stopped, which field needs attention and whether sending can be repeated. Responses from an external system will not always be equally detailed, so part of the diagnostics is based on the integration’s own exchange log.
For prices and stock levels, an acceptable delay must be set in advance. If a seller changes the range several times a month, periodic exchange may be sufficient. If stock changes rapidly across several channels, infrequent exports increase the risk of discrepancies. Identical values every millisecond cannot be promised: schedules, queues, system availability and reservation rules affect the result. The realistic objective is to set a clear frequency, record the last successful update time and warn of a failure.
How to run the first synchronisation without an uncontrolled import
Concern about the first full upload is justified. A bulk operation without prior mapping can create duplicates, send incorrect stock levels or produce hundreds of similar errors that then need manual review. A safe rollout is therefore phased rather than based on the idea of “connect it and synchronise everything”.
- Audit the sources. Identify systems, spreadsheets and responsible employees. Assign a source of truth for every field: where EAN is stored, where price comes from and which warehouse determines saleable stock quantity.
- Select the connection path. Compare Connector, XML/YML, API and a combined arrangement, considering catalogue size, change frequency, order requirements and source-system capabilities.
- Map the data. Match categories, attributes, units of measure, variations, identifiers and statuses. Send ambiguous values for a manual decision.
- Check quality. Create lists of missing EANs, required fields, broken image links, duplicate SKUs and other blocking issues.
- Preview. Let the seller see what data will be sent and how fields will be transformed before the bulk operation begins.
- Use a test sample. Process a small but representative group first: a simple product, a product with variations, an item with several images and a record with borderline data.
- Run the first controlled synchronisation. Increase volume gradually, monitor responses, correct repeated causes of errors and only then proceed to the remaining catalogue.
- Observe after launch. Review logs, delays, discrepancies and records that have not been updated for longer than expected.
A rollback path is useful as well. If new price logic produces an incorrect result, it should be clear how to stop sending, restore previous rules and identify affected items. This requires mapping versions, a change log and access restrictions: not every user should be able to start a full synchronisation.
Risks and limits that one integration cannot remove
An integration does not guarantee acceptance of every listing. A product may require mandatory attributes, a correct EAN, different images or clarification of its content. Marketplace checks and publication decisions remain a separate stage. RichAnanas helps make operational work visible and organised, but does not replace marketplace requirements or promise automatic approval.
A complete absence of errors cannot be promised either. Catalogues, access tokens, data formats, shop plugins and a seller’s internal processes change. Reliability comes not from saying that errors will never occur, but from control: logs, retries, notifications, separate test and production environments, a fallback scenario and documented responsibilities.
Another risk is an incorrectly selected source of truth. If an employee changes a price in the seller account and an ERP sends the old value again an hour later, the issue is not exchange speed but governance rules. Before launch, the team should agree where each data type may be edited and what happens when a conflict occurs.
Finally, integration does not replace operational discipline. New products still need to be created correctly, images prepared, specifications checked and errors investigated. Automation removes repeated data transfer and makes process status visible, but a high-quality source catalogue remains the business’s responsibility.
Who RichAnanas suits, and when a manual account is enough
RichAnanas is worth considering for sellers with a substantial catalogue, regular price and stock changes, several data sources or a team tired of repeated entry. It is also appropriate when WooCommerce, an ERP, a PIM or a custom system must be part of one process and statuses and errors need to be visible in one operational environment.
A manual seller account may be enough where the range is small, products are added rarely, prices barely change, stock is easy to control and one person processes orders. In that case, a full API integration can add more cost and maintenance than benefit. Starting manually, documenting the process and returning to automation as volume grows is a normal business decision.
There is also an intermediate option: automate only the most painful part. For example, send the catalogue and stock through XML/YML while processing orders manually for a time. Or connect WooCommerce through Connector without enabling bulk sending until EANs and attributes have been reviewed. A phased approach reduces risk and makes it possible to assess the outcome through the team’s actual work.
Where to begin with Ananas integration
The first discussion should begin with a map of the current process, not with the question “what does an API cost?”. Where is the catalogue located? Which system controls price? Are there product variations? How is saleable stock calculated? Who corrects errors? How many records change every day? The answers show whether Connector, file exchange, API or a combination is needed.
Review the RichAnanas project to understand the purpose of the operational studio and the connection options. Then send VMTech a short integration brief with the current system, catalogue format, approximate data composition and the processes creating the most manual work. On that basis, project boundaries can be defined, an audit prepared and a controlled first-synchronisation path selected without promises that cannot be verified in advance.
