I have connected five retailers with Shopify as the leading system to Tradebyte. This case study shows how such integrations are built for fashion retailers, which pitfalls are typical and what has worked in practice.
Starting point
The five retailers wanted to reach new marketplaces through Tradebyte. Their ranges comprise between 1,000 and 10,000 variants. In most projects I start with Tradebyte right at onboarding and begin directly with the TBCat format, so manual data maintenance never comes into existence in the first place.
Without automation, the product data would have to be maintained by hand for every marketplace. That is laborious and error-prone, especially at the start of a season or when a new marketplace is added.
Task
Shopify was to be the leading system: data is maintained only there, and Tradebyte and the connected marketplaces are supplied automatically.
Implementation
For each retailer I developed a custom interface that covers the complete cycle:
- Product data, variants, prices and stock go from Shopify to Tradebyte.
- Orders come from Tradebyte into the shop.
- Shipping confirmations, cancellations and returns are reported back automatically. One of the retailers deliberately continues to handle returns themselves.
Data is exchanged via Tradebyte’s XML formats, either through the SFTP access or directly through the API. The TBCat format from Tradebyte is used for the product data. Orders and stock are reconciled hourly. The interval is configurable per retailer: many marketplaces cannot process the data more often anyway, so a tighter interval would only create load without any benefit.
Where the data comes from
The retailers bring very different shops. The interface therefore picks up each piece of information where it is maintained anyway and combines it for the transfer to Tradebyte:
| Data | Source | Notes |
|---|---|---|
| Products and variants | Shopify product data | Configured variant options |
| Prices | Shopify product data | also in several currencies |
| Stock | Shopify product data | total stock or only selected locations |
| Basic information | Shopify product data | category, weight, size, country of origin, HS code |
| Further information | Shopify metafields | for example for bullet points and attributes |
| Orders | Tradebyte | are created in the shop automatically |
| Shipping confirmations, cancellations, returns | Shopify orders | are sent back to Tradebyte automatically |
Data is therefore maintained in one place, and the interface distributes it to Tradebyte and the connected marketplaces.
Extensible without interface changes
In Shopify, metafields are used for much of this information, and they can hold any kind of information. Shopify names them following the scheme namespace.key.
If you use this naming consistently, the interface can be extended with additional fields without any development. For example, all metafields in the namespace bulletpoint are automatically included in the bullet points of the product data, and new attributes are added to Tradebyte automatically when named accordingly. With the next export of the product data, the field appears in Tradebyte right away.
State stays in Shopify
My interfaces work as close to Shopify as possible and store the information needed for processing and transfer directly there. Successfully processed fulfillments, cancellations and returns are noted as tags on the order. The status is therefore immediately visible in the shop, and dependency on an external database is kept as low as possible.
Pitfall: mandatory fields without information
Every marketplace has its own requirements for product data, and Tradebyte passes them on to the retailers. Among them are often mandatory fields for information that simply does not apply to the retailer’s range or that they do not record for their articles: lining, insulation, pocket details, closure type, fan merchandise and the like.
The usual approach is to create a separate source field for each of these fields and maintain it with the same value for all articles. That bloats the data model and increases maintenance effort. Here is a small excerpt of such fields:
| Mandatory field (AboutYou) | Value |
|---|---|
| Lining | Unlined |
| Insulation | Other / without thermal insulation |
| Fit | Regular |
| Strap type | Regular strap |
| Fan merchandise | No |
| Pocket type, closure type, textile technology | not specified |
A single generic “dummy” field is enough here, simply added to every article. From this field, all of these mandatory fields can be mapped to a fixed default value. Where a sensible default exists, it is used (for example “Unlined” or “Regular”), otherwise “not specified”. Where the retailer records real data, it is of course mapped directly.
For AboutYou alone, this saved one of my clients from creating and maintaining 21 metafields.
Result
Orders are created without manual effort. Stock levels are current. Manual CSV maintenance, with its workload and sources of error, is no longer needed.
Further services around Tradebyte
Besides the interface, I take on tasks around setup and operation on request:
Switching from PANDA to TBCat
Are you still working with PANDA CSV files at Tradebyte? Switching after the start is possible too: I convert your product data to TBCat so that it comes automatically from your leading system. Maintaining the CSV files by hand is laborious and error-prone. A classic mistake: Excel shortens long EAN numbers to just a few digits, so articles can no longer be matched on the marketplace. I have already carried out this switch for one retailer.
Mapping, marketplace setup and support
Depending on your needs, I work in Tradebyte (TB.One) myself, for example on mapping and marketplace setup, or I only take care of support and adjustments to the interface. That way you do not have to learn the Tradebyte configuration yourself.
Your project
Do you want to connect your shop to Tradebyte or replace an existing connection? Find out more under Tradebyte Integration or contact me directly via the contact form: just describe your project briefly.