Trendyol API Documentation: Endpoints, Auth & Examples

At many companies selling on Trendyol, the day starts the same way: orders are read one by one from the seller panel, keyed into the ERP by hand, shipping labels are prepared separately, and when warehouse stock changes, the Trendyol stock gets updated only if someone remembers. With a small catalog and few orders this works. But as the catalog grows or a second marketplace is added, every manual step turns into lost time and errors: selling items that are out of stock, listings opened at the wrong price, shipments reported late.

A Trendyol API integration is the way to make these steps happen automatically between systems. In this article we cover the general structure of the Trendyol seller API, the choice between an off-the-shelf integrator and a custom integration, the ERP and shipping side, the technical points to watch, and the most common mistakes. The goal isn't to hand you code; it's to help you ask the right questions before starting an integration project.

What does a Trendyol API integration do?#

A marketplace integration automates the flow of data between your Trendyol store and your own systems (ERP, accounting, warehouse software, your own e-commerce site). Once an API integration is in place, these jobs typically stop being manual:

• Sending new products to Trendyol and updating existing product information
• Pushing stock and prices to Trendyol from a single source at regular intervals
• Pulling new orders and turning them into sales records in the ERP
• Reporting tracking numbers and invoice details back to Trendyol
• Tracking return requests and customer questions on a single screen

The real gain is consistency as much as speed. When stock lives in one place, the question "which number is right?" goes away.

The general structure of the Trendyol seller API#

Trendyol offers a REST-based API to sellers and integrator companies and publishes its documentation on its developer portal. Because the details change over time, you should always check the current documentation when starting a project. The general picture looks like this.

Integration details and authentication#

The seller ID, API key and secret key needed to access the API are found in the seller panel, in the integration information section under your account details. Requests are authenticated with these keys using Basic Authentication. Trendyol also requires a User-Agent header on every request that identifies the seller ID and who is sending the request (your own integration or an integrator company). Since these keys allow actions on your store, they should be protected like passwords and never written into a code repository or shared files.

Product upload#

Products are sent to Trendyol with their category, brand, barcode, images, description and category-specific attributes. Uploaded products don't go on sale immediately; they go through an approval process on Trendyol's side. Product upload runs as a batch operation: when you send the request you don't get the result right away but a batch request ID (batchRequestId), and you query separately with that ID to see which products succeeded and which failed.

Stock and price updates#

Stock and price updates also run in batches and return a request ID in the same way. In practice this is the part of the integration that runs most often, because every warehouse movement and every price change has to reach Trendyol. A good design sends only the products that changed, not the whole catalog every time.

Pulling shipment packages#

On Trendyol, orders are tracked as "packages". The integration pulls new and updated packages at regular intervals and turns them into orders in the ERP. The package status (new, picking, shipped, delivered, cancelled) must be kept in sync between the two systems.

Shipping and invoice notifications#

Once an order is prepared, tracking and invoice details are reported to Trendyol. When this step is late, both the customer experience and seller performance suffer. If e-invoicing runs through the ERP, sending the invoice to Trendyol the moment it's created should be considered part of the integration.

Returns and claims#

Return and exchange requests are handled through a separate API group. The returned item's arrival back in the warehouse, its addition to stock and the return entry in accounting should all match the status of the claim on Trendyol. This is often the most neglected part of an integration.

Customer questions#

Customer questions on product pages can also be read and answered through the API. For stores with many questions, gathering them on one screen makes it easier to spot recurring topics and track response times.

Off-the-shelf integrator or custom integration?#

There are ready-made integrator tools that manage Trendyol, Hepsiburada, n11 and other marketplaces from a single panel. For most sellers, they're the right place to start. These questions help with the decision:

• Is your process standard? If you keep products in one place, push them to marketplaces and collect orders on one screen, an off-the-shelf solution is most likely enough.
• Can your ERP talk to the ready-made tool? If your ERP (for example Logo, Mikro or Netsis) has a ready connection to the integrator you choose, the job gets much easier.
• Do you have rules specific to you? If rules such as warehouse-based stock allocation, marketplace-specific pricing formulas, production-dependent lead times, bundles or complex variant structures don't fit the settings screens of ready-made tools, a custom integration comes into play.
• Are your own site and internal systems involved? If you want a single data flow between marketplaces, your own e-commerce site and internal systems, a custom middle layer can be more flexible.

The two approaches aren't mutually exclusive. Some companies run the product and order flow through an off-the-shelf integrator and build only the step it doesn't cover (such as a custom pricing calculation or reporting) separately.

Thinking about ERP and shipping together#

A Trendyol API integration isn't a project on its own; it's really part of the flow between ERP, warehouse and shipping. Before starting, these questions need clear answers:

• Which system is the source of truth? Where will product data, stock and prices live? Usually the ERP is the master, and data goes to Trendyol only from there. Editing by hand on both sides quickly leads to inconsistencies.
• How will orders land in the ERP? Which customer account, which warehouse and which document type a Trendyol order is recorded under should be defined in advance.
• Where will shipping labels be prepared? Will shipping run through Trendyol's contracted carrier or your own carrier agreement? At which step is the tracking number created, and who reports it?
• Where will invoices be issued? If e-invoices are issued from the ERP, will the invoice details be sent to Trendyol automatically?

Code written before this flow is drawn on paper usually ends up being rewritten.

Category and attribute mapping#

The most time-consuming part of product upload is often not the code but the mapping. Trendyol requires specific attributes for each category (such as color, size, material, warranty period); some are mandatory, and some accept only predefined values. Your ERP's product groups and attribute names are almost certainly different.

That's why you need a persistent mapping table: which of your product groups corresponds to which Trendyol category, which of your attributes to which Trendyol attribute, and which of your values to which Trendyol value. Brand data also has to match Trendyol's brand list. Once this table is set up properly, adding new products gets faster; without it, every product becomes manual work.

Rate limits and batch processing#

Trendyol limits the number of requests sent to the API. Since the exact values can differ by endpoint and change over time, check them in the current documentation. From a design point of view, what matters is this:

• Send in batches, not one by one. Stock and price updates can carry multiple products in a single request. Sending a separate request per product both hits the limits and is needlessly slow.
• Send only what changed. Store the last value you sent; don't resend products that haven't changed.
• Query the result. Batch operations don't return a result immediately. There should be a step that stores the returned request ID and checks the result later. According to Trendyol's documentation, batch results can be viewed for up to four hours after completion, so the check step shouldn't be delayed.
• Back off when you hit the limit. When the limit is exceeded the request is rejected. Instead of retrying the same request immediately, the integration should wait and retry at increasing intervals.

The general logic can be summarized like this:

changed = stock_changed_since_last_push()
for chunk in split_into_chunks(changed):
    request_id = trendyol.push_stock_and_price(chunk)
    enqueue(request_id)

# a separate job that runs later
for request_id in pending_requests():
    result = trendyol.batch_result(request_id)
    record_failed_items(result)

Error handling and logging#

The quality of an integration shows not when everything is fine, but when something goes wrong. The network drops, Trendyol rejects a product, a customer account is missing in the ERP. For these situations:

• Log every request sent and every response received, with the date, product and request ID. When someone asks "why does this product show the wrong price?", the answer should be in the logs.
• Don't silently skip failed items. Collect rejected products and failed orders in a list and notify the right person.
• Prevent the same order from being processed twice. When an order is pulled again, no second record should be created in the ERP.
• Track who changed what. The source of price and stock changes (ERP, manual correction, campaign) should be visible.

Test and production environments#

Alongside production, Trendyol defines a separate test (stage) environment. It exists to try the integration without affecting real orders and real stock. However, access to the test environment may require different setup from production, so it's worth clarifying this early with Trendyol's current documentation and support channel.

Going live gradually also reduces risk: first read-only (pulling orders and comparing them without writing to the ERP), then stock and price updates for a limited set of products, and finally the full catalog. Checking that the numbers match in both systems at each stage lets you catch problems while they're small.

A shared layer for multiple marketplaces#

If you sell on Hepsiburada and n11 alongside Trendyol, writing a separate ERP connection for each marketplace quickly becomes unmanageable. A healthier structure is to put a shared layer between the ERP and the marketplaces:

• The ERP talks only to this layer; products, stock, prices and orders are kept in one common format.
• A separate connector for each marketplace translates this common format into that marketplace's API.
• Category mapping, pricing rules and stock allocation can be defined per marketplace but managed from one place.

This approach reduces adding a new marketplace to writing a new connector, without touching the existing flow. Most off-the-shelf integrators work on essentially the same logic.

Common mistakes#

• Keeping stock in two places: Correcting stock by hand in both the ERP and the Trendyol panel leads to overselling sooner or later.
• Resending the whole catalog at short intervals: It hits the limits and delays the updates that are actually urgent.
• Not checking batch results: The request was sent, so it's assumed to have succeeded, and rejected products go unnoticed for weeks.
• Leaving returns for later: The order flow gets built but returns stay manual; stock and accounting records drift apart over time.
• Leaving API keys exposed: Keys sitting in code, emails or shared spreadsheets are a serious security risk.
• Reading the documentation once and moving on: Marketplace APIs get updated. An integration that doesn't follow announcements may one day silently stop working.

Where to start?#

The first step isn't code but an inventory: list the marketplace tasks you do by hand today, and note how long each one takes and where errors happen most. At most companies the quickest wins come from stock synchronization and order transfer; product upload and the returns flow follow.

If you'd like to assess together which marketplace steps are ready for automation, whether an off-the-shelf tool will be enough, or whether you need a custom middle layer, you can reach us through our contact page. You can also explore our other solutions, such as the Email Robot for classifying incoming email and Pricing and Quotation Automation for quoting, on our services page.

Frequently Asked Questions#

Where do I get the API key for a Trendyol API integration?#

The seller ID, API key and secret key are in the Trendyol seller panel, in the integration information section under your account details. Since they allow actions on your store, share them only with the person setting up the integration, through a secure channel.

Is an off-the-shelf integrator or a custom integration the better choice?#

If your process is standard and your ERP has a ready connection, an off-the-shelf integrator is usually faster and more economical. If needs such as warehouse-based stock allocation, marketplace-specific pricing rules or a shared data flow with your own site don't fit a ready-made tool, a custom integration is worth considering.

Does a Trendyol integration work with Logo, Mikro or Netsis?#

These ERPs allow data to be exchanged with outside systems, but how the connection is set up depends on the product, version and license you use. Before starting, clarify with your ERP partner which connection methods are available on the ERP side.

How often should stock and prices be updated?#

The faster your stock changes, the more often you should update, but each time send only the products that changed, not the whole catalog. That way you stay within API limits and reduce the risk of overselling.

Do Hepsiburada and n11 need separate integrations?#

Each marketplace has its own API, so each needs its own connector. But if you put a shared layer between the ERP and the marketplaces, the ERP side stays single and adding a new marketplace just means writing a new connector.