The Baselinker API opens the whole account to the outside: orders, stock, prices, shipments and invoices can be read and written with your own code. It is one address you send a request to with a method name, and you get data back as JSON - no clicking in the dashboard, no Excel exports, no retyping. In practice it means everything you see in Baselinker, Poland’s most popular multichannel e-commerce hub, can be wired into your own store, accounting system, warehouse or reporting.
Below: what the API can really do, what you do not need code for at all, where off-the-shelf integrations end, and which traps blow these projects up.
What the Baselinker API is
The Baselinker API is the interface an external program uses to talk to your Baselinker account. There are no dozens of endpoints and no complicated authorisation - there is one entry point and a token from your account settings.
| Element | How it works |
|---|---|
| Address | a single connector.php endpoint at api.baselinker.com |
| Auth | a token from the dashboard, sent in the X-BLToken header |
| Request | POST with two fields: method (the function name) and parameters (JSON data) |
| Response | JSON with a SUCCESS or ERROR status and an error code |
| Limit | on the order of a hundred requests per minute per token - limits do change, check the docs before designing |
| Token scope | access to effectively the whole account; it cannot be narrowed to a single function |
The last row matters more than it looks: the token is the key to every order and every customer record. Keep it in server-side environment variables - never in front-end code and never in a public repository.
Before you write code: what Baselinker does by itself
A lot of Baselinker automation needs no API at all. The dashboard has built-in automatic actions - rules along the lines of “when a paid order arrives from this source, change the status, issue a document and prepare a shipping label”. You set them up by clicking.
The rule I apply to every quote: first I check whether a dashboard rule can do it. Code only gets written where the rules do not reach - because code then has to be maintained, while a clicked rule maintains itself. If your list of needs is mostly “move statuses and print labels”, you may not need a developer, just some order in the configuration. I will tell you that straight during the diagnosis.
Orders in Baselinker - what is possible
Orders are the most-used part of the API. You can read them, create them, edit them and move them between statuses.
getOrders- fetches orders (a hundred per request at most), with filters by date, status and sourcegetJournalList- the event journal: new order, status change, edit, payment. This is the proper way to fetch incrementallyaddOrder- pushing an order in from outside, for example from your own B2B panel or a form on your sitesetOrderFields,setOrderStatus,setOrderPayment- adding data, moving an order along and recording a payment
Fetching new orders correctly looks like this:
- You store the identifier of the last processed journal entry
- Every few minutes you ask for events newer than that identifier and pull the full data of the orders you care about
- You save Baselinker’s identifier alongside your own number - that is your only defence against duplicates
- Only after a successful save do you move the stored identifier forward
The last point is not a detail. If you move the pointer before saving, one failed run means an order nobody will ever see - and things like that only come to light during a complaint.
Baselinker also offers webhooks, that is notifications sent the moment something happens. They are convenient, but they do not free you from polling the journal: a notification may not arrive if your server happens to be restarting. A good rollout has a webhook for speed and periodic journal checks as a safety net.
Baselinker’s warehouse and stock levels
This is where the mess usually starts, because Baselinker distinguishes two different warehouses and they are easy to confuse.
The internal catalogue holds products kept inside Baselinker itself: you read them with getInventories and getInventoryProductsData, and change them with updateInventoryProductsStock and updateInventoryProductsPrices (in batches, on the order of a thousand products per request).
External storage is your store plugged into Baselinker - WooCommerce, PrestaShop, Shoper. Here getExternalStorages, getExternalStorageProductsData and updateExternalStorageProductsQuantity apply.
Before you write a line of code, answer one question: where does the truth about stock live? One place, not two. If Baselinker counts stock, the store only receives it. If your warehouse or ERP counts it, Baselinker gets a finished number and has no right to change it. Two-way sync “just in case” is the simplest way to sell goods you do not have - two systems subtract the same unit, each of them once.
Practical rules: send only the products whose stock actually changed, not the whole catalogue every ten minutes; do a full recalculation once a day at night; log every batch of changes together with the API response.
Shipping, documents and invoices
The API also covers what happens after an order is picked: createPackage books a shipment with the courier, getLabel returns a label to print, getOrderPackages checks tracking numbers. On the document side there are addInvoice, getInvoices and getSeries - issuing invoices and keeping numbering in order.
It is worth separating two things. Issuing a document can be automated without worry. Sending an invoice to KSeF, Poland’s mandatory e-invoicing system that now covers all businesses, is a different league - a wrongly sent document costs real time in corrections. In the setups I build, the automation prepares the whole package and a human approves the send with one click. How to arrange that I laid out in a custom KSeF integration and in the piece on connecting WooCommerce with an ERP and KSeF.
Where off-the-shelf integrations end
Baselinker’s plugins and built-in connections handle the typical scenario: a store on a popular engine, a standard product, standard shipping. You write code when your case falls outside that pattern.
| Situation | What the off-the-shelf option lacks |
|---|---|
| Bundles and kits | the stock of a bundle depends on several products at once - it has to be recalculated with your own rule |
| Per-channel pricing | one margin on Allegro, another in the store, another for a regular B2B customer |
| Your own customer panel | orders from a B2B panel on WordPress have to reach Baselinker through addOrder |
| An unusual store engine | a custom-coded or heavily modified store - no ready connector |
| Reporting and margin | profit after purchase cost and channel commissions gets calculated on your side |
| Business rules | ”hold the order if the customer has an unpaid previous invoice” |
If you are still weighing up whether Baselinker is the right place to wire your channels together, I put a comparison in the piece on Baselinker alternatives, and plugging Allegro itself into different engines I described in the article on marketplace integrations.
The traps that cost the most
Ordered from most frequent - I have seen all of them live.
- No duplicate protection - a repeated request creates a second order or a second invoice. Every write operation needs its own key and a check on whether it already ran
- Ignoring the rate limit - the integration works in testing with five products and dies with five thousand
- No error handling - the API replied with an error, the code carried on, and the data diverged in silence
- Stock counted in two places - the classic above, ending in selling goods you do not have
- No logs - when stock drifts a month later, without logs you cannot even establish when it started
- Zero testing on a copy - the first run goes straight onto the production account, on live orders
An integration is like electrical wiring: everything works for the first week, and the difference between good and bad work shows up in the third month. That is why what I hand over always has an operation log and an alert when the sync stops running - a standard part of optimization, not a paid extra.
Where to start and what it costs
I start with a free diagnosis: I look at your Baselinker account, your store and the list of things done by hand, then say plainly what a dashboard rule will handle and what needs code. Often the first part is bigger - and that is good, because it is the cheapest automation there is.
If real development work remains, you get a written quote before the start, with the scope broken into points. Typical rollouts at this scale - wiring a store to Baselinker with your own rules, a B2B panel pushing orders into the system, recalculating bundle stock - fit the fixed-bid project range: 5,000-10,000 PLN net. Smaller pieces come in below that, and integrations built into a larger WooCommerce store project are quoted together. Baselinker’s own subscription depends on order count and its price list does get updated - check that at the source.
Frequently asked questions
Is the Baselinker API free? API access is part of the account, not a separately paid add-on - you generate the token in settings. You pay for the Baselinker subscription according to its price list, and writing and maintaining the integration on your side is a separate cost.
Can I connect Baselinker to WooCommerce without a developer? Yes, the basic connection is set up in the dashboard and for a typical store that is enough: orders come in, stock goes back. Code is only needed for bundles, channel-dependent pricing, a B2B panel or rules the dashboard does not support.
How long does building an automation like this take? A simple one-way sync is usually a few working days including tests on a copy. Rollouts with invoices, bundles and custom rules take a few weeks - I give the deadline in the quote, after looking at the account and the store.
What happens when Baselinker changes its API? Changes happen and an integration can stop working correctly even though you touched nothing. That is why every rollout has logs and error notifications, and clients on ongoing support have the response included in the plan - Basic from 1,000, Pro from 2,000, Premium from 3,500 PLN net per month.
Running a store where something does not work the way it should? I build and rebuild WooCommerce stores - from a single fix to reworking the whole sales flow. Tell me what you are dealing with and I will send back a scope and a price.