Connecting your store to a supplier via API: stock, price lists and images kept up to date

Importing a supplier's catalogue once is a few days' work. Keeping it up to date is work that never ends: prices change, stock runs out, new colours appear, references are discontinued. If you do it by hand, your store is always lagging behind, and you sell what is no longer there or at a price that no longer applies.

When the supplier offers an API, the store can query it continuously. This article deals with that ongoing synchronisation; if your supplier only gives you CSV or XML files, we have another guide dedicated to that case.

What changes with an API compared with a file

• Up-to-the-minute data: stock is queried when needed, not when the supplier generates the file.
• Partial queries: you can ask for just the stock or just the prices, without downloading the whole catalogue.
• Rich data: many suppliers publish things in the API that do not fit in a CSV: tiered price lists, customisation techniques, images per colour, texts in several languages.
• More demanding: you have to handle authentication, request limits, network errors and API version changes.

What to sync and how often

What makes no sense is downloading the whole catalogue every hour: you load the supplier's server and yours, and you risk exceeding their limits.

Cost price is not selling price

The supplier gives you their price list; you decide your price. The connection needs clear rules:

• Margin by category, brand or price band, not a single one for everything.
• Quantity tiers: in sectors such as textiles or promotional products, the cost drops a lot above a certain volume. Those tiers should become quantity prices in your store.
• Rounding that does not leave prices like €12.37.
• Prices that are not touched: if you have lowered a product by hand for a campaign, the synchronisation should not overwrite it without warning.

Stock: yours and the supplier's

If you also hold goods in your own warehouse, merging your stock with the supplier's into a single number misleads the customer: “I have it and it ships today” is not the same as “I order it from the factory and it takes a week”. The right approach is to keep them separate and show a different lead time depending on where each unit comes from. And to decide what to do when someone orders more than the two add up to: block the sale or ask them to get in touch for a quote.

Combinations, languages and images

• Colours and sizes must become PrestaShop combinations matched to the attributes you already have, not new duplicate attributes (“Red”, “red”, “RED”).
• Images per colour, associated with their combination.
• Texts in every active language of your store, if the supplier publishes them.
• Categories: the supplier's tree is not yours. Their categories have to be matched to yours.
• Features (material, dimensions) as PrestaShop features, so that they work in the filters.

Customisation

In promotional products or customised textiles, the product is not sold on its own: it is sold with a print or marking. The supplier publishes techniques, areas, number of colours and costs (often with fixed set-up costs). Bringing that into the store lets the customer choose the technique and see the final price calculated, instead of requesting a quote for everything.

Common mistakes

1. Overwriting what you have improved: SEO texts or your own photos that the synchronisation replaces again with the supplier's.
2. Not logging what changes: without a history, you do not know why a price went up.
3. Syncing at peak hours and slowing the store down.
4. Not alerting when the API fails: the synchronisation stops and nobody notices until something out of stock is sold.
5. Credentials in the code: API keys go in the configuration, never in files that are copied or uploaded to a repository.

Checklist

1. You are clear about what data the API provides and with what limits.
2. Price rules by category and quantity tiers.
3. Your own stock and the supplier's kept separate, with different lead times.
4. Discontinued products are disabled, not deleted.
5. Attributes and categories matched to yours.
6. A change history and an alert if the synchronisation fails.

How to handle it in PrestaShop

RKR Conector Makito is an example of this type of connection: a package with a hub that compares and writes to the store, the connector to the Makito API, an optional sales multiples module and RKR Supplier Stock (optional, PrestaShop 9). It brings in the supplier's four price tiers (per unit and from 500, 2,000 and 5,000 units) converted into a selling price with your rules and into quantity prices, the texts, colours and features in the seven languages Makito publishes, and lets the customer add the product to the cart with its marking and the price already calculated. With RKR Supplier Stock, your stock and Makito's are stored separately, per combination, with different messages and lead times for each case, and by default no more is sold than the two add up to. Without that module, the connector works on PrestaShop 1.7.6 to 9.x. For other suppliers, the custom connectors that accompany this article follow the same approach.