Best Product APIs for Dropshipping and E-commerce in Poland

A store with a hundred products can still be managed by hand. Once you’re dealing with a thousand items whose prices and stock levels change weekly at the supplier’s end, manual data entry stops being viable — someone has to check every day whether a product is still in stock, whether the price changed, whether an image went missing. In practice, this is how stores end up selling items the wholesaler no longer has, or listing products at a price that’s a month out of date.
A product API is one way to solve this — not the only way, and not always the best one for every situation, but by far the most common choice once sales volume outgrows manual work. This article explains what a product API actually is, how it differs from related concepts (supplier API, marketplace API, XML feed), and what this looks like specifically in the Polish market — with BaseLinker, Allegro, WooCommerce, Shopify, PrestaShop, Shoper and IdoSell.

What Is a Product API?

An API (Application Programming Interface) is simply a standardized way for two software systems to communicate without human involvement. One system asks for data, the other responds — always in the same, predictable format.

A product API is a narrower concept: an interface through which an external system (e.g. an online store) can pull product data — names, prices, images, stock levels — directly from the database of whoever holds that information, instead of someone typing it in by hand.

The simplest analogy: instead of calling a wholesaler every day and asking “how many units of product X do you have and at what price,” your store “asks” that question automatically, electronically, once an hour or more often — and updates its own listing based on the answer.

A concrete example: an online store sends a request to a footwear wholesaler’s API for data on a given SKU. In response it receives a structured payload (usually JSON or XML) containing the name, wholesale price, available sizes, stock level, and image URLs. The store automatically saves this data and updates the product page.

One important caveat up front: not every tool marketed as an “API integration” is the same thing as a product API in the strict sense. Later in this article we clearly separate supplier APIs, store APIs, marketplace APIs, and integration platforms — a distinction that genuinely affects which solution you actually need.

How Does a Product API Work?

A typical data flow between a store and a product data provider looks like this:

1. Connection – the store’s system (or an intermediary integration platform) connects to the provider’s API endpoint.
2. Authentication – usually via an API key (token) generated in the provider’s panel; the token identifies who is asking and what data they can access.
3. Request – the system sends a request, e.g. “get product data changed after date X” or “get the stock level for SKU Y.”
4. Response – the API returns data in JSON or XML, usually with a status code indicating whether the request succeeded.
5. Data mapping – fields from the API response (e.g. stock_quantity, price_net) need to be matched to fields in the store’s database, since naming rarely lines up between the two sides.
6. Save or update – based on the mapped data, the system creates new products or updates existing ones.
7. Recurring sync – the whole process repeats automatically at set intervals (hourly, every few hours, sometimes near real-time via webhooks).

A Polish-market example: a WooCommerce store works with a clothing wholesaler that exposes its own API. A script on the store’s side (custom-built or running as a plugin) queries the wholesaler’s API every hour for stock changes and writes the result directly into the WooCommerce database through the store’s built-in REST API. A customer browsing the store always sees current availability — with no human involved on either side.

What Data Can You Pull Through a Product API?

The scope of data depends entirely on what a given provider has decided to expose — there’s no single universal standard here. The fields you’ll see most often are:

• product name
• SKU (the supplier’s internal identifier)
• EAN (barcode — critical for listing products on Allegro and other marketplaces; many categories have limited visibility without one)
• description (short and/or long)
• images (usually as URLs, less often as binary files)
• categories and subcategories
• variants (size, color, capacity, etc.)
• attributes/technical parameters
• price – worth checking whether the API returns net or gross price and in what currency; integrations with Polish wholesalers almost always mean PLN, but this needs verifying with foreign suppliers
• VAT rate
• stock level (an exact quantity, or just an “in stock / out of stock” status)
• supplier/manufacturer
• shipping information (fulfillment time, weight, package dimensions — relevant for calculating delivery costs)

Not every API returns the full set. Some wholesalers, especially smaller ones, expose only a basic set (name, price, stock), and the rest has to be filled in manually or sourced elsewhere. This is one of the first things worth checking before integrating — a missing EAN in a supplier’s data is a warning sign, since it will make listing on marketplaces harder later.

What Can You Actually Use a Product API For?

• Importing products from a wholesaler – a one-time or recurring upload of the entire catalog into the store.
• Automatic product updates – description, category, or parameter changes without manual work.
• Stock synchronization – prevents selling items the supplier no longer has.
• Price synchronization – important especially with suppliers who revise price lists several times a month.
• Product image sync – automatically pulling and swapping images.
• Updating descriptions – useful for large catalogs where manually editing thousands of product pages isn’t practical.
• Syncing variants – sizes, colors, and other product options updated together with the parent product.
• Connecting multiple stores – one product database feeding several storefronts at once (e.g. your own store plus a white-label store for a partner).
• Connecting marketplaces – listing the same catalog on Allegro, Amazon, or eBay without duplicating the work.
• Sending orders to the supplier – in a dropshipping setup, a customer’s order flows automatically into the wholesaler’s system.
• Tracking order status – shipping information flows back to the store and on to the customer.
• Automating the whole dropshipping process – combining the points above into one largely hands-off workflow.

Product APIs and Dropshipping

In a dropshipping setup, a product API acts as the connector in the chain:

Supplier → API → Integration → Online Store → Customer

Product data (name, price, stock, images) flows from the supplier to the store. When a customer places an order, information flows the other way — from the store back to the supplier, who ships directly to the end customer. A well-configured integration means the seller never physically touches the goods — the entire information flow happens electronically.

This is a good place to be clear about what an API does not automatically solve, since it’s one of the most common misunderstandings among people new to dropshipping:

• Supplier reliability – an API will pass you exactly the data the supplier entered; if the supplier has trouble shipping on time, no integration fixes that.
• Product quality – syncing a description doesn’t guarantee the described product actually meets the customer’s expectations.
• Shipping times – an API can return a stated fulfillment time, but it doesn’t control whether the supplier actually meets it.
• Returns and complaints handling – this is still a process you need to establish and negotiate with the supplier separately, outside the technical integration itself.
• Margins and profitability – automating the data flow doesn’t remove the need to check whether the numbers work at all, given the wholesale price, marketplace commission, and shipping costs.
• Marketplace compliance – Allegro, for example, requires that in a dropshipping arrangement the seller remains the party facing the buyer (their own details on the invoice, their own complaints handling) — an API doesn’t remove that obligation.

In other words: a product API automates the flow of information, not business accountability. It’s a good tool for scaling operations, not a substitute for choosing a good supplier.

Popular APIs and Platforms for E-commerce in Poland

Below is an overview of the solutions a Polish seller is most likely to run into. We deliberately don’t rank them from “best” to “worst” — each answers a different need.

BaseLinker

BaseLinker is a Polish tool that isn’t itself a product API — it’s an integration platform for managing multichannel sales. It connects an online store, marketplace accounts (Allegro, Amazon, eBay, and others), couriers, and accounting systems in a single panel.

BaseLinker does, however, expose its own fully documented REST-style API (api.baselinker.com/connector.php), which communicates in JSON and requires a token passed in the X-BLToken header. Through this API, developers can programmatically read and write order, product, and stock data — the documentation covers roughly 195 methods, with a request limit of 100 per minute. Changes (e.g. new orders) have to be polled via journal-log methods (getJournalList) — BaseLinker doesn’t publish official webhook documentation, so event-driven integrations work on an observed basis rather than a documented one.

For stores without an in-house developer, BaseLinker also offers ready-made integrations with wholesalers that expose an XML file — the tool pulls and maps the data itself, no code required.

Allegro API

The Allegro API (available at developer.allegro.pl) is a marketplace API, not a supplier’s product API. Once authorized via OAuth, it lets sellers manage their own Allegro listings: creating new offers, updating prices and stock, handling orders, promotions, post-sale claims, and buyer messages.

The key difference from a supplier API: the Allegro API operates on listings published on the platform, not on a supplier’s product catalog. If you want to automate listing creation based on wholesaler data, you need two pieces: a source of product data (a supplier API or an XML feed) and an integration with the Allegro API (built yourself or through a tool like BaseLinker/Apilo) that translates that data into actual listings.

It’s also worth checking the current verification status for public resources (e.g. GET /offers/listing) — Allegro periodically suspends or changes access rules for certain resources, so this should be verified against the official documentation before integrating.

WooCommerce REST API

WooCommerce, as a WordPress plugin, ships with a built-in REST API (available since version 2.6) that communicates in JSON, authenticated via API keys generated in the WooCommerce panel (Settings → Advanced → REST API). This is a store API — it allows reading and writing products, orders, and customers, plus webhooks for order status changes.

In practice, the WooCommerce REST API is the piece of the puzzle that receives data from a supplier API or an integration platform and writes it directly into the store’s database. On its own it doesn’t supply product data — it only allows that data to be entered and read programmatically.

Shopify Admin API

Shopify offers an Admin API for managing the store — products, variants, stock levels, and orders. An important fact for 2026: Shopify has officially marked the REST Admin API as legacy as of October 2024 and recommends building new integrations on the GraphQL Admin API instead. Public apps relying on older REST resources for products and variants had to migrate by February 2025, and custom integrations handling more than 100 product variants also need to move to GraphQL. Shopify ships new API versions quarterly (e.g. 2026-01, 2026-04) — when integrating, it’s worth pinning to a specific, current version rather than a generic endpoint.

For stores planning an integration with a Polish wholesaler or with BaseLinker, this means one thing: new integrations (custom scripts, not off-the-shelf plugins) should be designed for GraphQL from the start, rather than following older REST examples that are still floating around online.

PrestaShop Webservice API

PrestaShop includes a built-in Webservice module, which defaults to XML (JSON is also supported), authenticated with an API key generated in the admin panel (Advanced → Web Service). Webservice allows managing products, stock levels, categories, and orders, and connecting the store to external ERP systems.

This is a classic store API — in Polish deployments it’s most often paired with third-party modules that handle XML/CSV imports or direct API connections on the wholesaler’s side, while writing data into PrestaShop via Webservice.

Shoper

Shoper (a popular Polish SaaS platform) offers an open API (WebAPI) that lets external applications manage products and orders. Historically this was a SOAP/XML-based API — before integrating, it’s worth confirming the current version and format directly with the provider, since API documentation and capabilities evolve, and the latest details are best verified in the store panel or with Shoper directly.

IdoSell

IdoSell (formerly IAI-Shop) runs a comprehensive REST-based Admin API 3 — fully RESTful, with newer documentation and support for no-code integrations; the previous version, API 2.0, was retired from active development at the end of 2024. Notably for dropshipping: IdoSell also separately documents API gateways (the CustomerAPI, part of the ICDF format) specifically for wholesalers receiving dropshipping orders — i.e. the scenario where IdoSell sits on the supplier/wholesaler side, not the retail store side. It’s a good example of how a single provider can offer both a store API and a separate API designed for the supplier’s role in a dropshipping chain.

Polish Wholesalers and Suppliers

This is one of the most important facts about the Polish dropshipping market: most Polish dropshipping wholesalers don’t offer a full, publicly documented product API — instead they provide a recurring XML or CSV file at a fixed URL, sometimes following a commonly used schema (such as the IOF format, used across many integrations with platforms like Apilo). Some larger wholesalers additionally offer a B2B ordering panel and, less often, a genuine REST API.

If you’re trying to figure out what you actually need from a given supplier, a good starting point is a simple question to the wholesaler’s support team: do they provide a link to a periodically updated XML/CSV product feed, or a full API integration. The answer determines what type of integrator you’ll need on your side.

Availability, data scope, and terms of cooperation vary between suppliers and change over time — always worth verifying directly with the specific wholesaler before deciding.

Product API vs. XML/CSV Feed

This distinction matters a lot in Poland, since a large share of wholesalers simply don’t invest in building a full API — providing an XML or CSV file is cheaper and easier for them to maintain.

The key takeaway: an XML or CSV feed isn’t automatically a worse solution — if the supplier refreshes it hourly and your store doesn’t need real-time data, a product feed is entirely sufficient, and it’s usually simpler and cheaper to implement than a full API. A genuine API earns its keep where reaction speed to a change matters (e.g. fast-moving electronics stock) or where you need to send data the other way (e.g. orders to the supplier).

Supplier API vs. Store API vs. Marketplace API

This distinction accounts for most of the confusion around the term “product API.” In practice there are four different roles:

Supplier API (wholesaler API)
→ exposes data about the supplier’s own products: wholesale price, stock level, description. This is the data source in a dropshipping chain.

Store API
→ manages data in your own store: products, orders, customers. Examples: WooCommerce REST API, Shopify Admin API, PrestaShop Webservice, IdoSell Admin API 3.

Marketplace API
→ manages listings published on a given sales platform: the Allegro API, or equivalent APIs on other marketplaces. It operates at the listing level, not the supplier’s product catalog.

Integration platform
→ isn’t any of the above on its own — it ties them all together in one panel. BaseLinker and similar tools (e.g. Apilo) expose their own APIs, but their main function is connecting wholesalers, stores, and marketplaces into a single data flow without writing custom integration code.

When someone searches for a “product API,” depending on context they could mean any one of these four things — and that ambiguity is exactly what most often leads to disappointment after buying the wrong tool.

How to Choose a Product API for Your Online Store

• Documentation – is it complete, current, and publicly available, or do you have to ask for it after signing a contract?
• Authentication – API token, OAuth, header key – what mechanism, and is it secure (HTTPS mandatory)?
• REST or GraphQL – especially relevant for Shopify, where REST is already being phased out.
• Rate limits – how many requests per minute/hour does the provider allow, and is that enough for your catalog size?
• Webhooks vs. polling – does the provider notify you of changes automatically, or do you have to check periodically yourself?
• Pagination – how the API handles large catalogs (thousands of products) without overloading requests.
• SKU and EAN presence – a missing EAN will make marketplace selling harder later.
• Variant support – sizes, colors, packaging variants.
• Images and descriptions – in what format, and whether the license allows commercial use.
• Currency and VAT rates – especially with non-Polish suppliers, where prices may not be in PLN.
• An XML/CSV fallback – does one exist, in case API integration turns out too costly?
• Order synchronization – can the API send orders back to the supplier?
• Marketplace support – does the provider or integrator make it easy to list on Allegro and other platforms?
• Compatibility with your platform – WooCommerce, Shopify, PrestaShop, Shoper, IdoSell – not every API has ready-made plugins for every platform.
• Stability and SLA – how often is the API unavailable, and does the provider communicate that?
• Scalability – will the solution hold up as the catalog grows from a few hundred to tens of thousands of products?
• Monitoring and error handling – do you have (or plan to build) an alerting system for broken synchronization?

How to Integrate a Product API with Your Store

1. Choose a data provider – a wholesaler with its own API, a ready-made integration platform (e.g. BaseLinker), or an XML/CSV feed.
2. Get access credentials – token, API key, developer panel login.
3. Read the documentation – especially the list of available methods and the response format.
4. Connect to the API – run a first test request and verify authentication works.
5. Map the fields – match field names and structures (e.g. the supplier’s product_name to WooCommerce’s post_title).
6. Import products – the first, usually one-time upload of the full catalog.
7. Update stock levels – set a sync cycle matched to how often the supplier’s data actually changes.
8. Update prices – similarly, accounting for any markup rules.
9. Handle errors – what happens when a request fails (product removed, response format changed, rate limit hit).
10. Monitor synchronization – alerts for a broken integration, so you don’t find out about a problem from a customer.

Simple integrations with a single wholesaler, through a ready-made tool like BaseLinker, can usually be set up yourself using the integration wizard. Custom integrations — a wholesaler’s own API with no ready module, several data sources at once, or migrating from REST to GraphQL on Shopify — usually call for a developer.

Common Problems with Product APIs

• Incorrect product data – the supplier changes a field’s structure without notice, and the integration starts saving empty values. Fix: validate data before saving, alert on unusual values.
• Missing EAN – blocks listing in many Allegro categories. Fix: filter out products without an EAN and fill in only the most important ones manually, or drop that supplier.
• Duplicate products – the same product imported multiple times under different identifiers. Fix: use a single, unambiguous mapping key (ideally the supplier’s EAN or SKU), not the product name.
• Hitting rate limits – the integration starts returning 429 errors. Fix: implement request queuing and a delayed retry mechanism.
• Authentication errors – an expired token, a changed API key. Fix: monitor token validity and auto-refresh where the API supports it.
• Inconsistent SKUs – different systems use different identifier conventions. Fix: settle on a single, master identifier at the start of the integration.
• Missing images – image links stop working on the supplier’s side. Fix: cache images locally instead of relying solely on external URLs.
• Outdated stock levels – syncing too infrequently for a fast-moving catalog. Fix: match the sync frequency to how quickly the supplier’s data actually changes.
• Price changes noticed too late – risk of selling below cost. Fix: automatic markup rules instead of fixed prices.
• API downtime – the supplier has an outage and synchronization stalls. Fix: notifications for failed syncs, plus a fallback plan (e.g. temporarily flagging products as “check availability”).
• Feed file problems – a corrupted or incomplete XML/CSV file. Fix: validate file structure before importing, not after.
• API version changes – the provider retires an old version (as with Shopify REST or IdoSell API 2.0). Fix: track provider changelogs and plan migrations ahead of time, before the old version stops working.