Integracja sklepu z IAI Shop / IdoSell - kiedy i jak

IdoSell jako sklep vs kanał

Pierwsze pytanie, które zadaję, gdy klient pyta o IdoSell na potrzeby B2B, brzmi: czy IdoSell ma być całym sklepem, czy jednym z kanałów. Te dwie role wymagają zupełnie różnej architektury i prowadzą do różnych decyzji budżetowych.

W roli głównego sklepu IdoSell trzyma cały katalog, cenniki, kartoteki klientów i obsługę. To najtańsza ścieżka startowa - aktywujesz pakiet, dostajesz gotową stronę z koszykiem, panelem klienta, integracjami płatności i kurierów. Dla małej hurtowni schodzącej do e-commerce z dwoma cennikami (hurt, detal) i kilkoma setkami klientów to działa. Próg bólu pojawia się przy cennikach kontraktowych z formułami, multi-buyerze w jednym kontrahencie z osobnymi limitami i procedurze akceptacji zamówień powyżej limitu kredytowego. Customizacja IdoSell idzie tylko tam, gdzie producent przewidział pole konfiguracyjne. Jak nie ma - nie ma.

W roli kanału IdoSell żyje obok własnego sklepu B2B (Magento, Shopware, własny custom). Sklep B2B obsługuje klientów kontraktowych z pełnym cennikiem indywidualnym, procesem akceptacji i integracjami ERP po API. IdoSell przejmuje B2C i drobnych klientów detalicznych, dla których prostszy interfejs jest plusem, a brak zaawansowanych funkcji B2B nie przeszkadza. Wspólne źródło danych to PIM albo ERP, dwa sklepy są synchronizowane do tego samego stanu magazynowego.

Decyzja zwykle wychodzi z proporcji obrotów. Firmy z czystym B2B (powyżej 80% sprzedaży kontraktowej) idą własnym sklepem, ewentualnie z marketplace jako dodatkowym kanałem. Firmy z miksem B2B i B2C robią dwa sklepy zoptymalizowane pod osobnego klienta - jeden checkout z fakturą i terminem zapłaty, drugi z paczkomatem i BLIK-iem.

Custom vs SaaS dla sklepu B2B - szersza decyzja platformowa.

API IdoSell - możliwości i limity

IdoSell wystawia rozbudowane REST API pod marką IAI Open API. Pokrywa większość operacji potrzebnych w integracji - katalog, stany, cenniki, klientów, zamówienia, koszyki, płatności. Autoryzacja idzie API kluczem przypisanym do panelu administracyjnego, z możliwością ograniczenia scope per metoda. Klucze nie wygasają same, regenerujesz je z panelu, gdy zachodzi potrzeba.

Endpointy, których realnie używasz w integracji B2B, mieszczą się w siedmiu kategoriach. /products to katalog z pełnym CRUD-em. /products/stocks zwraca stany magazynowe. /products/prices obsługuje cenniki katalogowe i indywidualne. /clients to kartoteka klientów wraz z grupami cenowymi. /orders daje odczyt i aktualizację statusów zamówień. /baskets pokazuje koszyki klientów w toku. /payments to obsługa płatności.

Limity są ważniejsze, niż się wydaje. Domyślnie 100 requestów na minutę - dla synchronizacji 30 tys. produktów to wąskie gardło, bo pełen pull katalogu zajmuje przy paginacji po 100 rekordów co najmniej 5 godzin. Można zamówić zwiększenie do 1000 requestów na minutę, ale to płatny dodatek i warto wkalkulować w TCO. Webhooks działają na nowe zamówienie, zmianę statusu i odbiór płatności - tyle, ile potrzebujesz w 80% scenariuszy.

Czego w API brakuje i co potrafi zaboleć przy projektowaniu integracji: API do quick order z importem CSV, API do konfiguratora produktu (jeśli sklep go używa), API do dynamicznych formuł cenowych - cenniki są wyłącznie statyczne, oraz webhook na zmianę stanu magazynowego (zmiany stanu są wykrywane tylko pośrednio przez zmianę statusu zamówienia). Te luki załatwiasz pollingiem co kilka minut, ale dla sklepu z towarem unikatowym to za wolno.

IdoSell daje 14-30 dni testowego panelu dla developerów. To wystarcza na proof of concept integracji, ale realistyczny pełen test E2E z PIM-em i ERP-em wymaga przedłużenia.

Synchronizacja produktów

Pytanie fundamentalne, które trzeba rozstrzygnąć przed napisaniem pierwszej linijki integracji: gdzie jest źródło prawdy o katalogu. To nie jest decyzja techniczna, to decyzja organizacyjna i często boli, bo źle wybrane źródło tworzy proces, w którym handlowcy edytują dane w trzech miejscach na raz.

Pierwszy wariant - IdoSell jest źródłem. Wszystkie edycje produktów (nazwy, opisy, atrybuty, zdjęcia) leżą w IdoSell, a inne systemy (ERP, własny sklep B2B) ciągną z niego cyklicznie. Plus jest prostota: jeden panel, do którego ma dostęp dział merchandisingu. Minus - PIM IdoSella ma ograniczenia. Mało pól własnych, brak rozbudowanej hierarchii atrybutów, słabe wsparcie wariantów. Dla katalogu z 50 atrybutami per SKU to się nie nadaje.

Drugi wariant - źródłem jest ERP albo dedykowany PIM (Akeneo, Pimcore), a IdoSell to kanał. Edycje wykonywane są w ERP-ie (Comarch, Subiekt, enova) albo w PIM-ie, synchronizacja do IdoSella idzie przez API. Plus - pełna kontrola nad strukturą danych, możliwość rozbudowanej taksonomii. Minus - trzeba zbudować i utrzymać pipeline synchronizacji, plus dodatkowy moving part w architekturze.

Dla typowej hurtowni z 10 tys. SKU i więcej praktyka pokazuje, że wariant drugi jest jedyny sensowny. PIM zostaje źródłem, IdoSell dostaje wybrany subset pól potrzebnych do prezentacji i sprzedaży, reszta danych zostaje w PIM. Pipeline wygląda zwykle tak:

PIM (Akeneo) → Middleware → IdoSell API
                         → Własny sklep B2B
                         → Marketplace (Allegro, Amazon)

Middleware jako warstwa pośrednia ma sens, bo każdy kanał ma swój dialekt API i własne wymagania mapowania - próba spinania tego "każdy z każdym" generuje N na N połączeń i kończy się katastrofą po dodaniu trzeciego kanału.

PIM Akeneo w sklepie B2B - jeśli PIM jest źródłem prawdy.

Zamówienia z IdoSell do własnego OMS

Kiedy IdoSell jest kanałem, każde zamówienie z niego musi trafić do wspólnego OMS-a lub ERP-a, żeby księgowość, magazyn i obsługa klienta widziały jedno źródło prawdy. Robi się to webhookiem - IdoSell wystrzela POST do twojego endpointu na każde nowe zamówienie:

POST /webhook/idosell/order
{
  "order_id": "IDO-12345",
  "client_id": "CLI-998",
  "products": [
    {"sku": "ART-001", "qty": 5, "price": 49.99}
  ],
  "shipping": "kurier_dpd",
  "payment": "online_card",
  "total": 254.95
}

Po stronie middleware'a robię cztery mapowania. Numer zamówienia IdoSella przekładam na numer w OMS-ie z prefiksem, żeby dało się rozróżnić źródło. Klienta IdoSella mapuję do kontrahenta w ERP-ie - albo 1:1 przez wcześniej zsynchronizowany ID, albo przez email jako fallback (z ryzykiem, że ktoś założy konto z tym samym mailem osobno). Produkty muszą się zgadzać SKU - dlatego synchronizacja produktów jest fundamentem, bez niej nic dalej nie pójdzie. Statusy idą dwukierunkowo: OMS aktualizuje status "wysłane" i to wraca do IdoSella, żeby klient widział to w swoim panelu.

Trzy klasyczne pułapki. Pierwsza - IdoSell ma własne statusy zamówień (kilkanaście) i próba mapowania 1:1 do OMS-u kończy się tym, że jeden klient widzi "w realizacji", a drugi "w obsłudze" dla tej samej sytuacji. Robię tabelę mapowania z 4-6 docelowymi statusami, w które wpadają wszystkie warianty IdoSella. Druga - zwroty i reklamacje mają osobny workflow, który łatwo zgubić, jeśli OMS nie wie o nich. Webhook na zwrot to drugi endpoint, którego nie wolno pominąć. Trzecia - płatności. IdoSell często pobiera od klienta i przekazuje, ale faktura wystawiana jest z ERP-u twojej firmy. Trzeba rozliczyć w księgowości, kto komu co przekazał - i to musi być widoczne w obu systemach.

Cenniki B2B w IdoSell

IdoSell ma cenniki indywidualne, ale ich ograniczenia są realnym kryterium decyzyjnym, czy zostać na platformie. Tu warto być konkretnym, bo to obszar, w którym sprzedażowcy IdoSella zwykle mówią "tak, mamy cenniki B2B", a po stronie technicznej okazuje się, że to co innego niż klient potrzebuje.

Co IdoSell faktycznie umie. Cenniki per grupa klientów - "Hurt", "Detal", "Premium" - z możliwością przypisania klienta do grupy. Indywidualne ceny per produkt per klient, ale w skali tysięcy pozycji, nie milionów. Progi cenowe ilościowe (kup 100, cena niższa, kup 500, jeszcze niższa). Rabaty procentowe na poziomie klienta jako dodatek do cennika.

Czego nie umie, albo umie tak słabo, że szybciej obejść niż walczyć. Dynamicznych formuł cenowych typu "cena = bazowa razy marża zależna od kategorii i ilości plus opłata środowiskowa" - IdoSell przyjmuje tylko statyczne wartości pozycji cennika. Cenników kontraktowych z walidacją terminową (cena obowiązuje od 1 stycznia do 30 czerwca, potem wraca poprzednia) - można obejść uzupełniając ręcznie, ale to praca, której nikt nie chce powtarzać co kwartał. Skomplikowanych reguł rabatowych z drzewem decyzyjnym ("jeśli klient z grupy A i koszyk zawiera trzy produkty z kategorii X, rabat dodatkowy 5%"). Cenników zależnych od kombinacji atrybutów (rozmiar XL plus kolor czerwony - cena inna niż XL plus zielony, dla tego samego SKU bazowego).

Wniosek pragmatyczny: dla typowego B2B z paroma grupami cenowymi i kilkoma tysiącami indywidualnych pozycji IdoSell się sprawdzi. Dla zaawansowanego B2B z formułami, wymiarami cenowymi i procesami akceptacji ofert - własny sklep z osobnym silnikiem cenowym po stronie aplikacji.

Cenniki kontraktowe per kontrahent - co realnie potrzebuje zaawansowane B2B.

Migracja z IdoSell na własny sklep

Najczęstszy scenariusz, który spotykam: firma wystartowała na IdoSell, urosła, ograniczenia B2B zaczynają tamować rozwój. Pojawia się duży klient z wymaganiem cenników z formułami albo PunchOut-em, którego IdoSell nie obsługuje. Decyzja o migracji rodzi się w bólach, bo zespół już zna platformę, a zmiana to ryzyko.

Plan migracji robię w czterech etapach. Pierwszy to eksport danych z IdoSella - przez API IAI dostępne są metody eksportu produktów, klientów i historii zamówień. Pełen eksport sklepu z 50 tys. produktów trwa godziny, nie minuty (limit 100 requestów na minutę albo płatne 1000 - liczę pod swoje okno). Eksportuję wszystko: produkty z atrybutami, obrazy, kategorie, klientów z grupami cenowymi, historię zamówień minimum z ostatniego roku.

Drugi etap to mapowanie do nowej platformy. Struktura atrybutów IdoSella różni się od Magento i Shopware - trzeba zrobić tabelę przekładów. Obrazy są hostowane przez IdoSell, w nowej platformie potrzebują rebuilda URL-i i ponownego importu do własnego storage. Klienci mają hashe haseł, które nie są kompatybilne z innymi platformami (każda ma swój algorytm), więc przy pierwszym logowaniu klient musi zresetować hasło. To wymaga komunikacji wcześniej, inaczej widzisz 30% spadek logowań w pierwszym tygodniu.

Trzeci etap to cutover. IdoSell przełączam w tryb tylko do odczytu, żeby klienci wciąż widzieli historię, ale nie składali nowych zamówień. Redirecty z URL-i IdoSella na nowe URL-e w nowej platformie (mapowanie ręczne dla kluczowych stron, 301 globalne dla produktów). Komunikacja do klientów wychodzi z dwutygodniowym wyprzedzeniem - mailem, w panelu, na fakturze. Bez tej komunikacji w pierwszym tygodniu 30% klientów dzwoni "sklep zniknął".

Czwarty etap to hypercare. Monitoring sprzedaży dzień po dniu vs trend sprzed migracji, bo ważne, żeby wcześnie wykryć regresję. Wsparcie klientów, którzy nie umieją się zalogować - typowo 10-20% potrzebuje pomocy z resetem hasła i wyłapaniem zmiany. Dział obsługi ma w tym okresie tygodniowe nadgodziny - planuję to w budżecie migracji.

Realny czas: 3-4 miesiące dla średniej hurtowni, do 6 miesięcy dla zaawansowanego B2B z dużą bazą historycznych zamówień i kustomizacjami w IdoSell.

Plan cutover migracji - analogiczne podejście dla migracji platform sklepowych.

FAQ

Czy IdoSell nadaje się do B2B z cennikami kontraktowymi? Dla podstawowego B2B - grupy cenowe, kilka tysięcy indywidualnych pozycji, rabaty progowe - tak. Dla zaawansowanego B2B z formułami, dynamicznymi rabatami zależnymi od koszyka, integracjami ERP z dwukierunkową synchronizacją cenników - lepiej własny sklep ze swoim silnikiem cenowym. Próg leży gdzieś między 5 a 50 tys. pozycji indywidualnych w cenniku, w zależności od skomplikowania reguł.

Czy mogę używać IdoSell tylko jako kanału sprzedaży? Tak, IdoSell pełni rolę punktu sprzedaży, a źródło prawdy o produktach i klientach żyje gdzie indziej (PIM, ERP). Wymaga zbudowania pipeline'u synchronizacji i ustalenia, gdzie zachodzą zmiany. Najczęściej spotykany setup: PIM jako źródło, middleware jako warstwa mapująca, IdoSell jako jeden z kanałów konsumujących dane.

Ile kosztuje IdoSell dla katalogu 30k SKU? Pakiet IdoSell PRO z odpowiednią liczbą slotów produktów to typowo 800-2000 zł miesięcznie. Plus dodatki: zwiększony limit API (z 100 do 1000 req/min jest płatne), miejsce na obrazy, prowizje od integracji płatności. Pełna kalkulacja zależy od ruchu i wolumenu, ale dla średniej hurtowni 1500-3000 zł miesięcznie to realistyczny przedział.

Czy IdoSell może być częścią headless e-commerce? Częściowo. API IdoSella pozwala na większość operacji, ale platforma jest zaprojektowana jako monolit z własnym frontendem. Próba zbudowania headless setup-u "front w Next.js, IdoSell jako headless backend" działa, ale tracisz dużą część wartości platformy (gotowy frontend, panel klienta). Dla pełnego headless lepiej wybrać Shopware albo Magento z dedykowanym headless setup-em.

Czy IdoSell obsłuży 100k SKU? Technicznie tak, ale UX panelu zaczyna kuleć powyżej 50 tys. SKU - filtrowanie wolne, masowe edycje przez UI mało praktyczne, raporty czasem nie ładują się przy dużych zbiorach. Dla katalogu 100 tys. plus rozsądniej wybrać platformę zaprojektowaną pod skalę albo trzymać dane w PIM-ie, a w IdoSell synchronizować tylko aktywny subset.

Co dalej

• Integracje e-commerce: Integracje e-commerce B2B
• Wybór platformy: Jak wybrać platformę e-commerce B2B
• Custom vs SaaS: Custom vs SaaS dla sklepu B2B