Zestawy elastyczne Allegro — start 10 czerwca 2026, jak działają

Allegro 10 czerwca 2026 włączy zestawy elastyczne (flexible bundles) — nowy mechanizm łączenia ofert w bundle, który zastąpi dotychczasowe zestawy ofert. Pierwotnie funkcja miała ruszyć w drugiej połowie kwietnia, ale w komunikacie z 7 maja 2026 Allegro przesunęło datę o około 6 tygodni. Sandbox dla integracji jest dostępny od 29 stycznia 2026 — sprzedawcy mają więc ponad 4 miesiące testów przed włączeniem produkcji. Razem z nowymi endpointami /sale/flexible-bundles Allegro wyłącza cały stary zasób /sale/bundles i automatycznie migruje istniejące zestawy.

Najważniejsza zmiana, której nie ma w dokumentacji ani jednym zdaniem: kupujący zyskuje wybór. W dotychczasowych bundle dostawał gotową, sztywną kombinację 2-9 ofert. W zestawach elastycznych sprzedawca definiuje grupowe sloty, w każdym slocie umieszcza listę alternatywnych ofert, a kupujący wybiera po jednej z każdego slotu. Drugi przełom — rabaty procentowe (zamiast kwotowych) z możliwością ustawienia różnej zniżki per slot. Trzeci — możliwość utworzenia jednej akcji bundle dla wielu różnych produktów naraz (zamiast tworzyć osobny bundle dla każdej pary ofert).

Ten artykuł pokazuje konkretnie: jak działa mechanizm grupowych slotów, jak wygląda request body w nowym API, jakie endpointy znikają i co przygotować w integracji ERP / BaseLinker przed 10 czerwca. Kalkulator pomoże policzyć rentowność bundle przy obu typach rabatu (WHOLE_BUNDLE_DISCOUNT vs SLOT_DISCOUNT).

Spis treści

1. Co dokładnie zmienia się 10 czerwca 2026
2. Group slots — jak działa nowy mechanizm
3. Stare bundle vs flexible bundles — porównanie
4. Nowe REST endpointy /sale/flexible-bundles
5. Rabaty: WHOLE_BUNDLE_DISCOUNT vs SLOT_DISCOUNT
6. Migracja istniejących zestawów — co się stanie
7. Co przygotować przed 10 czerwca — checklist dla integracji
8. Kalkulator: rentowność bundle przy obu typach rabatu
9. Czego dokumentacja Allegro NIE mówi (i co warto sprawdzić)
10. Często zadawane pytania

Co dokładnie zmienia się 10 czerwca 2026

Allegro wprowadziło zestawy ofert (offer bundles) jako stałą funkcjonalność platformy w 2018 roku. Mechanizm pozwalał sprzedawcom łączyć od 2 do 9 ofert w jeden zestaw ze zniżką, którą kupujący nabywał w całości. Każdy zestaw był sztywną kombinacją — kupujący nie mógł podmienić żadnej oferty w środku.

29 stycznia 2026 Allegro ogłosiło zestawy elastyczne na Developer Portal: nową generację mechanizmu z grupowymi slotami, możliwością wymiany ofert przez kupującego i rabatami procentowymi. Pierwotnie wdrożenie planowano na drugą połowę kwietnia 2026 — ale 7 maja 2026 Allegro opublikowało aktualizację z przesuniętą datą: 10 czerwca 2026.

Co konkretnie się zmienia tego dnia:

• Wyłączenie 5 endpointów REST API: cały zasób /sale/bundles znika
• Włączenie 5 nowych endpointów: /sale/flexible-bundles startuje na produkcji
• Automatyczna migracja istniejących zestawów: Allegro przepisze stare bundle do nowej struktury (proces opisany w komunikacie jako "process migracji istniejących zestawów ofertowych")
• Nowy model rabatów: procentowy zamiast kwotowego, z dwoma trybami (WHOLE_BUNDLE_DISCOUNT, SLOT_DISCOUNT)
• Nowe pole entryPoint w slotach — kontroluje czy bundle pojawia się na stronie konkretnej oferty
• Pole requiredQuantity — wymagana liczba sztuk z danego slotu (np. 2 sztuki obudowy)

Sandbox API jest otwarty od 29 stycznia 2026 — sprzedawcy z własną integracją mają ponad 4 miesiące na testy przed włączeniem produkcji. To znacznie dłużej niż przy wcześniejszych zmianach API (typowo 4-8 tygodni).

Oś czasu wdrożenia

Group slots — jak działa nowy mechanizm

To centralna zmiana modelu danych. W dotychczasowych bundle struktura była prosta:

Bundle
  ├─ Oferta A (sztywna)
  ├─ Oferta B (sztywna)
  └─ Rabat kwotowy 30 zł

W zestawach elastycznych pojawia się pojęcie slotu — segmentu bundle z własną listą alternatyw:

Flexible bundle
  ├─ Slot 0 (entryPoint: true, requiredQuantity: 1)
  │   ├─ Oferta A1 (telefon iPhone 15)
  │   ├─ Oferta A2 (telefon iPhone 15 Pro)
  │   └─ Oferta A3 (telefon iPhone 15 Pro Max)
  │       — kupujący wybiera JEDNĄ
  ├─ Slot 1 (requiredQuantity: 2)
  │   ├─ Oferta B1 (etui czarne)
  │   ├─ Oferta B2 (etui granatowe)
  │   └─ Oferta B3 (etui białe)
  │       — kupujący wybiera JEDNĄ, dostaje 2 sztuki
  └─ Slot 2 (entryPoint: false)
      ├─ Oferta C1 (ładowarka 20W)
      └─ Oferta C2 (ładowarka 30W)

Kupujący, klikając "kup w zestawie", wybiera po jednej ofercie z każdego slotu. To diametralna zmiana doświadczenia zakupowego — zamiast sztywnej kombinacji dostaje konfigurator.

Struktura request body — przykład z dokumentacji

Allegro w newsie publikuje przykład JSON który ilustruje mechanikę:

{
  "slots": [
    {
      "order": 0,
      "entryPoint": true,
      "requiredQuantity": 2,
      "offers": [
        {
          "id": "1240124104",
          "excludedFromDiscount": false
        }
      ]
    }
  ],
  "discount": {
    "type": "SLOT_DISCOUNT"
  }
}

Pola w slocie:

• order — kolejność wyświetlania slotu w bundle (integer, 0-indexed)
• entryPoint — czy bundle jest widoczny na stronie konkretnej oferty z tego slotu (boolean). Typowo true dla slotu z produktem głównym, false dla akcesoriów
• requiredQuantity — liczba sztuk z danego slotu, którą kupujący musi nabyć (integer, np. 2 etui)
• offers — tablica ofert alternatywnych dostępnych w slocie
• offers[].id — identyfikator oferty Allegro
• offers[].excludedFromDiscount — czy konkretna oferta w slocie jest wykluczona z rabatu (boolean)

Co znaczy entryPoint: true

To pole kontroluje widoczność bundle. Jeśli oferta jest w slocie z entryPoint: true, bundle pojawia się na stronie tej oferty w sekcji "Kup w zestawie". Jeśli entryPoint: false, oferta uczestniczy w bundle, ale jej karta oferty nie promuje bundla.

Typowy use case:

• Telefon (Slot 0, entryPoint: true) — chcesz, żeby bundle widać było gdy ktoś szuka telefonu
• Etui (Slot 1, entryPoint: false) — nie chcesz, żeby kupujący trafiający na etui od razu widział pełny bundle z telefonem (etui może być sprzedawane osobno)
• Ładowarka (Slot 2, entryPoint: false) — to samo co etui

Stare bundle vs flexible bundles — porównanie

Jedna oferta może być częścią wielu zestawów — w dotychczasowych bundle limit wynosił 7 zestawów na ofertę. Czy ten limit jest zachowany dla flexible bundles, dokumentacja Allegro nie precyzuje (zobacz sekcję "Czego dokumentacja NIE mówi").

Nowe REST endpointy /sale/flexible-bundles

Wszystkie endpointy są w zakresie /sale/flexible-bundles i wymagają uwierzytelnienia OAuth typowym dla Allegro REST API (scope: allegro.api.sale.offers.write, dokładny scope może być uściślony w specyfikacji OpenAPI gdy zasób trafi do produkcji).

Porównanie ze starym /sale/bundles:

Kluczowa praktyczna zmiana — w starym API edycja bundle wymagała usunięcia i utworzenia od nowa (poza zmianą rabatu, która miała własny PUT). Nowe API daje pełną PUT-edycję bundle bez konieczności rekonstrukcji.

Rabaty: WHOLE_BUNDLE_DISCOUNT vs SLOT_DISCOUNT

Allegro w newsie definiuje dwa tryby rabatu, oba procentowe.

WHOLE_BUNDLE_DISCOUNT

Rabat na cały bundle. Allegro rozkłada zniżkę proporcjonalnie na wszystkie oferty w bundle, które nie mają excludedFromDiscount: true. Cytat z dokumentacji: "kwota rabatu zostanie rozłożona proporcjonalnie na wszystkie niewykluczone ze zniżki oferty w zestawie".

Przykład:

• Slot 0: telefon iPhone 15 (cena 3 500 zł)
• Slot 1: etui (cena 100 zł)
• Slot 2: ładowarka (cena 200 zł)
• Łączna wartość bundle: 3 800 zł
• Rabat: 10% (WHOLE_BUNDLE_DISCOUNT)
• Zniżka rozłożona: 350 zł na telefon, 10 zł na etui, 20 zł na ładowarkę
• Kupujący płaci: 3 420 zł

To dobry tryb gdy chcesz pokazać kupującemu jednolity rabat i nie zależy Ci na utrzymaniu konkretnej ceny per produkt.

SLOT_DISCOUNT

Rabat per slot. Możesz określić różną zniżkę dla każdego slotu w bundle. Cytat z dokumentacji: "pozwala określić, które sloty w zestawie są objęte rabatem i w jakiej wysokości".

Przykład:

• Slot 0: telefon (rabat 0% — flagowy produkt, marża cienka)
• Slot 1: etui (rabat 20% — wysokomarżowy akcesoria)
• Slot 2: ładowarka (rabat 30% — bardzo wysokomarżowy)
• Łączna cena po rabacie: 3 500 + 80 + 140 = 3 720 zł

Dla sprzedawcy z różnymi marżami per kategoria — to znacznie potężniejszy mechanizm niż stary, jednolity rabat kwotowy. Możesz dawać agresywne zniżki tylko na akcesoria (gdzie marża wynosi 50%) bez kanibalizowania marży na flagowym produkcie (gdzie marża wynosi 8%).

Migracja istniejących zestawów — co się stanie

Allegro w komunikacie z 29 stycznia 2026 zapowiedziało: "Równocześnie z wdrożeniem zostanie wdrożony process migracji istniejących zestawów ofertowych". Co to oznacza w praktyce:

• Istniejące bundle nie zostaną automatycznie usunięte — Allegro przepisze je do struktury flexible bundles
• Każdy stary bundle stanie się flexible bundle z jednym slotem zawierającym wszystkie oferty — tak wynika z logiki migracji (brak alternatyw = pojedynczy slot z N ofert)
• Stary rabat kwotowy zostanie przeliczony na procentowy — Allegro nie ujawniło dokładnej metody przeliczenia, ale typowy algorytm to: rabat % = stary rabat kwotowy / łączna wartość bundle
• entryPoint zostanie ustawiony domyślnie — prawdopodobnie true dla wszystkich ofert w bundle (zachowanie wsteczne)

Co wymaga ręcznej interwencji:

• Integracje korzystające ze starego API muszą zostać zaktualizowane (nowe endpointy, nowa struktura request body)
• Jeśli chcesz wykorzystać group slots (sloty z alternatywami), musisz manualnie przekształcić zmigrowany bundle na format z wieloma slotami
• Jeśli chcesz rabaty per slot (SLOT_DISCOUNT), musisz manualnie zmienić tryb i ustawić wartości

W praktyce: po 10 czerwca 2026 Twoje istniejące zestawy działają dalej, ale w formie bardzo prymitywnej (jeden slot, jednolity rabat procentowy). Pełne korzyści (wybór kupującego, rabaty per slot, requiredQuantity > 1) wymagają nowej konfiguracji.

Co przygotować przed 10 czerwca — checklist dla integracji

Twardy deadline to 10 czerwca 2026. Stare endpointy przestaną działać — integracja, która nie zostanie zaktualizowana, przestanie tworzyć/edytować zestawy. Oto checklist.

1. Audyt aktualnej integracji

Sprawdź czy korzystasz z /sale/bundles w którymkolwiek kodzie. Typowe miejsca:

• Skrypty CRON które tworzą bundle dla nowych ofert
• BaseLinker / Sello / podobne narzędzia (sprawdź ich roadmapę aktualizacji)
• Własne dashboardy które prezentują listę bundli
• Webhooki które reagują na zmiany bundli

2. Test w Sandboxie

Sandbox API jest dostępny od 29 stycznia 2026. Endpoint sandbox to typowo https://api.allegro.pl.allegrosandbox.pl/sale/flexible-bundles. Stwórz testowy bundle z group slots i SLOT_DISCOUNT, zweryfikuj że Twoja integracja poprawnie obsługuje nowy model.

3. Aktualizacja modelu danych

Stary bundle miał płaską listę ofert. Nowy ma:

FlexibleBundle {
  bundleId: string
  slots: Slot[] {
    order: int
    entryPoint: bool
    requiredQuantity: int
    offers: Offer[] {
      id: string
      excludedFromDiscount: bool
    }
  }
  discount: {
    type: "WHOLE_BUNDLE_DISCOUNT" | "SLOT_DISCOUNT"
    // dla SLOT_DISCOUNT: prawdopodobnie pole z wartościami per slot
  }
}

Jeśli używasz Eloquent / TypeORM / podobnego ORM-a, dodaj relację Bundle hasMany Slots zamiast prostej tabeli bundle_offers.

4. Plan migracji ręcznej

Wybierz top 10 swoich istniejących bundli (po sprzedaży). Zaplanuj manualną rekonfigurację każdego z nich po 10 czerwca:

• Czy ma sens dodać alternatywy w slocie (np. wybór kolorów etui)?
• Czy ma sens różne rabaty per slot (akcesoria 20%, produkt główny 0%)?
• Który slot powinien być entryPoint: true (zwykle ten z głównym driverem ruchu)?

5. Komunikacja do działu obsługi

Jeśli masz BOK-a obsługującego pytania klientów — przygotuj FAQ:

• "Czemu mogę teraz wybrać kolor etui w zestawie?" (group slots)
• "Dlaczego rabat w zestawie jest inny dla etui niż dla telefonu?" (SLOT_DISCOUNT)
• "Dlaczego widzę dwa różne bundle z tym samym telefonem?" (jeśli skonfigurujesz różne bundle dla różnych slotów akcesoriów)

6. Monitoring konwersji po wdrożeniu

Group slots zmienia doświadczenie zakupowe. Konwersja na bundle może wzrosnąć (większa swoboda wyboru) lub spaść (paraliż decyzyjny). Mierz CR per bundle w pierwszych 2-4 tygodniach po 10 czerwca i porównaj z baseline z maja.

Kalkulator: rentowność bundle przy obu typach rabatu

Poniżej kalkulator który pomoże policzyć rentowność bundle przy obu typach rabatu. Wprowadź ceny i marże 3 produktów, system pokaże zysk per produkt i łączny po WHOLE_BUNDLE_DISCOUNT i SLOT_DISCOUNT.

Czego dokumentacja Allegro NIE mówi (i co warto sprawdzić)

News na Developer Portal jest oszczędny — pozostawia kilka pytań bez odpowiedzi. Na podstawie aktualnego stanu sandboxa i analogii do starego API można przypuszczać, ale bez weryfikacji w sandboxie nie należy zakładać:

• Maksymalna liczba slotów w bundle — w starym API limit bundle to 9 ofert; w nowym brak oficjalnej deklaracji limitu slotów lub ofert per slot
• Maksymalna liczba alternatyw per slot — analogicznie
• Czy requiredQuantity może przekraczać quantity oferty — jeśli oferta ma w magazynie 1 szt, a slot wymaga 2, co dzieje się przy zakupie?
• Jak liczona jest prowizja Allegro — czy nadal per produkt (jak w starym bundle), czy z całego bundle? Jeśli per produkt, każda oferta w slocie jest niezależnie objęta stawką prowizji swojej kategorii
• Dokładny format SLOT_DISCOUNT w request body — przykład w newsie pokazuje tylko "type": "SLOT_DISCOUNT", bez pól z wartościami per slot. Pełna struktura prawdopodobnie wymaga dodatkowego pola z mapowaniem slotOrder → percentage
• Czy bundle widoczne są w kampaniach promocyjnych — w starym API bundle z rabatem nie pojawiały się w kampaniach (Black Friday, Smart! Weeks). Czy ta reguła zostaje?
• Walidacja kategorii — czy alternatywy w jednym slocie muszą być z tej samej kategorii? Z tej samej marki?

To wszystko można i należy zweryfikować w sandboxie przed 10 czerwca. Jeśli zarządzasz integracją ERP — przeznacz 4-8 godzin pracy programistycznej na testy.

Co możesz zrobić TERAZ — 5 kroków

1. Sprawdź czy używasz /sale/bundles w aktualnej integracji

grep -r "/sale/bundles" . w repo Twojej integracji. Każde wystąpienie wymaga aktualizacji.

2. Załóż konto sandbox Allegro (jeśli jeszcze nie masz)

Sandbox: https://apps.developer.allegro.pl.allegrosandbox.pl. Bez tego nie zrobisz pełnych testów.

3. Przetestuj POST /sale/flexible-bundles ze swoim tokenem sandbox

Stwórz testowy bundle z 2 slotami i SLOT_DISCOUNT. Zweryfikuj że dostajesz bundleId i że GET zwraca strukturę zgodną z Twoim modelem danych.

4. Wybierz top 5 swoich istniejących bundli do ręcznej rekonfiguracji

Po 10 czerwca Allegro zmigruje je automatycznie, ale tylko Ty wiesz które bundle skorzystają z group slots i rabatów per slot. Przygotuj listę na 10 czerwca.

5. Połącz konto z Profiro żeby sprawdzić realny zysk per bundle

SLOT_DISCOUNT wymaga znajomości marży per kategoria. Profiro liczy zysk netto po prowizji SUC, NSP, dopłacie Smart! i kursie walut na każdej ofercie — niezbędne do mądrego ustawienia rabatów per slot.

Powiązane artykuły

• Koniec wariantów ofertowych Allegro — 14 kwietnia 2026 — wcześniejsza zmiana w modelu produktów Allegro; flexible bundles są częściowym substytutem dla ofert wielowariantowych
• Ile naprawdę zarabiasz na Allegro? — fundamenty kalkulacji zysku netto, krytyczne przy ustawianiu SLOT_DISCOUNT
• Prowizje Allegro 2026 — tabela stawek per kategoria — prowizja per produkt w bundle nadal liczona per kategoria
• Allegro AI weryfikuje oferty od 5 maja 2026 — kontekst innych zmian w 2026

Często zadawane pytania

Czy moje istniejące bundle przestaną działać 10 czerwca?

Nie — Allegro automatycznie zmigruje je do nowej struktury flexible bundles. Ale działać będą w bardzo prymitywnej formie (jeden slot, jednolity rabat procentowy). Żeby skorzystać z group slots i SLOT_DISCOUNT, musisz ręcznie zrekonfigurować bundle po 10 czerwca.

Czy mogę używać starych endpointów /sale/bundles po 10 czerwca 2026?

Nie. Allegro wyraźnie zapowiedziało wyłączenie: "starych metod POST, GET i DELETE dla /sale/bundles oraz PUT dla /sale/bundles/{bundleId}/discount nie będzie można używać". Integracje muszą być zaktualizowane do 9 czerwca włącznie.

Czy BaseLinker / Sello / Magento już obsługują flexible bundles?

Sprawdź roadmapę swojego narzędzia. Na 18 maja 2026 żaden popularny polski integrator nie ma publicznie ogłoszonego supportu — ale 23 dni do wdrożenia to typowo czas w którym pojawia się update. Skontaktuj się z supportem przed 10 czerwca. Jeśli Twoja integracja jest własna (skrypty PHP/Python/Node), przygotuj implementację w sandboxie już teraz.

Jak Allegro przelicza stary rabat kwotowy na nowy procentowy?

Dokumentacja Allegro nie podaje algorytmu migracji rabatów. Najbardziej prawdopodobny algorytm to: rabat % = stary rabat kwotowy / łączna wartość ofert w bundle × 100. Zweryfikuj wartości zmigrowanych bundli po 10 czerwca i ewentualnie skoryguj ręcznie jeśli nowy rabat nie odpowiada Twoim założeniom marżowym.

Czy prowizja Allegro w bundle będzie liczona per produkt czy z całości?

W starym API: per produkt (każda oferta w bundle objęta stawką prowizji swojej kategorii, naliczana od ceny po rabacie). Dla flexible bundles dokumentacja nie precyzuje wprost, ale logika "kupujący wybiera 1 z N alternatyw w slocie" sugeruje że nadal per produkt — bo dopiero w momencie zakupu wiadomo która oferta z slotu została wybrana. Zweryfikuj w sandboxie.

Czy mogę mieć w slocie oferty z różnych kategorii?

Dokumentacja Allegro nie podaje takiego ograniczenia. Logicznie — slot z alternatywami typowo zawiera oferty tego samego typu (np. różne kolory etui), więc będą z tej samej kategorii. Ale technicznie API może pozwolić na mieszanie kategorii. Każda kategoria ma własną stawkę prowizji — co znaczy, że wybór przez kupującego między slotem A z kategorii 5% a slotem A' z kategorii 10% wpłynie na Twój zysk netto.

Co jeśli oferta w slocie wyprzeda się?

W starym API bundle deaktywowało się gdy zostawała tylko 1 aktywna oferta. W nowym, gdzie slot ma N alternatyw, prawdopodobnie wystarczy że co najmniej jedna oferta w slocie jest aktywna — wtedy bundle pozostaje aktywny, a wyprzedana oferta po prostu znika z wyboru kupującego. To znaczna poprawa stabilności bundli w czasie. Do zweryfikowania w sandboxie.