Integration pitfalls: connecting SellerHub to GIS MT for product marking

On the first run of the SellerHub integration with GIS MT, the DataMatrix codes had already appeared, but some product items were still not linked. An unpleasant situation: the code exists, the seller is waiting for marking, but on the platform it cannot be safely handed off for processing.

The task looked compact: connect GIS MT for mandatory product marking, generate DataMatrix codes, link them to product items, and show the marking status. In SellerHub this affects 300+ sellers, so manual checks like “what’s going on with the code?” quickly turn into a queue of errors. On top of that, penalties for marking violations are increasing, and the cost of an incorrect status is higher than the cost of an extra state in the data model.

Let’s go through the pitfalls we hit in this integration.

Pitfall 1. Treating DataMatrix as a separate entity without a link to the product

The first mistake is to treat DataMatrix as a set of strings that can be generated in advance and later distributed to items somehow. For a storefront or a report, that still seems acceptable. For marking, it doesn’t.

In SellerHub, a product item lives its own life: the seller maintains the catalog, changes product cards, and works with different product groups. If the code is stored separately from the item, it is easy to end up in a gray area in the UI: the code seems to have been created, but which product it belongs to is only clear from external context. And external context is the first thing to be lost.

We tied the flow to the following chain:

• product item in SellerHub;
• request to GIS MT;
• received DataMatrix;
• marking status for this specific item.

If the link does not go through, the code is not shown as ready. This is an important constraint: successful generation does not yet mean the seller can use the code without risk. This was exactly the point of debate — whether to treat the response from GIS MT as the final point. It turned out that the final point for SellerHub comes later: when the code is linked to the correct product item and the status does not conflict with the current state.

Pitfall 2. Making the marking status a boolean

The second mistake is obvious: add a marked: true/false field and call it done. But integration with GIS MT is not limited to two states.

There is the moment when the request is sent. There is the moment when the DataMatrix is received. There is a separate moment when the code is linked to the product item. There are cases where the status needs to be checked in an external system rather than trusted from a local cache.

If you show the seller “done” immediately after generation, you can end up with a mismatch: everything is green in SellerHub, but the marking process has not actually finished yet. For a platform with 300+ sellers, this is not a minor rough edge; it is a source of large-scale manual investigation.

So we made the status part of the process, not a decorative field. SellerHub stores and updates the marking state, and the UI relies not on the mere existence of a DataMatrix, but on the state of the “item — code — GIS MT response” link.

Pitfall 3. Processing a batch as if it were always homogeneous

The third pitfall is batch processing. In marking, it is tempting to take a batch of products, send requests, and get back a neat list of codes. In reality, a single batch can contain items in different states: one is ready, another is missing data, a third is waiting for a status update.

If the whole batch fails because of one item, the seller sees a generic error instead of the specific cause. If you silently skip the error, things get even worse: some products are marked, some are not, and in the UI it all looks the same.

We split the processing down to the product-item level. An error on one item does not block the others, but it remains visible in the context of that item. That makes it easier to retry the operation, check the status, and avoid mixing a technical error with the business state of marking.

What we managed to lock down in the process

The main benefit of the integration is not that SellerHub learned to receive DataMatrix codes. That is only one step. A working scheme emerged only after we linked generation, association with the product item, and status tracking into a single flow.

For the seller, it looks simpler: less manual copying, fewer places where the code and the product can be mixed up. For the platform, there are fewer implicit states that later have to be dug out of logs and message threads.

The next practical step in integrations like this is to look carefully not at the happy path, but at the intermediate states: the code is created but not linked; it is linked but the status is not yet confirmed; the status has been updated, but the item in the catalog has already changed.