Integrating your store with Kasta: feed, API and orders

As a base, yes: Kasta's XML instructions say plainly that files with any other structure are not accepted, and the Rozetka feed structure is the exception. That does not make it ready, though. Clothing and footwear need separate Color and Size parameters, the brand has to come from Kasta's reference list, and the article number is marked mandatory in Kasta's field table. In our own measurement of 21 public feeds of Ukrainian stores (5 September 2026, 88,991 products), only one passed Rozetka's own mandatory fields without violations.

That is Kasta's rule: if there is no stock tag and available=true, HUB sets the quantity to 10. A product you have zero of goes on sale, and the cancellation later falls on you. In the same measurement of 21 feeds, six had no stock_quantity or quantity_in_stock tag in a single item. So we pass stock explicitly in every item and flag the items without it during the review.

The feed, if your range changes slowly and orders are few: prices and stock from it arrive roughly once an hour, or every 30 minutes in a separate mode. The API, when that is not enough or you want to process orders in your own system: stock goes out right after a change, and orders and statuses travel both ways. A mix also happens: content via the feed, stock via the API. In that case we switch off price and stock updates in the feed settings, otherwise the two sources overwrite each other. New products from the feed go through Kasta's general queue — roughly up to ±6 hours, and once every 4 hours if the date in the feed header does not change. So we update the generation date on every build.

HUB treats it as a new product and sends it to moderation again. The supplier's article number, brand, color and size are fixed to the card on first upload and are not updated; to change them, the product is deleted and uploaded again. So we check the card key before the first upload — afterwards a fix costs another round of moderation for everything it touched.

We pass stock via the API right after it changes, without waiting for the feed cycle. We confirm Kasta orders with the ConfirmedBySupplier status as soon as they land in your system: until confirmation Kasta itself deducts the ordered quantity from the stock you sent, and if your warehouse has already written it off, the item is deducted twice and disappears from sale before it has actually run out. The honest limit: a window between a sale and the update always remains; it can be narrowed but not removed.

Yes, through the API: an order list with a change cursor, up to 100 per request, orders available from 1 January 2023. In the other direction, we send statuses in the sequence Kasta requires: for example, a waybill is registered only after the “packed” status, and a cancellation only with one of the reasons from its list. Statuses have limits, including 300 requests per minute and no more than 10 per order per 10 minutes, so requests go through a queue.

Right, we have not worked with Kasta, and the page does not hide it. We have built stores with the Rozetka marketplace connected (case below), feeds and exports for Prom are described on the Prom integration page, and we analyzed 21 public feeds separately. The description of Kasta on this page was checked against its supplier documentation on 12 September 2026. What protects you: a fixed scope in the contract, a free review before the contract and a 30-day warranty from the date the acceptance act is signed.

Kasta shows the sale price to the buyer, and the royalty percentage has to be built into it from the start — its documentation says so. The strikethrough price cannot be lower than the sale price, otherwise the upload returns an error. HUB calculates the supplier price itself. You know the percentage from your contract; we write a rule in the generator so the Kasta price is not kept in a separate spreadsheet.

After the free 2–3-day review: feed only — 4–9 working days (feed 2–5, first upload and mapping 1–3, handover 1). Feed plus the stock API and orders — 9–19 working days. We will be more precise after the review: what shifts the timeline most is products with a size grid, where variants have to be split into fields.