Hepsiburada Integration: Listings, Orders and Returns Flow

A Hepsiburada integration connects the listing, order, shipping and return work you do in the Hepsiburada Seller Panel to your own e-commerce platform and ERP over Hepsiburada's merchant API. An order is written to your ERP as it arrives, a stock change updates the listing, and a return request is followed all the way to the warehouse shelf. What sets Hepsiburada apart from other Turkish marketplaces is that it treats the product card and the listing as two separate layers, and it moves most parcels through its own delivery network. This guide covers those differences and how an integration adapts to them.

Catalogue and listing: two separate layers

Selling an item on Hepsiburada is two jobs. The first is the product card: title, description, images, category attributes and barcode. That card sits in a shared catalogue, and everyone selling the same item uses the same card. The second job is the listing: your merchant SKU, price, stock and handling time attached to that card. The card is approved once; the listing changes every day.

This split shapes the integration directly. Card submissions go through a review; the category team checks the card and sends it back if attributes are missing. Listing updates need no approval, so stock and price changes appear almost immediately. The integration must use both channels correctly — new products through the catalogue flow, daily stock and price through the listing flow.

If the item already exists in the catalogue (a well-known brand's phone or a book, say), you do not create a new card; you attach by barcode and create only your listing. If you sell your own brand, you build the card yourself and its quality affects ranking. We explain what drives card quality in marketplace product content and quality score.

Order flow and the packaging step

Hepsiburada delivers orders line by line and waits for the seller to package them. A new order first appears as "new"; you group its lines into a package and confirm the packaging action. No shipping label is generated until that step is done. This differs from Trendyol's ready-made packages: you have more control, but a forgotten step leaves the order waiting. In practice the flow runs like this:

1. The order lands as "new"; the integration writes lines, customer and payment details to the ERP.
2. The warehouse decides which lines ship together; the integration groups them into a package and reports the packaging action to Hepsiburada.
3. A package number is created and the shipping label is printed against it.
4. The invoice is issued in the ERP and passed to Hepsiburada.
5. When the carrier collects the parcel the status becomes "in transit"; delivery moves it to "delivered".
6. If an item is unavailable, the line is cancelled with a reason code that counts against seller performance.

The packaging step is also where split shipments happen. If two of three lines ship today and one tomorrow, you open two packages. The integration tracks each as its own shipping and invoice line; the customer sees one order, you see two dispatches.

For multi-channel businesses this flow has to sit in the same list as orders from Trendyol, Amazon and your own store. How we set that up is in multi-channel order management.

HepsiJet and the shipping model

Hepsiburada's most visible shipping difference is its own delivery network, HepsiJet. In most regions orders travel with HepsiJet; for certain product groups and regions, contracted third-party carriers take over. Carrier selection is generally governed by Hepsiburada's rules rather than the seller's choice; the integration reads the carrier assigned to the package and prints the matching label.

Then there is delivery time. The handling time on the product card determines the delivery date shown to the customer. Setting a short handling time and shipping late hurts performance; setting a long one hurts conversion. The integration lets you manage handling time per product and see the remaining window in the order list. In Bulutegra's order screen, choosing the Hepsiburada tab brings the packages closest to their hand-over deadline to the top.

If you use Hepsiburada's warehouse-based fulfilment model (units shipping from a Hepsiburada facility), stock sits in two places: your warehouse and theirs. The integration has to track both and reflect the combined figure correctly to other channels — the subject of multi-warehouse stock management.

Price, campaigns and competition

On Hepsiburada, too, several sellers share one product card and one of them wins the "add to basket" button. Price, delivery time and seller score all count. The price matrix earns its keep here: it shows your Hepsiburada list and sale price separately and stops you dropping below your floor.

Campaigns work along two lines. One is the discounts you define yourself; the other is Hepsiburada's seasonal campaigns and events it asks sellers to join. Joining a campaign can change the commission model, so the price you enter should be run through a campaign calculator that accounts for VAT, commission and return risk before you commit. Campaign periods also strain stock; fast-selling items must be withdrawn from other channels in time, which is only possible with tight stock synchronisation.

Q&A, returns and payment tracking

Customer questions on the product page are routed to the seller and wait for a reply. Unanswered questions hurt conversion and seller score. Handling them in one inbox alongside phone and WhatsApp messages saves time; Bulutegra's CRM module gathers Hepsiburada questions, WhatsApp Business API messages and email in a single queue.

Returns start with the customer on Hepsiburada. A request is opened, the item is sent back to you, and you inspect and approve or reject it with a reason. On an approved return Hepsiburada refunds the customer and deducts the amount and commission from your payment. Lost items, damaged returns and returns whose commission was never credited back are the items that snag reconciliation most often.

Payments are periodic and each statement carries sales, commission, shipping charges and return deductions as separate lines. The integration matches those lines to orders; an unmatched line is flagged as a missing payout. Bulutegra tracks these records with status, ticket and note fields, and a user in the accounting role sees only this screen — closing month-end without ever logging into the seller panel.

How it works with Bulutegra

Bulutegra connects to Hepsiburada over the merchant API and setup follows four steps: Connect (merchant details entered, listings read; half a day), Match (your merchant SKU and barcode bound one-to-one to your own SKU; one to three days), Watch (shadow mode: the system only reads for one to two weeks and writes nothing while you compare orders and stock movements with your current routine), and Hand over (packaging, stock and price write access enabled for Hepsiburada). The same software ran in the founding company's own multi-channel retail operation first; forgotten packaging steps, split shipments and return matching were solved there before anyone else used it.

After handover, Hepsiburada orders are written to Nebim V3, Logo, Mikro or SAP with customer, lines, carrier and payment details. The ownership flag lets you decide per product whether Bulutegra or an external system manages the Hepsiburada listing, so there is no clash during the transition. The full setup sequence is in integration setup in 4 steps, and every module is listed in the solutions section.

To connect your Hepsiburada store to your own systems, request a demo and we will map the setup plan to your existing infrastructure together.