Product data transmission from your system to Tradebyte

Product data transmission

from your system to TB.One

Definition

A “catalogue” is the XML file containing all product-related data. We named our XML format for that purpose “TB.Cat” – Tradebyte catalogue.
A catalogue contains
– your merchant information (i.e. Company name, TB merchant ID)
– your category tree
– a list of your manufacturers
– a list of all your products – by “products” we at TB.One understand all relevant meta-information of an item from title, manufacturer, description to media like pictures or PDFs and various attributes like material, age group, gender, target group or season. Example: White Adidas T-Shirt.
– a product contains one or more “articles”, which represent the single SKU with price, delivery time, stock. Example: Size M or L of the White Adidas T-Shirt.

Full and Delta

You can either give us your complete catalogue master in one file (full load) or only a delta of the changed products (delta load). Especially with large data volumes, it is recommended to send a full load only once a day or week and to transfer e.g. hourly or single product updates in the moment of a change via delta load.

Requirements

First of all, you need access to a TB.One account. You can get this from Tradebyte or the owner of the TB.One account. In TB.One the access data for the TB.One REST API can be generated. You need these to send your data to TB.One.
Of course you need a leading system in which your article data is maintained up-to-date. From this system you transfer your data to TB.One. This can be an ERP system, a PIM, a shop system or any other system for managing article data.

Best Practices

1. This part shows a collection of our top recommendations in regards of interplay.

Handling of media Titel
Check out the media guides of the individual channels. A good orientation is Zalando, so you can list almost everywhere.
Media should always be maintained at SKU level, unless an image describes a product in several versions. However, this cannot be interpreted by every shop, so it is generally not advisable to do so.
Image formats should be uniform so that they can scale in the respective frameworks of the shops. We prefer JPEG.
Provide at least for images – front view, back view, details.

2. Categories

You can just send the categorization you use in your PIM/Erp/Shop and later map it to channels categories using the TB.One cluster feature.

3. There are also rules of the game to make sure everything works fine. Please make sure to follow them.

The connection to an active TB.One requires the agreement of the respective account owner.
Always use the current versions of the XML schemas.

4. API handling

REST calls may only be made sequentially and not more than once at the same time.
The corresponding timestamp must be set for delta calls. Identical timestamps are counted as full load. A maximum of 6 full loads can be retrieved every 4 hours.

5. Error codes

Error codes 4xx/5xx must be recognized and handled.
4xx errors must not be followed by another recall.
For 5xx, wait at least 10 minutes, and do not exceed a number of 5 retrievals.

6. Processing data

Validation of the XML against the latest XSD version is required before processing the data.
Only complete XML files may be processed.

7. Delta Logic

Price changes affect Delta exports, inventory changes do not.
Product data always contain whole products in the delta, not just the changes to them.
If properties for the previous data feed are no longer contained, they are considered deleted.

8. Deactivation of products

The deactivation of products implicitly affects the export. Only products and articles that are contained in the full load are considered active. There is no explicit deactivation. There is a config-option in TB.One that needs to be turned on for this to work.