Marketplace Integration Guide: Trendyol, Hepsiburada and Amazon

Marketplace integration connects your own systems to marketplaces such as Trendyol, Hepsiburada, Amazon, n11 and Çiçeksepeti, so products, stock, prices and orders move between them automatically. You set up a product once; stock and prices update on every channel by themselves; orders land in a single list; invoices and ERP records are created without anyone retyping them. This guide is written for sellers in Turkey. It covers what an integration actually does, why running channels by hand stops working as you grow, how to handle stock sync and channel pricing, where invoicing and the ERP fit in, how to choose between an off-the-shelf integrator and a custom build, and how to set one up step by step.

What does a marketplace integration cover?

Every marketplace has its own seller API, category tree, required product attributes and order statuses. They do similar jobs with different rules. The integration layer translates your single product and order model into whatever each channel expects. A typical set of flows looks like this:

You don't need every flow on day one. But deciding early which ones are automated and which stay manual saves you from surprises later.

How the channels differ

The notes below describe the general shape of each channel. Marketplaces update their services from time to time, so always check the details against their current seller documentation.

Trendyol integration

Products are identified by barcode and go through Trendyol's approval before they can be sold. Product creation, stock and price updates are accepted as batch requests, and you query the result separately. Orders arrive as shipment packages, and Trendyol expects the seller to report some status changes through the API, such as when picking starts.

Hepsiburada integration

Hepsiburada keeps the product catalogue separate from the listing that carries your price and stock. If the product is already in the catalogue, you only open your own listing; if not, you create the product first and it goes to review. The integration needs to handle both steps.

Amazon integration

Seller operations on Amazon run through the Selling Partner API (SP-API). Access requires a developer registration in Seller Central and authorising your application. Products match on ASIN: if the product is already in the catalogue you add an offer to it, otherwise you create a new product, which usually requires a GTIN such as an EAN. Access to buyers' personal data, such as names and addresses, needs additional authorisation and falls under Amazon's data protection rules. With FBA, where Amazon ships from its own warehouse, that stock is tracked separately from your own.

n11 and Çiçeksepeti

Both offer sellers services for products, stock, prices and orders, each with its own category and attribute structure. If the core data model is right, adding another channel to the same integration layer is far easier than starting over.

Why managing channels by hand breaks down

With one marketplace and a few dozen products, the seller panel is enough. Trouble starts when products, channels and order volume grow together:

• Stock is updated panel by panel; forget one, and you sell something you don't have.
• A price changes on one channel while another keeps selling at the old price.
• Every order is retyped into the accounting software or ERP, so wrong product codes and amounts creep in.
• Invoices are issued and uploaded to orders one at a time.
• Return requests and customer questions pile up in separate panels and response times slip.
• During campaigns the team spends its time entering data instead of selling.

Hiring more people doesn't fix this for long, because the root cause is keeping the same data in several places by hand. The real job of an integration is to give every piece of data a single source of truth.

Stock sync and overselling

Marketplace inventory sync exists to stop the same physical item from selling on two channels. If your last unit sells on Trendyol and Hepsiburada within a short time of each other, one order has to be cancelled. Seller-caused cancellations hurt your store's performance and, depending on the marketplace's rules, can lead to penalties. A few principles work together to reduce the risk:

• One source of stock. The ERP, a warehouse system or the integration layer can own stock, but only one of them. Nobody edits stock in marketplace panels; every change flows out from that source. What you send to channels is sellable stock, not what's on the shelf: physical stock minus orders not yet shipped and any buffer you hold back.
• Event-driven updates. When an order arrives from any channel, sellable stock drops immediately and the new figure goes to the other channels. Goods received, a sale on your own site or an approved return trigger an update in the same way. New orders are picked up either by polling each marketplace at short intervals or through the notification services it offers; the sooner an order reaches you, the smaller the window in which the same item can sell elsewhere. Scheduled syncs are fine for product details, but stock needs updates triggered by each change. Because some marketplaces queue updates and report the outcome later, the integration should confirm each update was actually applied. Respect each marketplace's API rate limits and batch updates where you can.
• Safety stock and allocation. For low-stock items, holding back a buffer or reserving certain products for certain channels reduces the risk of overselling. How much to hold back is a commercial decision; the integration applies it consistently on every update.
• Stock held by the marketplace. With models like Amazon FBA, stock in the marketplace's warehouse is tracked apart from yours. The integration must keep the two separate, while reports show them side by side.

Price rules per channel

Selling a product at the same price everywhere rarely makes sense. Commission rates vary by marketplace and category, and shipping and service fees, campaign participation and competing sellers all affect the right price. On Trendyol, Hepsiburada and Amazon, where several sellers can share one product page, price is one of the deciding factors in which offer gets featured. Price rules usually follow this structure:

• Base price: the list price in your ERP, or a value calculated from cost.
• Channel formula: a multiplier or mark-up that covers commission, shipping and service fees.
• Floor: the integration never sends a channel a price below the margin you set. Campaigns you join from a marketplace's own panel can bypass that check, so make those decisions against the same floor.
• Rounding: a shared rule so prices look consistent on each channel.
• Campaign windows: prices with a start and end date that revert on their own.

Log which rule changed each price and who triggered it, so that when an unexpected price shows up on a channel, you can find the reason quickly.

Orders, shipping labels, returns and questions

Orders from every marketplace come into one list. Status changes such as picking, invoiced and shipped are reported back in the steps each marketplace expects; with the marketplace's contracted carriers, the carrier updates some of them. An order can sometimes be split into several packages or partly cancelled, so the order model should support that from the start. Track every order by its marketplace order number, so a dropped connection never imports the same order twice.

When you ship with the marketplace's contracted carriers, the shipping barcode and tracking number are usually generated on the marketplace side; the integration pulls them in bulk, the warehouse prints labels from one screen and tracking is recorded on the order. If you use your own carrier agreement, the tracking number flows the other way, from you to the marketplace.

Return requests come from the marketplace. When the item reaches the warehouse it is inspected, approved if acceptable and put back into stock. Stock should not go up automatically before inspection, so damaged or incomplete returns never become sellable again. The document used to book a return in your accounts depends on the buyer, so settle that rule together with your invoicing flow. Customer questions from product pages also collect in separate panels; pulling them into one inbox helps the team reply quickly, which matters because marketplaces may take response time into account when rating sellers.

Invoicing marketplace orders: e-Fatura and e-Arşiv

For a marketplace sale in Turkey, the seller invoices the buyer, and the marketplace separately invoices the seller for its commission and service fees. If you use e-Fatura and e-Arşiv, the document you issue depends on the buyer:

• If the buyer is registered in the e-Fatura system, you issue an e-Fatura.
• For consumers and buyers who are not registered, you issue an e-Arşiv Fatura.

When an order carries corporate billing details, the integration checks the tax number against GİB's list of registered e-Fatura users through your e-invoice provider (özel entegratör) and picks the right document type. The invoice is built from the order data, issued through your provider and, where the marketplace asks for it, attached to the order as a link or a file. An e-Arşiv invoice for an online sale also carries extra details such as the website address, payment and shipping information, which the integration fills in from the order. How campaign discounts appear on the invoice can depend on who funds the discount, so settle that rule with your accountant and build it into the integration.

To be clear about our role: BernSoftware is not an özel entegratör. We build the software that connects your chosen provider's services to your store, marketplace and ERP flows. Our guide to e-invoice integration in Turkey covers document types, taxpayer lookup and UBL-TR in more depth, and our e-invoice integration page explains what we deliver.

Posting marketplace orders to your ERP

Retyping marketplace orders into the accounting system is where many sellers lose the most time. Whether you run Logo, Mikro, Netsis or SAP, settle these questions before orders can flow into the ERP automatically:

• Customer accounts: one summary account per marketplace, or a separate account per buyer? How are buyers who request a corporate invoice handled?
• Product matching: the link between the marketplace barcode or seller SKU and the ERP stock code, including colour and size for variants.
• Document type: does the order become a sales order or go straight to an invoice, and is the invoice issued by the ERP or by the integration layer?
• Shipping and fees: which accounts receive the shipping charged to buyers and the commission and service invoices the marketplace sends you.
• Payout reconciliation: what the marketplace pays you is the sales total minus commission, shipping, returns and other deductions. Matching these per order against the marketplace's payout and statement reports makes month-end close easier.

Whether reads and writes should go through the ERP's own services or a middleware layer is covered in our article on ERP integration methods. The same rule applies here: create orders and invoices through the ERP's official services, not by writing straight into its tables and bypassing its business logic.

Off-the-shelf integrator or custom integration?

There are ready-made integration tools that manage several marketplaces from one panel, and for many sellers they are the right place to start. A custom integration makes sense when your business rules don't fit the standard flows. A fair comparison:

A third option is common in practice: an off-the-shelf integrator handles the channel connections, and a custom bridge between it and your ERP applies your own rules. If your own online store is also a sales channel, its platform choice feeds into this decision too; we cover that in building an e-commerce site: platform or custom development. Running marketplace orders through the same stock and order backend as your e-commerce site makes it easier to stay consistent across channels.

How to set up marketplace integration, step by step

1. Clean your master data. Every variant needs a unique SKU and barcode, with names, descriptions and images kept in one place.
2. Decide where stock and prices live. Pick which system has the final say on each.
3. Request API access early. Each marketplace issues integration credentials through your seller account, and Amazon also requires a developer registration. Approval steps can affect the timeline, so start on day one.
4. Map categories and attributes. Mapping colour, size, material and similar fields to each marketplace's category structure once is what makes bulk uploads possible.
5. Write down your price rules. Agree channel formulas, floors and campaign rules with sales and finance.
6. Test orders, invoices and ERP posting end to end. Use the marketplace's test environment if it has one and a test company in the ERP; never experiment on live systems.
7. Protect buyer data. Names, addresses and phone numbers that arrive with orders are personal data under KVKK, Turkey's data protection law. Limit access by role and keep the data only as long as you need it.
8. Start with one channel and a limited range. Add the other marketplaces once the process runs smoothly on the first.
9. Set up monitoring and alerts. A failed order transfer, a rejected product or an unapplied stock update should never disappear quietly; it should show on a dashboard and reach the right person.

Marketplace APIs change over time: new required fields appear and old endpoints are retired. Going live is not the end of the job but the start of something that needs regular maintenance.

BernSoftware builds integrations that sit between channels such as Trendyol, Hepsiburada, Amazon, n11 and Çiçeksepeti and your ERP and e-invoicing setup. We work with the APIs these marketplaces provide to sellers, and if you already use an off-the-shelf integrator, we can build the bridge that connects it to your ERP. After launch, our monthly support packages keep up with API changes. See our marketplace integration page, plan your project or get in touch to scope it together.