On this page
What is an API and what does an API integration do?
An API is a set of agreements that lets software talk to other software, instead of a person clicking on a screen. Think of it as a system's service counter: you ask for something in a fixed form and you get an answer in a fixed form 1. An API integration uses that counter to make two systems work together.
For a webshop it is usually about four kinds of data:
- Stock. A sale in one system lowers the quantity in the other. Also read how to sync stock across channels.
- Prices. A price change in one place arrives everywhere.
- Product data. Titles, descriptions, photos and attributes go from the source to the channels.
- Orders. An order reaches the place that processes it, and the status or tracking code goes back.
That is the same goal as any webshop integration. The difference is in how the connection is made, which is what follows.
Push and pull in plain words
A system can ask whether anything is new (pull, or polling), for example every ten minutes. It can also get a nudge as soon as something happens (push). Such a nudge is often called a webhook: the system itself sends a message to an address you provide 3. Asking is simple, but you are always a little behind and you often ask for nothing. A nudge is faster, but your side must be able to receive and process the message. Many integrations use both.
API, plugin, CSV import or ready-made integration?
All four move data from A to B. They differ in speed, flexibility and how much work you have with them.
| Approach | How it works | Fits | Watch out for |
|---|---|---|---|
| API integration | Two systems talk to each other directly, on request or as soon as something happens | Data that changes often, such as stock and orders | Someone has to build or buy it, and maintain it |
| Plugin | A module in your webshop talks to one other system | One simple connection | Every extra connection is another plugin with its own upkeep |
| File import (CSV or XML feed) | A file is fetched or uploaded at set times | Product data that rarely changes | Data runs behind between two runs, and orders usually do not travel back with it |
| Ready-made integration | A provider has already done the API work and maintains it | Well-known marketplaces, suppliers and systems | You can only choose from what the provider supports |
A ready-made integration is usually an API integration itself: the provider has done the work, so you do not have to build it. That is the normal choice as long as the system you want to connect is on the list. See also the difference between a plugin, an integration platform and a custom API.
What can go wrong?
- Limits. An API only allows a certain number of requests per period. Go over it and you get a "too many requests" response (HTTP 429) and have to wait 2. With large catalogues your integration must take that into account.
- Access. Every API wants to know who is asking, usually with a key or token. Keys expire, get revoked or leak. Who manages them?
- Versions. An API changes. An old version disappears at some point, and an integration that was not updated stops working.
- Errors. A request can fail because of an outage, a time-out or bad data. A good integration retries and shows what did not work, instead of failing silently.
- Data that does not fit. Categories, VAT codes and attributes are named differently everywhere. Someone has to match them up.
How to judge a provider
- Is there public documentation you can read yourself?
- Does data go one way or both ways, and how often?
- What happens on an error, and can you see it yourself?
- Who updates the integration when the other party changes its API?
- Which limits apply to your plan?
Build it yourself or use a provider?
Building it yourself pays off if you have a process nobody supports as standard, for example an in-house ERP or a custom POS, and if you have a developer who also maintains it after delivery. Count on build time, tests, error handling and changes whenever an API changes.
Choosing a provider is smarter for well-known channels such as marketplaces or suppliers. Those APIs are not unique to you, so you would rather share the work with others. The combination exists too: a ready-made integration for the standard channels, and your own software for what falls outside them.
What StoreLinkr offers: integrations and its own API
StoreLinkr has two sides, and you can combine them.
Ready-made integrations
The integration overview lists the marketplaces, webshops, suppliers and warehouse systems StoreLinkr already connects. You do not have to build an API link for those. If a system is not listed, it is not available; ask what is possible first. See also connecting your webshop.
The E-commerce API
For what falls outside that, StoreLinkr has a RESTful E-commerce API. Your developers can use it to read and update products, push stock mutations, and retrieve and process orders. Besides the API, StoreLinkr supports webhooks, so your system gets a nudge on a new order or stock change instead of having to keep asking. For data exchange, JSON, XML and CSV are possible. The public documentation is at api.storelinkr.com.
Your marketplace and webshop integrations keep working while your own software runs on top of them via the API. Which limits apply depends on your plan and use. Ask before you build something heavy, and see the pricing.
The API is meant for companies with in-house development capacity or a technical partner. Without a developer, start with the ready-made integrations.
Build on the StoreLinkr API
Read what the E-commerce API can do and find the public documentation.
Frequently asked questions
Sources
Checked on October 27, 2026.
- MDN Web Docs, API: developer.mozilla.org/en-US/docs/Glossary/API
- MDN Web Docs, 429 Too Many Requests: developer.mozilla.org/en-US/docs/Web/HTTP/Status/429
- Wikipedia, Webhook: en.wikipedia.org/wiki/Webhook
