Integracja BaseLinker ze sklepem i ERP — jak to zrobić dobrze

Integracja Base — systemu znanego wcześniej jako BaseLinker — ze sklepem i ERP wymaga czegoś więcej niż uruchomienia gotowego połączenia. Trzeba określić, skąd pochodzi wiążąca wartość stanu magazynowego, ceny, opisu produktu, statusu zamówienia i dokumentu sprzedaży. Następnie należy zaprojektować kierunki synchronizacji, reakcję na konflikt, ponowienie po błędzie i sposób kontroli rozbieżności. Bez tych decyzji każdy system może działać zgodnie z konfiguracją, a mimo to pokazywać inną cenę, stan lub status.

W skrócie

• Wdrożenie zaczyna się od mapy pól, nie od konektora. Dla każdego pola — stan, cena, tytuł, atrybut, status zamówienia, dokument sprzedaży, zwrot — trzeba wskazać jeden system nadrzędny i jeden kierunek zapisu.
• Rozbieżność stanów może wynikać z projektu albo awarii technicznej. Najpierw trzeba sprawdzić właściciela pola i identyfikatory wariantów, a następnie logi, limity API, kolejkę ponowień i opóźnienia synchronizacji.
• Topologia decyduje o kosztach utrzymania. Sklep ↔ BaseLinker to najprostszy układ; sklep ↔ BaseLinker ↔ ERP przenosi księgowość i dokumenty do systemu finansowego; BaseLinker jako hub dla marketplace dodaje osobne mapowania per kanał.
• Warianty i SKU wymagają osobnego testu. Jeżeli sklep, Base i ERP używają innych identyfikatorów, stan całego produktu może wyglądać poprawnie, choć konkretny rozmiar lub kolor jest błędny.
• Ceny mają więcej niż jedną wartość. Cena podstawowa, promocyjna, cennik B2B i cena per kanał to osobne pola; wrzucenie ich w jedno kończy się sprzedażą po cenie hurtowej w sklepie detalicznym.
• Rezerwacja stanu jest osobną decyzją. Bez ustalenia, w którym momencie zamówienie blokuje towar i który system o tym decyduje, nadsprzedaż jest kwestią czasu, nie pecha.
• Zwroty i korekty rozjeżdżają dane najbardziej. Zwrot dotyka stanu, dokumentu sprzedaży i statusu zamówienia jednocześnie, więc wymaga osobnego przejścia w projekcie.
• Odbiór wymaga danych podobnych do produkcyjnych i kontrolowanego pilotażu. Kilka produktów testowych nie pokaże problemów z wariantami, limitami API, dużą partią zamówień ani przypadkami brzegowymi.
• Wybór narzędzia jest wtórny wobec mapy pól. BaseLinker, alternatywne systemy do obsługi zamówień i integracje natywne platform rozwiązują ten sam problem w innym miejscu — źle zaprojektowana mapa pól psuje każdy z nich.

Ten wpis dotyczy integracji, czyli warstwy, w której dane krążą między systemami. Widoczność sklepu w wyszukiwarce opisuje osobny materiał o pozycjonowaniu sklepu internetowego, a przegląd tego, co jeszcze w sklepie warto sprawdzić przed większym projektem, znajduje się we wpisie o tym, jak wykonać audyt sklepu internetowego.

Dlaczego integracja działa w teście, a zawodzi na produkcji

Test połączenia potwierdza zwykle tylko podstawowy przepływ: zamówienie trafia do Base, a stan wraca do sklepu. Produkcja dodaje równoczesne zmiany, wiele wariantów, zwroty częściowe, przerwy w dostępie do API, limity zapytań i ręczne korekty w ERP. Problem ujawnia się wtedy, gdy projekt nie określa, jak system ma zachować się w takich sytuacjach.

Częstym źródłem rozbieżności jest zapis tego samego pola przez kilka systemów. Sklep może naliczyć promocję, Base przesłać cenę z hurtowni, a ERP opublikować cennik po przeliczeniu marży. Nie oznacza to automatycznie błędu któregoś narzędzia — brakuje reguły rozstrzygającej, która wartość jest wiążąca. Inne przyczyny są czysto techniczne: brak ponowienia odrzuconego żądania, niekompletne mapowanie SKU, zerwany webhook albo błędna obsługa paginacji.

Dlatego projekt zaczyna się od dwóch pytań: kto może zmieniać dane i jak integracja odzyskuje spójność po awarii. Dopiero później wybiera się konektory, harmonogramy i częstotliwość synchronizacji.

Kto jest źródłem prawdy dla którego pola

To sedno całego wdrożenia. Poniższa tabela nie jest gotową konfiguracją do skopiowania — jest listą decyzji, które trzeba podjąć i zapisać, zanim ktokolwiek dotknie konfiguracji. Typowe rozwiązanie zależy od tego, czy firma prowadzi magazyn w ERP, czy w BaseLinkerze, i czy sprzedaje przez marketplace.

Najbezpieczniejszą zasadą domyślną jest jeden system nadrzędny dla jednego pola. Dwukierunkowa integracja często oznacza różne pola płynące w przeciwnych kierunkach: zamówienie trafia ze sklepu do Base, a status i numer przesyłki wracają. Jeżeli ten sam atrybut naprawdę musi być zmieniany w kilku miejscach, projekt potrzebuje jawnej reguły scalania, wersjonowania, kolejności zdarzeń i rejestru konfliktów. Samo ustawienie synchronizacji w obie strony nie rozwiązuje tego problemu.

Trzy topologie integracji

Wybór topologii wynika z tego, gdzie firma faktycznie prowadzi księgowość i magazyn, a nie z tego, co jest wygodniejsze do skonfigurowania.

Sklep ↔ BaseLinker

Najprostszy układ i najczęstszy start. Zamówienia ze sklepu trafiają do BaseLinkera, tam są obsługiwane, tam powstają etykiety i dokumenty, a do sklepu wraca status i numer przesyłki. Stany i ceny mogą być prowadzone w BaseLinkerze i wypychane do sklepu albo odwrotnie — i to jest jedyna istotna decyzja w tej topologii.

Ten układ ma naturalną granicę. Kiedy pojawia się pełna księgowość, magazyn wielolokalizacyjny, cenniki kontrahentów albo produkcja, BaseLinker przestaje być właściwym miejscem na te dane i wchodzi ERP.

Sklep ↔ BaseLinker ↔ ERP

Tu BaseLinker jest warstwą operacyjną: zbiera zamówienia z wszystkich kanałów, obsługuje kompletację i wysyłkę, prowadzi komunikację z klientem. ERP — Subiekt GT, Comarch ERP Optima albo XL, enova365 — jest właścicielem magazynu, dokumentów i rozliczeń. Sklep jest witryną i drugim, obok marketplace, kanałem sprzedaży.

Trzy rzeczy wymagają w tej topologii szczególnej uwagi. Pierwsza: gdzie powstaje dokument sprzedaży i co go wyzwala — opłacenie, wysyłka czy zmiana statusu. Druga: który system rezerwuje towar i kiedy. Trzecia: jak wraca informacja o zwrocie, żeby stan i dokument zmieniły się raz, a nie dwa razy.

Integracja z ERP prawie nigdy nie jest „gotowa z pudełka” bez decyzji. Nawet jeżeli dla danej pary systemów istnieje gotowy konektor, decyzje o polach nadrzędnych, wyzwalaczach dokumentów i obsłudze zwrotów są po stronie wdrażającego.

BaseLinker jako hub dla marketplace

Kiedy dochodzi Allegro, Amazon albo inne marketplace, BaseLinker zwykle staje się miejscem, w którym spotykają się zamówienia z wszystkich kanałów. To sensowny układ — jedna kolejka do obsługi, jedno miejsce na etykiety, jedna historia komunikacji.

Cena za to jest konkretna: każdy kanał ma własne wymagania wobec danych. Allegro operuje własnym modelem parametrów i kategorii, a jego API i regulamin rządzą ofertą niezależnie od tego, co sklep trzyma u siebie. Amazon wymaga własnych identyfikatorów i ma własny model realizacji. To oznacza mapowania per kanał — kategorii, parametrów, jednostek, czasu wysyłki — i osobną decyzję o tym, czy cena na marketplace jest polem niezależnym od ceny sklepowej. Zwykle jest, bo prowizja kanału zmienia rachunek marży. Reklamową stronę tego kanału opisuje przewodnik po Allegro Ads, a rolę samych danych produktowych — wpis o tym, czym jest feed produktowy i jak go wykorzystać.

Słowniczek

• Źródło prawdy — system, którego wartość danego pola jest wiążąca; pozostałe systemy tę wartość tylko odczytują.
• Mapowanie pól — zapisana zgodność między polem w jednym systemie a polem w drugim, razem z kierunkiem zapisu.
• Rezerwacja stanu — zablokowanie towaru pod konkretne zamówienie, żeby nie mógł zostać sprzedany drugi raz przed wysyłką.
• Idempotencja — właściwość operacji, przy której ponowione wywołanie nie tworzy drugiego zamówienia ani drugiego dokumentu.
• Webhook — powiadomienie wysyłane przez system w momencie zdarzenia, zamiast odpytywania go w pętli o zmiany.
• Limit zapytań — maksymalna liczba wywołań API w jednostce czasu. Po przekroczeniu limitu integracja powinna odłożyć operację i ponowić ją zgodnie z odpowiedzią API, bez tworzenia duplikatów.
• PIM — system zarządzania danymi produktowymi, w którym żyją tytuły, opisy, atrybuty i media, jeżeli firma nie trzyma ich w sklepie.
• Kolejka retry — mechanizm ponawiania nieudanych operacji, bez którego jedna awaria sieci trwale rozjeżdża dane.

Pułapki, które ujawniają się dopiero na produkcji

Warianty i SKU

Najczęstsza cicha awaria. Sklep identyfikuje wariant identyfikatorem wewnętrznym, BaseLinker po SKU, ERP po własnym indeksie, a część produktów została kiedyś dodana ręcznie i nie ma SKU wcale. Stany schodzą się wtedy na poziomie produktu, a rozchodzą na poziomie rozmiaru — sklep pokazuje dostępność, bo produkt ma łącznie dziewięć sztuk, ale zamawianego rozmiaru nie ma.

Rozwiązanie jest nudne i wymaga pracy przed wdrożeniem: jedno pole techniczne jako identyfikator wariantu, wypełnione w stu procentach, unikalne, nigdy nierecyklingowane po usunięciu produktu i nigdy niezmieniane, bo zmiana rozmiarówki nie jest zmianą identyfikatora. Każdy produkt bez tego pola trzeba uzupełnić przed startem, a nie „w trakcie”.

Ceny promocyjne i cenniki B2B

Cena nie jest jednym polem. Jest ich zwykle co najmniej pięć: cena bazowa, cena promocyjna, cena przed przekreśleniem, cennik kontrahenta i cena per kanał. Integracja, która mapuje „cenę na cenę”, nadpisuje promocję ceną bazową albo utrwala promocję po zakończeniu akcji.

Osobno wymaga decyzji sprzedaż B2B. Cennik kontrahenta prawie zawsze żyje w ERP, bo jest częścią umowy handlowej. Sklep detaliczny nie powinien mieć prawa go nadpisać, a jednocześnie musi umieć go pokazać zalogowanemu kontrahentowi — to argument za odczytem, nie za dwukierunkowością.

Rezerwacje stanu i nadsprzedaż

Nadsprzedaż wygląda na problem z synchronizacją, a jest problemem z rezerwacją. Trzeba ustalić moment, w którym towar przestaje być dostępny dla innych kupujących: złożenie zamówienia, opłacenie, przyjęcie do kompletacji. Każdy wybór ma inne konsekwencje — rezerwacja przy złożeniu chroni magazyn, ale blokuje towar pod nieopłacone zamówienia, rezerwacja przy opłaceniu odwrotnie.

Do tego dochodzi bufor. Sklep sprzedający równolegle na kilku kanałach, z których każdy odświeża stan w innym rytmie, potrzebuje marginesu na produktach o wysokiej rotacji. To decyzja biznesowa: ile sprzedaży warto oddać, żeby nie anulować zamówień.

Opóźnienia synchronizacji i konflikty zapisu

Synchronizacja nie jest natychmiastowa i nie musi być — musi być zmierzona. Dwie liczby wystarczają: maksymalne dopuszczalne opóźnienie dla stanu i maksymalne dopuszczalne opóźnienie dla ceny. Bez nich „prawie w czasie rzeczywistym” jest tylko zwrotem grzecznościowym.

Konflikt zapisu to sytuacja, w której dwa systemy zapisują to samo pole w tym samym oknie synchronizacji. Bez reguły rozstrzygającej wygrywa ten, który zapisał później, co znaczy, że wynik zależy od kolejności zadań w harmonogramie. Reguła może być prosta — pole ma jednego właściciela, zapisy z innych źródeł są odrzucane i logowane — ale musi istnieć, a odrzucone zapisy muszą być widoczne, bo to one pokazują, gdzie mapa pól jest niezgodna z tym, jak firma naprawdę pracuje.

Osobno trzeba zaplanować obsługę limitów zapytań i ponowień. Aktualna dokumentacja Base podaje limit 100 żądań na minutę, ale wartość i zasady mogą się zmienić, dlatego muszą być odczytywane z dokumentacji na dzień wdrożenia. Żądanie odrzucone lub przerwane nie może po prostu zniknąć. Powinno trafić do kolejki ponowień, zachować identyfikator operacji i po kolejnej próbie nie tworzyć drugiego zamówienia ani dokumentu.

Zwroty, korekty i faktury

Zwrot to najbardziej złożone zdarzenie w całej integracji, bo dotyka trzech rzeczy naraz: stanu magazynowego, dokumentu sprzedaży i statusu zamówienia. Do tego dochodzą przypadki, o których nikt nie myśli na etapie projektu: zwrot części pozycji z zamówienia, zwrot z inną formą płatności niż zakup, wymiana na inny rozmiar zamiast zwrotu pieniędzy, towar wracający uszkodzony i nietrafiający na stan.

Decyzje, które trzeba podjąć: który system tworzy korektę, co wyzwala przyjęcie towaru na magazyn, jak wygląda status zamówienia po częściowym zwrocie i kto odpowiada za zwrot płatności. Dokumenty i korekty najlepiej utrzymywać w systemie wskazanym przez księgowość, z jedną numeracją i kontrolą uprawnień.

W lipcu 2026 roku integracja faktur musi uwzględniać działający KSeF 2.0. Obowiązek wystawiania faktur objął największe firmy 1 lutego 2026 roku, a pozostałych podatników 1 kwietnia 2026 roku, z czasowym wyjątkiem do końca 2026 roku dla podmiotów mieszczących się w ustawowym limicie 10 000 zł miesięcznej sprzedaży dokumentowanej fakturami. Odbieranie faktur przez KSeF jest obowiązkowe od 1 lutego 2026 roku. Szczegółowy zakres trzeba każdorazowo sprawdzić w oficjalnym serwisie Ministerstwa Finansów i potwierdzić z księgowością.

Integracja BaseLinkera z platformą sklepową

Ta sama mapa pól, inne ograniczenia techniczne po stronie sklepu.

BaseLinker i PrestaShop. PrestaShop udostępnia własne webservice API i model danych z kombinacjami wariantów. Kluczowe pytanie brzmi, czy stany prowadzone są per kombinacja i czy identyfikator kombinacji jest stabilny między eksportami. W sklepach z długą historią częstym problemem są produkty utworzone przed wprowadzeniem porządku w SKU oraz moduły, które nadpisują cenę własną regułą.

BaseLinker i WooCommerce. WooCommerce działa na REST API i modelu wariacji produktu. Uwagi wymagają dwa miejsca: wtyczki, które modyfikują cenę lub stan we własnej logice, oraz wydajność przy większej liczbie wariantów, bo synchronizacja idzie wtedy przez wiele wywołań. Kiedy sklep na WooCommerce zaczyna być wąskim gardłem integracji, wraca pytanie o platformę — kontekst tej decyzji opisuje wpis o tym, czy warto założyć sklep na WordPressie z WooCommerce.

BaseLinker i Shoper. Shoper jako platforma SaaS udostępnia własne API, ale zakres pól i możliwość ingerencji w logikę są węższe niż w rozwiązaniach, w których kod należy do sklepu. To zwykle nie problem, dopóki wymagania są standardowe; staje się problemem, gdy pojawia się nietypowa logika cenowa albo własny model wariantów.

Sklep dedykowany. W sklepie budowanym na miarę integracja przestaje być kompromisem z ograniczeniami platformy — pola, kierunki zapisu i reguły konfliktów projektuje się razem z resztą systemu. Tak podchodzimy do tworzenia sklepów internetowych z integracjami opisanymi na starcie, gdzie sekcja integracji obejmuje BaseLinkera, ERP, płatności i logistykę, a decyzja o systemie nadrzędnym dla każdego pola jest częścią projektu, nie ustaleniem po fakcie.

Integracja BaseLinkera z Subiektem GT i innymi systemami ERP

Połączenie BaseLinkera z Subiektem GT to jedno z najczęściej zamawianych wdrożeń w polskim e-commerce i zwykle jest to integracja pośrednia — przez dedykowany łącznik działający po stronie serwera albo maszyny, na której stoi Subiekt. Wynika to z architektury: Subiekt GT jest aplikacją desktopową z bazą po stronie firmy, nie usługą chmurową z publicznym API.

To ma trzy praktyczne konsekwencje. Pierwsza: integracja ma dodatkowy element, który może przestać działać — usługę łącznika, jej dostępność i logi trzeba monitorować osobno. Druga: częstotliwość synchronizacji jest ograniczona wydajnością bazy, więc „co minutę” nie zawsze jest realistyczne, a to wraca do decyzji o dopuszczalnym opóźnieniu stanu. Trzecia: zmiany w bazie ERP robione ręcznie przez księgowość albo magazyn są normalną praktyką i integracja musi je znieść, a nie traktować jako anomalię.

Comarch ERP Optima i XL oraz enova365 mają inne mechanizmy integracji niż Subiekt GT, ale decyzje projektowe pozostają podobne: kto jest właścicielem stanu, co wyzwala dokument, jak wraca zwrot i gdzie utrzymywane są cenniki kontrahentów. Nazwa ERP zmienia sposób realizacji, nie zestaw pytań.

BaseLinker a alternatywy

Wybór narzędzia jest wtórny wobec mapy pól, ale nie jest bez znaczenia. Poniższe zestawienie porównuje kategorie rozwiązań, nie punktuje produktów — każde z nich sprawdza się w innym układzie.

Uczciwe porównanie kosztów wymaga zajrzenia do aktualnych cenników, bo modele rozliczeń w tej kategorii są zmienne i zależą od liczby zamówień, kanałów i użytkowników. To samo dotyczy limitów API — konkretne wartości warto sprawdzić w dokumentacji na dzień wdrożenia i wpisać do projektu jako założenie, a nie przepisywać z artykułu.

Jak podchodzimy do tego w Space Ads

Zaczynamy od mapy pól przygotowanej wspólnie z osobami odpowiedzialnymi za magazyn, sprzedaż i księgowość. Dla każdego atrybutu zapisujemy system nadrzędny, kierunek synchronizacji, dopuszczalne opóźnienie oraz reakcję na konflikt. Następnie kontrolujemy identyfikatory produktów i wariantów, ponieważ bez stabilnego mapowania nie da się wiarygodnie synchronizować stanów. Zwroty, korekty i awarie projektujemy jako pełne procesy, a nie wyjątki dopisywane po starcie. Wdrożenie przechodzi pilotaż na danych zbliżonych do produkcyjnych i testy przypadków brzegowych: częściowego zwrotu, wymiany, zamówienia z kilku magazynów, przerwy w łączności oraz ponowienia żądania. Pełny ruch włączamy dopiero po uzgodnieniu wyników odbioru i sposobu monitorowania rozbieżności.

Plan wdrożenia krok po kroku

1. Spisać kanały i systemy. Sklep, marketplace, hurtownie, ERP, WMS, system księgowy, CRM, narzędzie do wysyłek. Wszystko, co dotyka zamówienia albo stanu.
2. Zbudować mapę pól. Dla każdego pola z tabeli wyżej wskazać system nadrzędny, kierunek zapisu i regułę konfliktu. To dokument, który podpisują osoby odpowiedzialne za magazyn i księgowość, nie notatka wdrożeniowca.
3. Uporządkować identyfikatory. Jedno pole jako identyfikator wariantu, wypełnione w stu procentach, unikalne, stabilne. Produkty bez identyfikatora uzupełnić przed startem.
4. Ustalić model cen. Które ceny istnieją, gdzie żyje każda z nich, kto ma prawo nadpisać, jak działa promocja i jak cennik B2B.
5. Zdecydować o rezerwacji stanu. Moment blokady towaru, bufor na produktach o wysokiej rotacji, zachowanie przy nieopłaconym zamówieniu.
6. Zaprojektować przepływ zamówienia. Od utworzenia przez statusy i wysyłkę do dokumentu; wskazać wyzwalacz każdego kroku i system, który go wykonuje.
7. Zaprojektować przepływ zwrotu. Zwrot pełny i częściowy, wymiana, towar uszkodzony, korekta dokumentu, zwrot płatności.
8. Zaplanować odporność. Kolejka ponowień, obsługa limitów zapytań, logowanie odrzuconych zapisów, alert przy przekroczeniu progu opóźnienia.
9. Uruchomić na ograniczonym zakresie. Jedna kategoria albo jeden magazyn, prawdziwe zamówienia, pełny monitoring. Rozjazdy szuka się tu, nie po pełnym starcie.
10. Przeprowadzić odbiór według checklisty. Dopiero po jego zamknięciu włączyć pełny ruch i wyłączyć procesy ręczne, które integracja zastępuje.

Checklista testów akceptacyjnych na prawdziwych danych

• Zamówienie ze sklepu pojawia się w BaseLinkerze raz, z kompletem pozycji, wariantów i danych do wysyłki.
• Zamówienie z marketplace pojawia się w tej samej kolejce, z poprawnym mapowaniem parametrów i ceny właściwej dla kanału.
• Stan po sprzedaży spada w systemie nadrzędnym i schodzi na wszystkich kanałach w zadeklarowanym czasie.
• Stan wariantu, nie tylko produktu, jest poprawny po sprzedaży skrajnego rozmiaru.
• Cena promocyjna utrzymuje się przez cały czas akcji i wraca do bazowej po jej zakończeniu, bez ręcznej interwencji.
• Zalogowany kontrahent B2B widzi cenę ze swojego cennika, a klient detaliczny jej nie widzi.
• Status zamówienia i numer przesyłki wracają do sklepu i do klienta, bez cofania statusu przy kolejnej synchronizacji.
• Dokument sprzedaży powstaje raz, w jednym systemie, z poprawną numeracją i przypisaniem do zamówienia.
• Zwrot częściowy zmienia stan, dokument i status zgodnie z projektem, a towar wraca na magazyn dokładnie raz.
• Wymiana rozmiaru przechodzi ścieżkę zaprojektowaną dla wymiany, a nie ścieżkę zwrotu i nowego zamówienia, jeżeli tak ustalono.
• Zamówienie złożone dwa razy z powodu ponowienia wywołania nie tworzy dwóch zamówień ani dwóch dokumentów.
• Przekroczenie limitu zapytań kończy się ponowieniem, nie utratą zdarzenia; w logu widać ponowienie.
• Ręczna zmiana stanu w ERP przez magazyn propaguje się na kanały i nie jest nadpisywana przez poprzednią wartość.
• Wyłączenie łącznika na godzinę i ponowne włączenie kończy się dogonieniem zaległości, bez duplikatów.
• Zamówienie z produktem z dwóch magazynów rozdziela się zgodnie z regułą realizacji.
• Raport rozjazdów stanu za dobę jest pusty albo zawiera wyłącznie pozycje z wyjaśnioną przyczyną.

Częsty błąd → co zrobić zamiast tego

Najczęstsze pytania

Czym jest integracja BaseLinkera ze sklepem?

Integracja BaseLinkera ze sklepem to wymiana danych o produktach, stanach, cenach i zamówieniach między sklepem internetowym a BaseLinkerem, w której dla każdego pola ustalony jest system nadrzędny i kierunek zapisu. Sama łączność techniczna to mniejsza część pracy; większą jest decyzja, który system jest właścicielem którego pola i co dzieje się przy konflikcie zapisu.

Ile trwa wdrożenie BaseLinkera?

Czas zależy przede wszystkim od stanu danych produktowych i liczby kanałów, a nie od samego podłączenia. Sklep z kompletnymi identyfikatorami wariantów, jednym magazynem i jednym kanałem jest gotowy szybko. Sklep z niepełnymi SKU, kilkoma cennikami, ERP i sprzedażą na marketplace wymaga osobnej pracy nad danymi przed startem, i to ona zwykle decyduje o harmonogramie.

Który system powinien być źródłem prawdy dla stanów magazynowych?

Ten, w którym fizycznie prowadzony jest magazyn. Jeżeli firma używa ERP albo WMS z realnym stanem, to on jest nadrzędny, a BaseLinker i sklep odczytują wartość. Jeżeli magazyn prowadzony jest w BaseLinkerze, to on jest nadrzędny. Kluczowe jest, żeby właścicielem był jeden system i żeby pozostałe nie miały prawa zapisu tego pola.

Czy BaseLinker integruje się z Subiektem GT?

Tak, ale zwykle pośrednio — przez dedykowany łącznik działający po stronie firmy, ponieważ Subiekt GT jest aplikacją desktopową z lokalną bazą danych, a nie usługą z publicznym API. W praktyce oznacza to dodatkowy element do monitorowania oraz częstotliwość synchronizacji ograniczoną wydajnością bazy, co należy uwzględnić w dopuszczalnym opóźnieniu stanu.

Jak wygląda integracja BaseLinkera z PrestaShop i WooCommerce?

Obie platformy udostępniają własne API i model wariantów: PrestaShop przez webservice i kombinacje, WooCommerce przez REST API i wariacje. Uwagi wymagają stabilność identyfikatorów wariantów oraz wtyczki i moduły, które modyfikują cenę lub stan własną logiką, bo to one najczęściej nadpisują wartości pochodzące z integracji.

Apilo czy BaseLinker — co wybrać?

Oba narzędzia rozwiązują ten sam problem obsługi zamówień wielokanałowej, więc wybór zwykle sprowadza się do pokrycia konkretnych kanałów, hurtowni i kurierów używanych przez firmę oraz do modelu rozliczenia przy jej wolumenie zamówień. Decyzja o narzędziu ma jednak mniejszy wpływ na stabilność niż mapa pól — źle zaprojektowane źródło prawdy rozjeżdża dane w każdym z tych systemów.

Dlaczego stany magazynowe rozjeżdżają się po integracji?

Przyczyną mogą być dwa systemy zapisujące to samo pole, niekompletne identyfikatory wariantów, błędna reguła rezerwacji, opóźnienie synchronizacji albo utracone wywołanie API. Diagnoza powinna połączyć mapę właścicieli danych z logami, kolejką ponowień i raportem rozbieżności. Bez tego nie da się odróżnić błędu projektu od awarii technicznej.

Czy warto włączyć dwukierunkową synchronizację?

Dwukierunkowość ma sens dla różnych pól w różnych kierunkach — zamówienie płynie ze sklepu, a status i numer przesyłki wracają. Jeżeli ten sam atrybut ma być zmieniany w obu systemach, potrzebna jest jawna reguła scalania, wersjonowania i obsługi konfliktów. Bez niej synchronizacja stanu w obie strony jest ryzykowna.

Jakie są limity API BaseLinkera?

Dokumentacja API Base podaje obecnie limit 100 żądań na minutę. Wartość trzeba ponownie sprawdzić przed wdrożeniem, ponieważ może się zmienić. Integracja powinna reagować na odrzucenie żądania kolejką ponowień, kontrolowanym odstępem między próbami i idempotencją, aby kolejna próba nie utworzyła duplikatu.

Najważniejsze

• Integracja BaseLinkera ze sklepem i ERP stoi na jednym pytaniu: który system jest źródłem prawdy dla którego pola — jedno pole ma jednego właściciela i jeden kierunek zapisu, a dwukierunkowość dotyczy różnych pól, nie tego samego pola w obie strony.
• Topologia wynika z tego, gdzie firma prowadzi magazyn i księgowość: sklep ↔ BaseLinker, sklep ↔ BaseLinker ↔ ERP albo BaseLinker jako hub dla marketplace.
• Warianty i SKU są krytycznym punktem kontroli; identyfikator wariantu powinien być kompletny, unikalny i stabilny przed startem.
• Ceny to kilka osobnych pól — bazowa, promocyjna, cennik B2B, cena per kanał — a mapowanie ich w jedno kończy się sprzedażą po złej cenie.
• Rezerwacja stanu, dopuszczalne opóźnienie i reguła konfliktu zapisu to decyzje do podjęcia przed wdrożeniem, nie po pierwszym incydencie.
• Zwroty i korekty wymagają osobnego projektu, bo dotykają stanu, dokumentu sprzedaży i statusu zamówienia jednocześnie.
• Odbiór wdrożenia robi się na prawdziwych danych i przypadkach brzegowych; testy na produktach demo nie wykryją ani limitów API, ani konfliktów zapisu.

Źródła i dalsza lektura

• Base — dokumentacja API
• Allegro — dokumentacja REST API
• Amazon — Selling Partner API
• WooCommerce — REST API documentation
• PrestaShop — DevDocs (Webservice API)
• Ministerstwo Finansów — etapy wdrożenia KSeF 2.0

Zakres funkcji, limity API i modele rozliczeń narzędzi zmieniają się w czasie — to stan na lipiec 2026, więc przed wdrożeniem należy sprawdzić aktualną dokumentację z linków powyżej.

Czytaj dalej

• Zakupy przez asystenta AI — co to znaczy dla sklepu
• Czym jest feed produktowy i jak go wykorzystać
• Jak wykonać audyt sklepu internetowego
• Pozycjonowanie sklepu internetowego: SEO e-commerce od podstaw
• Allegro Ads 2026 — kompletny przewodnik
• Dedykowane sklepy internetowe z integracjami