Trendyol API Changes in 2026: Field Renames, the V2 Migration, and the August 10 Deadline

For anyone building against Trendyol's seller API, 2026 is a year with two waves: in April the orders line-item fields were renamed and the old names were pulled from production within a few days; then on August 10, 2026 the Product V1 services shut down entirely. Whether you write your own integration as a seller, build an ERP/integrator, or simply keep any system that pulls Trendyol data alive, this post is for you: we have gathered every change in one place — the old-to-new field name table, the new scope and record limits, how V2 differs from V1, and how to test the migration.

The 2026 timeline: what changed and when

Here is the critical part: none of these are the kind of change where "the API starts erroring and you notice." With a field rename the request still returns 200 and the JSON still arrives — it is just that the key you were reading no longer exists, and your code silently reads null. In a system that computes order amounts from those fields, that means waking up one morning to find every line item showing 0 TL.

April 2026: orders field renames (old → new)

The full list of the changes announced in the April 2, 2026 changelog, with the old names removed from production on April 6:

Watch out: vatBaseAmount → vatRate is not a pure rename

Most rows in the table are name changes; vatBaseAmount → vatRate is a content change. The field now carries a rate, not an amount. If you need the VAT base, you have to derive it yourself from the VAT-inclusive line amount: base = lineGrossAmount ÷ (1 + vatRate/100). This is also where a classic seller mistake creeps in: on Trendyol, customer prices are VAT-inclusive, and commission is calculated on the VAT-inclusive sale price — that is not a rule that changed in April, it was already the rule. What changed in April were the API field names. In an integration that builds its margin math from API data, coding this distinction correctly is critical; the details are in "Is Trendyol commission charged on the VAT-inclusive price?"

Why did most integrations notice this late?

Because nothing "broke." HTTP 200, valid JSON, a familiar structure — only item["price"] is now undefined. In dynamic languages and tolerant parsers, that produces a silent null/0 rather than an exception. Since only a few days separated the announcement (April 2) from the removal (April 6), a "I read the changelog once a month" rhythm was not enough either. The lesson: an alarm that watches the empty-value rate per field is a more reliable safeguard than tracking the changelog — we explain how to set one up in the testing section below.

Orders history is being limited to 1 month: do not postpone your backfill

The history scope you can pull from the orders endpoint is being limited to 1 month. The practical impact is large: until now you could say "I will just pull old orders from the API when I need them"; you will not be able to anymore. What you need to do:

• Make your own database the single source of truth. The moment you pull orders, store them permanently; do not use the API as an archive.
• If you have a retrospective need, run the backfill now. Once the window narrows, you can no longer reach that data through the API.
• Run incremental sync more frequently. If your sync job stalls for a few weeks, the missed interval can turn into permanent data loss.

Order data is the raw material for payout reconciliation, return analysis, and true profit calculation. To see which deductions land on top of that data, take a look at how a Trendyol payout is calculated.

A 10,000-record limit on getShipmentPackages, and the Stream endpoint

A 10,000-record limit is coming to the getShipmentPackages endpoint, which high-volume stores use to pull shipment packages page by page. For volumes that exceed this limit, Trendyol recommends the Stream endpoint. On the integration side, this means the "keep incrementing the page number until you reach the end" pattern will no longer work at high volume: nothing comes back after the 10,000th record, and your code sees this not as an error but as "the list is over" — again a silent data-loss scenario. If you are building a system whose daily package count approaches this limit, plan the Stream-based flow now; even if you are not close, add a check that raises an alarm when you hit the limit.

August 10, 2026: Product V1 services shut down

This is the year's hardest date: the Product V1 services shut down on August 10, 2026. Unlike the field rename, here requests stop working entirely once the transition period ends. How V2 differs from V1:

• New endpoint: approved products are listed via /products/approved.
• Smaller page size: size is at most 100. Sync jobs that worked with larger pages under V1 will make more requests — update your rate-limit and time budgets accordingly.
• Nested structure: in the product response, content and variants come nested. Parsers and database mappings that expect a flat product row have to be rewritten.
• Cursor-based pagination: instead of a page number, nextPageToken is used. There is no random access like "jump to page=5"; each page is fetched with the previous one's token. Persisting the token (a checkpoint) so you can resume where you left off is your responsibility.

V2 migration checklist

1. Inventory every call in your code that goes to V1 product endpoints (a grep is enough).
2. Update your parsing and database mapping to match V2's nested content/variants structure.
3. Convert pagination to a nextPageToken loop; store the token as a checkpoint and verify empty/last-page behavior with tests.
4. Recompute your total request count and sync duration with size=100.
5. Do not leave the migration to August 10: roll out V2 now, keep V1 running in parallel for a few weeks only for comparison, then shut it off.

How do you test your integration? (Lessons we drew from April)

We lived through these changes in our own integration; the practices below are not theory, they are what actually worked on that April morning:

• Store the raw response. Alongside the fields you parse, keep the API's raw JSON too (e.g. in a raw_data column). When a field name changes, you can reprocess historical data with the new schema; if you did not store it, that data is baked into the assumptions of the day it was parsed.
• Set up an empty-value alarm per field. A condition like "more than 90% of the line items received in the last 24 hours have an empty lineUnitPrice" will warn you of a field rename before the changelog does. It is the cheapest insurance against silent breakage.
• Log unknown fields. Log the first time you see a key in the response (a "first seen" discipline). New fields are usually the first signal that the old ones are about to be removed.
• Validate with real store data. You cannot validate the orders schema on a test store that has no order history; an empty list is "compatible" with any schema. Pull from a real store with a small date window and compare the fields one by one.
• Trust the response, not the docs. For example, on the finance side settlement amounts arrive in the credit/debt fields and seller revenue is roughly credit − commission; the otherfinancials call requires transactionType, and the date range is scanned in windows of at most 15 days. We learned none of this by assumption — we learned it by inspecting the live response, and you should apply the same discipline to every endpoint.
• Test the pagination edge cases. Last page, empty result, invalid token, hitting the limit (10,000 records / size 100) — write down the expected behavior for each and lock it in with automated tests.

Pulling the data is half the job

Pulling the right data from the API is half the job; the other half is drawing the right conclusion from it: seeing which product actually turns a profit after commission, shipping, service fees, and withholding tax are subtracted. You can run this calculation for a single product with the Trendyol profit calculator, and for an entire payment period with the payout calculator. If you would rather not write and maintain the integration from scratch: when you connect your Trendyol account, Verimle pulls order, deduction, and finance data, calculates true profit per product, and detects unexpected deductions to prepare an objection draft — keeping up with the API schema and adapting to changes like the ones in this post becomes our job. Explore the Profit X-ray feature.

Note: Trendyol API field names, versions, and the migration timeline, along with the technical details here, are updated by Trendyol from time to time; this post is a guiding summary and does not replace the current official integration documentation. Before you build your integration and lock in your field mappings, always verify against Trendyol's official sources: Trendyol Developer Documentation and Trendyol Seller Information Center. This guide was reviewed on July 18, 2026.