Turkey has a large and concentrated e-commerce market, and most of its volume flows through a small number of marketplaces. For a seller expanding into the country, or a platform building integrations on behalf of sellers, that means a short list of APIs to learn — and a set of assumptions from other markets that will not carry over.
This guide covers what actually differs, aimed at developers who have integrated marketplaces elsewhere and want to know what is new here.
Quick comparison
| Marketplace | Position | Auth style | Integration weight |
|---|---|---|---|
| Trendyol | Largest reach | Credentials tied to seller account | Heaviest, most documented |
| Hepsiburada | Strong in electronics and home | Credentials tied to merchant account | Moderate |
| N11 | Established, broad catalogue | Credentials tied to store account | Moderate |
These are seller APIs, not open APIs
The first thing to understand is that none of this is publicly accessible data. You cannot browse Trendyol's catalogue programmatically as an anonymous developer the way you might with a public product API.
Trendyol, Hepsiburada and N11 all issue credentials against an approved seller account. The commercial relationship comes first: you register as a seller, get approved, and only then receive API access.
This inverts the usual order of work. In most integrations you prototype against the API and then handle the business side. Here the business side gates everything, and it is not a same-day process. Build your timeline around that.
It also means you cannot meaningfully evaluate these APIs before onboarding. Read the documentation, but expect to discover the real behaviour only once you have credentials.
The architecture that works
Teams integrating more than one Turkish marketplace converge on the same shape, and arriving at it early saves a rewrite.
Keep one internal product model that represents your catalogue as your business understands it. Then write a separate adapter per marketplace that translates between your model and theirs. Do not try to build a single generic integration that treats all three the same — their category taxonomies, required attributes, image rules and order states differ enough that the abstraction leaks immediately.
The adapter boundary should also own each marketplace's identifiers. Your product has your SKU; each marketplace has its own product identifier, and the mapping between them belongs in a table you control, not scattered through business logic.
Category and attribute mapping is the real work
If you take one thing from this article: budget most of your integration time for category and attribute mapping, not for authentication or order handling.
Each marketplace maintains its own category tree, and each category has its own mandatory and optional attributes. A shoe listing needs different fields than a laptop listing. Submit a product with a missing or invalid required attribute and it is rejected, often with a message that tells you which field failed but not what value it expected.
Three practices make this tractable.
Fetch and cache the category and attribute definitions from each marketplace rather than hard-coding them. They change, and a hard-coded taxonomy silently rots.
Store your category mapping as data, not code. A mapping table that operations staff can update without a deploy is worth building early, because mapping decisions are commercial judgements as much as technical ones.
Validate against the marketplace's attribute rules before submitting, and surface failures with the product and field named. A rejection queue that says "17 products failed" is not actionable; one that says "product X, brand attribute missing" is.
Stock and price synchronisation
Stock is the highest-risk path in the whole integration, and it deserves more engineering attention than anything else here.
Overselling — accepting an order for inventory you no longer have — is penalised by marketplaces and damages seller ratings, which in turn affects visibility. When the same inventory is listed across three marketplaces plus your own site, a sale in one place must reduce availability everywhere else quickly.
Two design decisions follow. First, treat stock updates as a separate, high-priority queue from catalogue updates. A backlog of product description changes must never delay a stock decrement. Second, consider holding a buffer — listing slightly less than your true stock — so that propagation delay does not translate directly into oversells. This is a commercial decision as much as a technical one, but it is the standard mitigation.
Price synchronisation is lower risk but has its own trap: campaign and discount mechanics differ per marketplace, and a price you set may not be the price displayed. Do not assume your submitted price is authoritative for what the customer sees; read back what the marketplace reports.
Order lifecycle differences
Order states are where cross-marketplace assumptions break most quietly. Each platform models the journey from placement to delivery with its own set of statuses and its own rules about which transitions are permitted.
The failure mode is not a crash. It is a status your code does not recognise, silently mapped to a default, leading to an order that sits in the wrong state in your system while the marketplace expects action. By the time anyone notices, the shipping deadline has passed.
Guard against this explicitly. Map known statuses deliberately, and when an unknown status arrives, log it loudly and route the order to human review rather than guessing. Marketplaces add and rename statuses over time.
Shipping deadlines are also stricter here than sellers from some markets expect, and missing them affects seller performance metrics. If your integration handles fulfilment, surface the deadline as a first-class field rather than something buried in the order payload.
For the shipping side of this — carrier integrations, tracking and label generation — see our guide to Turkish shipping and logistics APIs.
Invoicing and compliance
Turkey operates a mandatory electronic invoicing system, and marketplace sales fall within it. This is not something your marketplace integration handles for you.
For most sellers, the practical path is a separate integration with an accredited e-invoicing provider, connected to the order flow so that invoices are issued against completed orders. This is a distinct project with its own compliance requirements.
Consumer protection rules — return windows, disclosure obligations, delivery commitments — also apply and are enforced. These are legal questions rather than technical ones, and they should be resolved with qualified local advice before launch rather than discovered afterwards.
Testing and rollout
Test environment availability differs across these marketplaces, and where sandboxes exist they do not always reflect production behaviour precisely. Plan for a period of careful production testing with a small number of real listings.
A rollout that works: start with a handful of products in one category on one marketplace. Verify the full loop — listing appears correctly, stock decrements on sale, order arrives in your system, status transitions work, invoice is issued. Only then widen the category range, then add the second marketplace.
Teams that integrate all three simultaneously and push their full catalogue on day one spend the following weeks untangling which marketplace rejected what and why.
Also build observability before you need it. Log every request and response at the adapter boundary with the product or order identifier attached. When a seller asks why a specific product is not visible, you want to answer from logs rather than guesswork.
Documentation references in this article point to each marketplace's official developer portal. Marketplace APIs change frequently and terms differ by seller agreement, so treat the official portals as authoritative and verify current behaviour during integration.
Related API Deposu entries
Sources
Frequently Asked Questions
›Can I access these APIs without being a registered seller?
No. These are seller APIs, not public data APIs. Credentials are issued against an approved seller account on each marketplace, so commercial onboarding comes before any technical work.
›Is one integration enough for all three marketplaces?
No. Each marketplace has its own authentication, category taxonomy, attribute requirements and order lifecycle. A shared internal product model with per-marketplace adapters is the workable architecture; a single generic integration is not.
›How quickly do stock updates need to propagate?
Faster than most teams plan for. Overselling — accepting an order for stock you no longer have — carries penalties and damages seller ratings. Treat stock synchronisation as the highest-priority path in your integration, ahead of catalogue enrichment.
›What is the biggest source of integration failures?
Category and attribute mapping. Each marketplace has its own taxonomy with mandatory attributes that differ by category, and product submissions are rejected when required attributes are missing or invalid. This consumes far more time than authentication or order handling.
›Do I need a Turkish legal entity?
Selling on Turkish marketplaces involves tax, invoicing and consumer protection obligations under Turkish law. These are commercial and legal questions that precede the technical integration, and they should be resolved with qualified local advice rather than inferred from API documentation.