Marketplace Integration Management: Trendyol, Hepsiburada, Amazon

An Excel sheet on Trendyol, a separate panel on Hepsiburada, another screen on Amazon, an entirely different flow on N11. Most businesses selling across multiple marketplaces in Turkey still manage stock, price, and orders by hand, channel by channel. The result is three kinds of loss at once: selling the last unit on two marketplaces at the same time and having to cancel (over-sell), forgetting to update a campaign price on one channel and selling at a loss, and noticing an order too late, missing the marketplace's delivery window (SLA), and taking a penalty or score hit. As revenue grows, these three compound into operational debt. When we talk about marketplace integration, this is exactly the first thing we touch: building an orchestration layer that pushes stock, price, and orders from a single centre, event-driven and idempotent, to every channel, and that automates product listing.

Our Approach

On a marketplace integration project our first decision is always to set a single source of truth. The root of multi-channel chaos is that each marketplace keeps its own stock and price separately and none of them is aware of the others. So we'd consolidate stock, price, and product master data on a central PIM and PostgreSQL, and position the marketplaces as nothing more than a "reflection" of that centre. No channel is an authority on its own; even an order arriving from a channel is just an event to decrement the central counter; the marketplace does not own that stock. If this principle is not set from day one, over-sell never fully closes no matter how fast you synchronise.

The second critical decision is event-driven synchronisation. Walking every channel one by one to update it whenever stock or price changes (polling) is both slow and rate-limit hungry. Instead we'd publish the change as an event to RabbitMQ or Kafka, and have a separate consumer service for each marketplace write that event to its own API. This architecture solves two things at once: the change propagates to all channels within seconds, and because each channel runs at its own pace, a slow one does not block the others. We keep hot data (live stock, active orders) in Redis, managing both read load and concurrency locks at this layer.

The third layer is the wall everyone working with marketplaces eventually hits: rate limits, retries, and idempotency. Trendyol, Hepsiburada, Amazon SP-API, and N11 each impose a different rate limit and error behaviour. We put a token-bucket rate limiter in front of each channel; requests are pulled from the queue at a controlled pace, so a spike never hits the API directly. On transient errors (429, 5xx) we retry with jittered exponential backoff; persistent failures land in a dead-letter queue. The most critical point is idempotency: for writes such as order confirmation and stock update, we assign each operation an idempotency key so that if a retry fires it twice, no duplicate record is created. This is the only mechanism that keeps the system safe in the "the network dropped, did the request go through or not" uncertainty.

The final layer is product listing automation and order orchestration. We'd take a product defined once in the central PIM, translate it through a per-channel mapping layer into each marketplace's own category tree and mandatory attribute set, and list it automatically; incoming orders are collected in a single queue and managed with a state machine (new → confirmed → shipped → delivered). The whole operation is gathered into one Next.js-based panel; which channel is being throttled, which listing was rejected, which order is approaching its SLA is all visible here. Sentry-based error and latency monitoring is set up from the start; the scenario where the integration silently breaks is the most expensive scenario.

Our Preferred Technology Stack

We typically reach for the following, adapted per project to the marketplaces you work with, your product count, and your order volume.