Trendyol API: how to get Trendyol product prices, sellers and reviews as JSON

$0.67–$1.50 / 1,000 credits on monthly billing, or $0.33–$0.75 / 1,000 credits paid yearly (−50%). Credits roll over and never expire, and every engine draws from the same balance. Failed calls are free except verified SHEIN NOT_FOUND on product/detail and price (4 credits). Credits are not requests: measured across 1,124 catalog actions on 2026-08-25, 67% cost one credit, 18% cost two and 5% cost three.

Not stated as a platform policy. Apify's monetisation docs only recommend to developers that they "don't bill users for what they can't access, for example if a run gets aborted" — whether a given publisher honours that is up to the publisher. Two concrete things we can state. First, the leading actor charges no Actor Start fee, so a run that saves no records costs nothing; several of its rivals charge $0.005, and one charges $0.08, to start a run whether or not it returns anything. Second, Apify's own API publishes this actor's last-30-day outcomes: of 10,197 runs, 9,198 succeeded, 981 timed out, 18 were aborted and 0 failed. Its store page headlines a 100% success rate, and on its own terms that is correct, because nothing outright failed — but roughly one run in ten ended on the clock, and both numbers are worth knowing before you plan a large backfill. On our side a failed or blocked call is not charged, except verified SHEIN NOT_FOUND on product/detail and price (4 credits), and an invalid content_id was refused in 29.1 milliseconds with zero upstream calls on 2026-09-16.

The reason a plain script returns nothing: Trendyol's public search page answered 0 of 8 datacenter requests

Measured on 2026-06-21 from two exit countries. A straightforward server-side GET of Trendyol's own search results page was refused on 8 of 8 attempts — this is the wall that sends people looking for an API in the first place, and you can reproduce it from any cloud host in about a minute. It is also why requests plus BeautifulSoup, which works fine on a laptop, returns an empty list the moment it is deployed. We absorb that server-side and do not publish how. In the same session all 15 actions then in the engine answered correctly in 0.8 to 2.5 seconds, and 46 varied requests fired in parallel — 20 searches, 8 filter lookups, 5 category pages, 5 seller catalogues, 3 seller profiles, 3 product details and 2 review pages — came back 46 of 46 in 4.3 seconds.

Against us: six of every twenty-four search rows repeat on every page you ask for

Pages 1, 2, 10 and 30 of a single query each returned 24 rows, and the same six product ids appeared on all four. Nothing on those rows marks them as promoted. Walking ten pages with max_pages returned 183 distinct products rather than 240, which is exactly this effect after de-duplication. Two more things on the same page shape go against us: list_price and list_price_value were filled on only 3 of 24 rows, so you cannot compute a discount rate from search alone, and meta.total_count reported 81,187 matches — Trendyol's own figure for the result set, not the number of rows paging will hand you. De-duplicate on content_id, read discounts from product/detail, and treat the reported total as a headline rather than a plan.

Against us: product detail published no list price while search published one for the same product

On content_id 1127950824, search returned a 74.999 TL crossed-out list price and product/detail returned null for the same product on the same day. The cause was that the buy-box field being read as the list price is in practice the selected seller's own price, and it usually equals the price paid, so the strike test never fired while the real crossed-out figure sat in a different field. Fixed on 2026-09-06, and the anti-fabrication guard was deliberately left alone: a list price is published only when it is genuinely higher than the price actually paid, so an undiscounted product still returns null rather than an invented discount. Related and still true — discount_pct is a rounded integer. A product at 15,099 lira against a 15,149 lira list price reports 0. The two price numbers are exact; compute the rate yourself when a fraction of a percent matters.

Against us: a dead route was reported to customers as a dead product, on every single product

product/similar answered NOT_FOUND "endpoint/content not found" for every product, including our own declared golden case. The upstream recommendation route had moved, and because a 404 was being mapped straight to NOT_FOUND, a retired route surfaced as a missing product — the worst kind of error, because it looks like an answer. A 15-path sweep over the same service returned the identical application-level 404 on all 15, so the fix came from capturing what the page itself calls rather than from more guessing. After the repair, two independent sets of 23 products across 23 categories with disjoint ids: 23 of 23 and 23 of 23 returned ok with rows, 920 rows in total, with content_id, title, brand, url, price, rating, comment_count, image and category filled on 100% of rows and list_price on 37.6% and 40.7% — correctly sparse, because undiscounted products return null. Six of six round-trips from similar to product/detail agreed on the price string exactly.

All 14 actions answered on one key, cache-free, between 0.642 and 3.293 seconds

Public acceptance on an owner key, every call a cache miss: product/questions 0.642 s, product/reviews 0.687 s, category/products 0.887 s, search 0.925 s (36 de-duplicated rows), suggest 0.926 s, search/filters 1.224 s, seller/products 1.595 s, product/coupons 1.850 s, product/variants 2.066 s, product/detail 2.189 s at 441,883 bytes, product/offers 2.356 s, seller/info 2.472 s, product/description 3.293 s. product/offers returned 36 published seller offers for content_id 458904548 priced from 9.999 TL to 21.529,01 TL — a 2.15x spread on one listing — with the buy-box winner flagged, and a competing seller scoring 9.3 asking 10.960 TL against the winner's 9.999 TL. An invalid content_id was refused in 29.1 milliseconds with zero upstream calls and zero bytes. Behind it: 26 unit and regression tests and 19 of 19 valid staged calls. This is a bounded functional sample, not a throughput or SLA claim.

Honest limit on the offers block: only the buy-box seller publishes stock and item number

In the same 36-offer response, seller_id, seller_name, seller_score, price, price_value, currency, campaign and free_cargo were present on every row, but in_stock and item_number came back null on every competitor and non-null only on the buy-box winner. That is what Trendyol publishes, so we return null rather than inferring availability we cannot see. Two related separations worth knowing: a product with a single seller returns other_offers as an empty array with other_offers_count 0 — Trendyol publishes no competing-merchant block at all in that case, and the empty array is the true answer rather than a failure; and coupons come back as anonymous visibility with eligibility_checked false, never subtracted from the price, because what a logged-out visitor can see is not what a given account is actually entitled to.

The seller upload tree is 3,361 categories, and one of them wants 38 attributes

Measured on 2026-09-22 against Trendyol's public integration endpoints, which need no login: 11 of 11 category calls returned 200 from an ordinary datacenter host in 0.3 to 1 second. The tree holds 3,361 categories; the query "ayakkabı" matched 51 leaf categories; and category 411, Casual Ayakkabı, carries 38 attributes of which 9 are required before a listing can be created. A category id that does not exist answers a clean NOT_FOUND. Worth knowing that this is the one part of the engine that overlaps with Trendyol's own seller API — it tells you the shape of the upload template, but it does not upload anything, because writing to a store is what the Partner API is for.