Integration software and marketplace integration services: so your store, marketplaces and ERP see the same stock and the same price.

We wrote this guide for e-commerce teams that sell on more than one channel and move stock, prices or orders between systems by hand, want to set up marketplace integration, or find that the off-the-shelf integration tool they use doesn’t meet their needs. We based the technical rules we describe on the official developer documentation of Trendyol (a Türkiye-based online marketplace), Shopify, WooCommerce and Amazon; the sources are listed by number at the end of the page. We verified limits, version changes and service names against the source as of October 2026. Our own field observations are marked separately under the heading “Expert note”.

Our integration work runs in three layers: deciding where each piece of data is considered correct and how it maps between channels, building the integration on official APIs and an infrastructure that respects limits, and monitoring errors, reconciliation and version changes. The ten sections below explain how these layers work and what we check during setup, in that order.

What is e-commerce integration, and why is it needed?

E-commerce integration means connecting a company’s online store, marketplaces, ERP or accounting software and shipping carriers through APIs, so product, stock, price, order and invoice information stays in sync without being moved by hand. As the number of channels grows, manual updates take time and create errors: a product that has sold out on one channel keeps selling on another, and canceled orders hurt customer satisfaction and the seller rating on the marketplace.

We cover building the sales channels themselves on our e-commerce website development page, and growing on those channels on our e-commerce marketing page; this page goes into the software that connects the channels.

How does marketplace integration work?

Marketplaces offer APIs so sellers can connect their stores to their own systems. The Trendyol API lets companies in the marketplace program handle product transfer, stock and price updates, order processing, invoice submission and customer questions from their own e-commerce systems.¹ Amazon’s Selling Partner API likewise gives sellers access to order, shipment, payment and inventory data through a REST-based interface; applications work with the permissions the seller grants through OAuth.¹⁰

Most of our clients sell in Türkiye, so the examples on this page often involve Trendyol, one of the country’s main online marketplaces, and ikas, a Türkiye-based e-commerce platform; the same approach applies to Amazon, Shopify, WooCommerce and other channels with official APIs.

Each marketplace’s API works with different rules: product creation fields, category attributes, request limits and order statuses vary from channel to channel. That’s why we build the integration with a separate connector for each channel and a channel-independent data model in the middle; adding a new channel means writing only that channel’s connector, not the whole system.

Single source of truth: where should stock, price and product data live?

The integration’s first decision isn’t about software: for each piece of information, you need to decide which system is considered correct. Stock usually lives in the warehouse or ERP system, product descriptions and images in the online store, and prices in accounting software or a pricing sheet. If the same information can be changed in two systems at once, sooner or later one overwrites the other, and there’s no way to know which is right.

Once the source system is set, the other systems are fed from it. Orders flow the other way: an order from the marketplace is written to the source system, stock is deducted there, and the new stock is sent out to every channel.

The order of invoicing and shipping is set from the start too. After the order is written to the source system, the invoice is issued, a tracking code is obtained from the carrier and that code is reported back to the marketplace; returns and cancellations follow the same path in reverse. When it’s written down which step happens in which system and in what order, it’s immediately clear where the process stopped if a step fails.

How do product, category and XML feed mapping work?

Marketplaces keep products in their own category trees with their own attribute lists; attributes such as color, size or material that are mandatory in one category may not exist at all in another. Most of an integration is this mapping: a table records which field and which value each field on your product card corresponds to on every channel.

We match products across channels by barcode and stock code. In catalogs where products have no barcode, the same barcode is used for more than one product, or variants were created as separate products, we clean the data first and show unmapped products in a separate list. We keep the mapping table in a panel your team can update too; when a new category opens, no software change is needed.

Product data from suppliers, and from some sales channels, often arrives as an XML feed. In an XML integration the file is read at regular intervals, only changed products are processed, and the feed’s fields are tied to the same mapping table. An XML feed is usually one-way: products and stock come in, orders don’t go back; when orders need to move as well, we complete the flow with an API.

Price mapping works the same way. Because channels run on different commission rates and shipping terms, the same product often has a different price on each channel; instead of entering that difference by hand for every product, we tie it to a rule per channel. During campaigns, we define temporary prices with a start and end date, so the price returns to the usual rule on its own when the campaign ends.

Rate limits and queues

Marketplaces and platforms limit the number of requests that can be made in a given time to protect their systems. On Trendyol, starting September 14, 2026, limits are applied per service group rather than per service; for a seller with a 50,000-product listing limit, for example, product creation, update and deletion services together are limited to 200 requests per minute, and stock and price updates to 350 requests per minute.² If more than 30 price updates per minute are sent for the same barcode, an error is returned for that barcode.² Shopify’s limits work with a leaky bucket algorithm: each request adds some amount to the bucket, the bucket drains at a steady rate, and when the bucket is full, requests are throttled.⁷

That’s why, instead of sending requests directly, we put them in a queue and drain the queue at each channel’s limit. We merge multiple stock changes for the same product that arrive within a short time into a single update, and during campaigns we line up price updates so they don’t hit the per-barcode limit.

Batch operations and error tracking

Marketplaces process many operations in a queue rather than immediately. On Trendyol, operations such as product creation, product update and stock-price update return a batch request ID for a successful request; whether the operation actually completed, and which products had errors, is checked separately with that ID.³ These results can be viewed for up to 4 hours; for stock-price updates, the item-level status fields must be read rather than the batch’s overall status.³

The gap between “request sent” and “operation completed” is the most commonly overlooked point in integrations. We check the result of every batch, log failed products together with the reason, and alert your team when errors repeat. Trendyol also offers a test environment, so we develop there first.³

Webhooks or scheduled polling?

There are two ways to learn about a change in another system: polling it at regular intervals, or having it send a notification when something changes. Shopify webhooks send near-real-time data when a specific event happens in a shop, and are a more performant alternative to continuously polling for data; incoming notifications should have their HMAC signature verified, and duplicate deliveries of the same notification should be ignored.⁸

Services that don’t offer notifications need polling, and polling has its own rules. For large data scans and regular sync, Trendyol recommends its new cursor-based order service over the old page-based one: the old service can reach at most 10,000 records, while the new one returns the last 3 months of data in windows of up to 14 days.⁴ We set the polling interval by the channel’s order volume, and start every poll from the last successful time so a missed poll can close the gap.

In most projects we use both methods together: we process changes instantly through notifications, and a nightly poll checks whether any change was missed. Because notification systems can occasionally miss a delivery, this second check stops differences between channels from building up.

Security: keys, permissions and access

An integration is software with read and write access to your systems, so permissions need to be kept as narrow as possible. WooCommerce REST API keys are generated for a specific WordPress user, follow that user’s roles and capabilities, and are granted at read, write or read/write level; accessing the API over HTTPS is recommended where possible.⁹ With Amazon SP-API, the application works with the permissions the seller grants through an OAuth flow.¹⁰

We keep API keys not in the code but in an encrypted secrets store, and give each connection only the permissions it needs. A connector that updates stock shouldn’t be able to read customer data. Keys are generated in your company’s name; when the work ends, our access is closed.

Personal data such as customer names, addresses and phone numbers also moves between systems with orders. We transfer this data only to the systems that need it, and mask personal details in logs and error reports, so customer data isn’t exposed unnecessarily while debugging.

Off-the-shelf integration software or a custom integration?

The deciding factor is less the number of channels than how complex your data is. Off-the-shelf marketplace integration tools open standard flows quickly; as your own rules multiply, fitting them inside the tool’s limits gets harder. The three routes compare like this:

If the tool you already use does the job, we don’t recommend replacing it; filling the missing link is often enough.

Monitoring and maintenance: what happens when API versions change?

Platforms change their APIs regularly and retire old versions. Shopify’s REST Admin API has been a legacy API since October 1, 2024; since April 1, 2025, all new public apps must be built exclusively with the GraphQL Admin API.⁶ Trendyol also changed its product service limits from September 14, 2026, and recommends moving from the page-based service to the cursor-based one for large order scans.²⁴

We follow platforms’ change announcements and update affected flows before the migration date. Learning from a customer complaint that the integration stopped one morning is always more expensive than putting the migration on the calendar.

The day-to-day part of maintenance is reconciliation: every night a report compares stock and orders in the source system with each channel and lists any mismatched products with the reason. Read together, the error board, the reconciliation report and the version calendar show the health of the integration at a glance.

How our integration services work in the first 30 days

The job of the first 30 days isn’t to connect every channel at once; it’s to make the data decisions, automate the flow that creates the most manual work, and verify the result with reconciliation. We work in this order:

1. Week 1 · Review: channels, systems, API access and the state of product data are reviewed; single-source-of-truth decisions are written down.
2. Week 2 · Mapping: product, category and pricing mapping tables are prepared; unmapped products are listed.
3. Week 3 · First flow: the flow that creates the most manual work, usually stock and orders, is built in the test environment and taken live with a limited set of products.
4. Week 4 · Reconciliation: stock and orders on the channels are compared with the source system; the order of the next flows is decided together.

How to choose an e-commerce integration company

You find out how good an integration is not on day one but the first time something goes wrong. We suggest comparing proposals on these points:

1. Official APIs: the connection is built on the marketplace’s published API; tools that fill in panel pages automatically or scrape screens stop without warning when the panel changes.
2. Result checks: batch operations are checked separately to confirm they actually completed; “request sent” is not treated as success.
3. Visible errors: errors appear on a board your team can read, with the product name and what needs to be done.
4. Key and code ownership: API keys are issued in your company’s name and the source code sits in your repository, so the integration stays with you if you change partners.
5. Version tracking: it’s written down who follows platform API changes and whether migrations are covered by maintenance.
6. Overpromising: “zero errors” or “instant sync” doesn’t square with marketplaces that work with request limits and queues.

What drives integration software pricing?

Pricing depends less on the number of systems than on the state of the data and the complexity of the flows:

Fees usually combine a project fee for the build with a monthly fee for maintenance and monitoring after launch. We work out the scope together in the first meeting and then send a written proposal; third-party costs such as servers or tool subscriptions are separate from our fee and paid directly to the provider.

Integration software pricing: starting prices and ranges

The lower end of each range is the starting price; excluding VAT. Scope is confirmed in a written proposal after the first meeting. As of October 2026.

If you’d like to look at your channels together, pick a meeting day that suits you below; in the first meeting we find together which flow creates the most manual work.