Google Shopping feeds for Ticimax, T-Soft, ikas and IdeaSoft stores

Merchants running on Ticimax, T-Soft, ikas or IdeaSoft have the same goal as everyone else — a file Merchant Center accepts — but they reach it from a different starting point. These platforms are strong at running a Turkish shop and less concerned with the details of Google's specification. Here is what actually needs doing on each, and the handful of data problems that account for most rejected products.

Two routes out of every platform

The XML export. Every one of these platforms can publish a product XML — often marketed as an "XML entegrasyon" or marketplace export. It is a URL you can hand to any feed tool, it needs no credentials, and it is available on every price plan. The catch is that the fields are whatever the template gives you, and the template can change without warning.

The API. Each platform also has an admin API:

• Ticimax — a web service, opened with an authorisation code (Yetki Kodu) you generate in the panel.
• T-Soft — a REST API, with a web service user and password you create in the panel.
• ikas — an admin API over GraphQL, using the client ID and secret of a private app.
• IdeaSoft — an admin API where you create an API app and approve access once (OAuth2).

The API route gives you variants, stock and images as structured data instead of whatever the XML template happened to include, and it does not break when someone edits the export template. It costs one set-up step: creating read-only credentials in the shop's panel.

Either route works. The decision is about how much the export already gives you, and how much you mind it changing under you.

The five problems that cost you products

1. Comma decimals

Turkish exports write prices as 1.299,90 — a full stop for thousands, a comma for decimals. Google needs 1299.90 TRY. A feed tool that assumes English number formatting will read that as one thousand two hundred ninety-nine, or fail outright.

Set the number format explicitly for the source rather than hoping it is detected. The same applies to weights and dimensions.

2. KDV

Many exports contain the net price, or both net and gross under names that are not obvious (fiyat, satisFiyati, kdvDahilFiyat). Google compares the feed price with the price on the landing page, and the landing page shows the price with KDV.

Send the price with KDV. If the export only has the net figure, add the rate with a rule — price × 1.20, rounded — and make sure the rate matches the product's category, since not everything is 20%.

3. Turkish characters

If product names arrive as Ãœrÿn or KoÅŸu, the export is not being read as UTF-8. Sometimes the file is genuinely in another encoding; sometimes it is UTF-8 with the wrong declaration. Either way, set the encoding for the source explicitly, and check a product with ı, ş, ğ, İ in its name before you publish.

The same characters matter in the other direction: İstanbul lower-cased carelessly becomes i̇stanbul. If a rule changes case, it must know the language.

4. Relative links and images

Exports frequently contain /urun/kosu-ayakkabisi or /images/1042.jpg instead of full addresses. Google needs absolute URLs beginning with https://. Make the store's own address the base and prepend it — once, as a rule, for every product.

While you are there, check what the image URL actually returns. Thumbnails are a common trap: the export links to a 200-pixel preview while the product page shows a large image. Google is raising its minimum to 500 × 500 pixels with enforcement starting 31 January 2027.

5. Variants in one row

Some exports list a product once with Beden: 40, 41, 42 in a field. Google wants each size as its own item, with its own id, availability and price, grouped by item_group_id.

If the export cannot produce one row per variant, that is the strongest argument for using the platform's API, where variants come through as separate records with their own stock.

What a working set-up looks like

For a typical Turkish shop advertising in Türkiye:

1. Connect the source — the XML export URL, or the platform's API with read-only credentials.
2. Set encoding and number format explicitly: UTF-8, comma decimal separator.
3. Map the fields to the standard schema: id, title, description, link, image, price, availability, brand, GTIN where it exists, item_group_id for variants.
4. Add rules: make links and images absolute; add KDV if prices are net; build titles as {brand} {title} – {color}, {size}; map your categories to Google's taxonomy with a lookup table.
5. Filter: leave out products with no image, no price, or zero stock.
6. Publish the Google feed, register its URL in Merchant Center, and set the fetch to daily or more often.
7. Rebuild on a schedule that matches how fast your stock moves — hourly is realistic for a busy shop.

Add a second feed for Meta from the same catalog when you need it; the work above is not repeated.

Selling abroad

Shops advertising outside Türkiye hit two extra issues. Currency: each target country needs prices in the currency that country's visitors see on your site, which usually means one feed per market. Shipping and returns: configured in Merchant Center rather than in the feed, but they must be true for the country you are targeting, or products are disapproved for reasons that look unrelated to the data.

None of this is exotic. It is the same specification everyone else follows, plus four local details — decimals, KDV, encoding and variants — that are easy to fix once and tiresome to fix repeatedly. Fix them in the rules that build the feed, and the next export from the shop cannot undo the work.

Frequently asked questions