Granularne blokowanie dostępu do API w przypadku restrykcji na koncie (rozdzielenie Ofert od Zamówień i Komunikacji)

[GregECAT]

Sugestia: Granularne blokowanie dostępu do API w przypadku restrykcji na koncie (rozdzielenie Ofert od Zamówień i Komunikacji)

Typ: Feature Request / Enhancement
Kategoria: API Design, Orders, Messaging

Opis problemu

Obecnie w sytuacji, gdy konto sprzedawcy zostaje zablokowane z powodu procedur weryfikacyjnych (np. KYC, AML, konieczność wyjaśnienia konfliktu w konkretnym zamówieniu, rutynowe blokady bezpieczeństwa), dostęp do API Allegro zostaje całkowicie odcięty.

Dla sprzedawców, którzy opierają swoją działalność w 100% na zewnętrznych systemach zarządzania sprzedażą (ERP, BaseLinker, autorskie systemy SaaS jak Gapli), zarządząjących często wieloma kontami jednocześnie, taka globalna blokada generuje krytyczną lawinę problemów:

1. Całkowita utrata widoczności: Sprzedawca traci z poziomu swojego systemu możliwość podglądu istniejących zamówień, co paraliżuje proces pakowania i wysyłki towarów, które zostały opłacone przed nałożeniem blokady.
2. Paraliż komunikacyjny: Odcięcie od API Wiadomości i Dyskusji sprawia, że sprzedawca nie jest w stanie odpowiadać na zapytania klientów ani informować ich o ewentualnych opóźnieniach.
3. Efekt domina: Brak możliwości reakcji i realizacji zaległych zamówień rodzi kolejne problemy.

Dlaczego jest to problem (również dla Allegro)?

Taka polityka rykoszetem uderza w samo Allegro oraz kupujących:

• Obciążenie BOK Allegro: Odcięty od API sprzedawca (szczególnie taki, który automatyzuje komunikację) nie odpisuje klientom. Zniecierpliwieni klienci otwierają kolejne Dyskusje, proszą o pomoc Allegro Protect, co generuje ogromną ilość dodatkowej, niepotrzebnej pracy dla pracowników wsparcia Allegro.
• Pogorszenie doświadczeń Kupujących: Klienci są pozostawieni sami sobie, bez informacji o statusie swojego zamówienia.
• Błędne koło SLA: Blokada uniemożliwia wysłanie zamówień i dodanie numerów przewozowych, co drastycznie obniża statystyki jakościowe sprzedawcy, utrudniając mu powrót do normalnej sprzedaży po odblokowaniu konta.

Rozumiemy i w pełni popieramy konieczność istnienia blokad jako mechanizmu ochrony platformy i kupujących przed nieuczciwymi praktykami czy wymagającymi weryfikacji sytuacjami. Jednak zakres tej blokady w środowisku zautomatyzowanym (API) jest zbyt szeroki.

Proponowane rozwiązanie

Wnosimy o zmianę polityki blokowania kont w kontekście dostępu do REST API poprzez wprowadzenie granularnych restrykcji:

1. Blokada zasobów sprzedażowych (Offers/Products) [ZACHOWANA]: API powinno odrzucać (np. błędem 403 Forbidden) wszelkie próby wystawiania nowych ofert, wznawiania zakończonych, synchronizacji stanów magazynowych w górę czy modyfikacji opisów. Mechanizm prewencyjny zostaje w pełni utrzymany.
2. Dostęp do zarządzania zamówieniami (Orders/Checkout-Forms) [ODBLOKOWANY]: Sprzedawca powinien móc przez API pobrać opłacone zamówienia (złożone przed blokadą), dodać do nich numery listów przewozowych i zmienić ich status, dokonywać zwrotów.
3. Dostęp do obsługi klienta (Messages/Disputes) [ODBLOKOWANY]: Utrzymanie możliwości komunikacji dwustronnej z klientem poprzez API oraz odpowiadania w toczących się dyskusjach lub reklamacjach.

Korzyści z wdrożenia poprawki

• Zwiększenie satysfakcji kupujących dzięki utrzymaniu standardów obsługi klienta pomimo procedur wyjaśniających na koncie sprzedawcy.
• Mniejsze obciążenie administracji i działu wsparcia Allegro – sprzedawca samodzielnie i na bieżąco rozwiązuje problemy z kupującymi bez eskalacji.
• Umożliwienie twórcom oprogramowania e-commerce budowania stabilniejszych i bardziej niezawodnych integracji, które potrafią elegancko obsłużyć "stan weryfikacji" zamiast ulegać awarii autoryzacji.

Bardzo prosimy zespół architektów API o pochylenie się nad tym problemem. W dobie ogromnej automatyzacji sprzedaży, całkowite "odcięcie kabla" generuje więcej szkód dla wszystkich stron (w tym kupujących) niż zysków z samej blokady.

[infoasystentai-collab]

Well done

[PrzemyslawLukanowski]

Dziękujemy za przesłanie szczegółowej sugestii dotyczącej blokowania dostępu do API. Aktualnie nie mamy jednak w planach wdrożenia takiego rozwiązania, jednak zapisujemy ten pomysł na przyszłość i jeśli cokolwiek zmieni się w naszych planach rozwoju API, z pewnością wrócimy z informacją w wątku.

[koziolkaanna-cell]

Też mam zablokowane konto i wypłaty środków z konta i teraz utrudnianie też realizację kolejnych zamówień i zrobiło się błędne koło. Co mam zrobić żeby nie powtórzyło się to w przyszłości.

[PrzemyslawLukanowski]

W takiej sytuacji możesz ponownie autoryzować aplikację, aby po wygenerowaniu nowych tokenów mogła nadal wykonywać operacje w Twoim imieniu.

[GregECAT]

Dziękuję za odpowiedź. Rozumiem, że przebudowa logiki autoryzacji i blokad to duże przedsięwzięcie i trudno je wpisać ad-hoc w obecny plan rozwoju.

Chciałbym jednak – bazując na naszych doświadczeniach przy integracji tysięcy kont – rzucić nieco więcej światła na ten problem od strony czysto biznesowej i operacyjnej. Z perspektywy technicznej API całkowite odcięcie wydaje się najbezpieczniejszym rozwiązaniem, jednak w realiach e-commerce wywołuje ono ogromny pożar, który na końcu i tak gasi wsparcie Allegro.

Dlaczego obecny model "wszystko albo nic" jest tak bolesny dla obu stron?

Kiedy duży sprzedawca opierający procesy na zewnętrznym systemie (ERP/SaaS) trafia na rutynową weryfikację (np. AML/KYC) i traci token API z minuty na minutę:

1. Kupujący są ignorowani: Sprzedawca nie widzi zapytań klientów, bo traci dostęp do API Wiadomości.
2. Lawina Dyskusji: Klienci, zirytowani brakiem paczki i brakiem kontaktu, zaczynają masowo otwierać Dyskusje (do których sprzedawca znów nie ma dostępu przez API).
3. Koszty po stronie Allegro: Sfrustrowani kupujący eskalują sprawy do Allegro Protect, zmuszając pracowników BOK Allegro do ręcznego rozwiązywania konfliktów. Tych problemów w ogóle by nie było, gdyby sprzedawca mógł zachować ciągłość obsługi klienta.

Odcinając API w 100%, system zmusza profesjonalnego sprzedawcę do bycia głuchym na potrzeby klienta, nawet jeśli powodem blokady jest trywialny brak przesłania skanu dokumentu do weryfikacji lub gdy problem z jednym zamówieniem powoduje narastające problemy z kolejnymi przez brak dostępu do systemu komunikacji i płynnego zarządzania statusami zamówień i ich obsługą w połączeniu z systemem, z którego korzysta sprzedawca.

Pytanie o rozwiązanie tymczasowe (workaround):

Czy do czasu ewentualnej, gruntownej zmiany polityki blokad, przewidujecie jakikolwiek workaround dla twórców oprogramowania zewnętrznego?

Czy byłoby możliwe wdrożenie np. wyodrębnionego zakresu autoryzacji (scope tokena, np. read:orders_emergency i messaging:emergency), który dawałby dostęp wyłącznie do pobierania historycznych zamówień i obsługi bieżącej komunikacji z klientem, a który to token nie byłby unieważniany przez standardowe blokady sprzedażowe?

Będę bardzo wdzięczny za przekazanie tej perspektywy biznesowej do Waszego zespołu produktowego. Jako twórcy oprogramowania chcemy, aby cały proces zakupowy na Allegro przebiegał gładko dla kupujących – nawet w sytuacjach awaryjnych na koncie sprzedawcy.

[PrzemyslawLukanowski]

Dziękujemy za ten dodatkowy komentarz i szczegółowe przedstawienie perspektywy biznesowej – doskonale rozumiemy, jak kluczowa jest ciągłość komunikacji z kupującym. Chcielibyśmy jednak doprecyzować jedną kwestię: w przypadku nałożenia blokady sprzedawca wciąż zachowuje dostęp do wymienionych przez Ciebie funkcji (obsługa zamówień i wiadomości), jednak obecny mechanizm bezpieczeństwa unieważnia dotychczasowe tokeny. Na tę chwilę jedynym działającym workaroundem jest ponowne przejście procesu autoryzacji aplikacji przez sprzedawcę w celu wygenerowania nowej pary tokenów.

Niemniej jednak, zespół API przeanalizuje ten wątek - wrócę z informacją, jeśli zdecydujemy się wprowadzić zmiany w zachowaniu tokenów po otrzymaniu blokady na koncie.

[GregECAT]

Dziękuję bardzo za szybką i konkretną odpowiedź! 🎉

Potwierdzam — workaround działa prawidłowo. Po ponownym przejściu procesu autoryzacji OAuth na zablokowanym koncie, nowo wygenerowany token pozwala na:

• ✅ Pobieranie zamówień (/order/checkout-forms)
• ✅ Pobieranie i wysyłanie wiadomości (/messaging)
• ✅ Zarządzanie wysyłkami i numerami przewozowymi

Jednocześnie operacje na ofercie (wystawianie, wznawianie) są prawidłowo blokowane przez Allegro, co jest oczekiwanym i zrozumiałym zachowaniem.

---

Po naszej stronie (SaaS) wdrożymy teraz mechanizm automatycznego wykrywania unieważnienia tokena i natychmiastowego promptowania użytkownika do ponownej autoryzacji, tak aby ciągłość obsługi zamówień i komunikacji z kupującymi była zachowana bez przerwy.

---

Mimo że workaround rozwiązuje problem operacyjnie, chciałbym poprosić o nieporzucanie tego tematu w planach rozwoju API. Oto dlaczego:

1. Workaround wymaga akcji manualnej ze strony sprzedawcy
Sprzedawca musi się dowiedzieć, że token został unieważniony, wejść do panelu integracji i ręcznie ponownie autoryzować aplikację. W przypadku dużych operatorów zarządzających dziesiątkami kont, czas reakcji może wynosić godziny — a w tym czasie kupujący czekają na odpowiedź.

2. Idealne rozwiązanie docelowe
Gdyby mechanizm bezpieczeństwa unieważniał token tylko dla scope'ów związanych z ofertami (np. sale.offers.*), zachowując ważność tokena dla zamówień i wiadomości — cały problem zniknąłby automatycznie, bez konieczności jakiejkolwiek interwencji ze strony sprzedawcy ani twórcy oprogramowania.

3. Kupujący wygrywa
Każda minuta, w której sprzedawca nie wie, że musi ponownie autoryzować aplikację, to minuta, w której kupujący nie dostaje odpowiedzi na pytanie o swoją paczkę. Granularne tokeny eliminują tę lukę całkowicie.

Jeszcze raz dziękuję za merytoryczną dyskusję i otwartość na feedback. Trzymamy kciuki za pozytywną decyzję zespołu API w tej sprawie! 🤞

[pdobranski]

Dzień dobry,
Mam wiele kanałów sprzedaży na różnych marketplacach i zablokowane konto przez inne zamówienie do wyjaśnienia. Gdybym nie wszedł indywidualnie w wiadomości Allegro, to nie wiedziałbym, że Klientka do mnie napisała. Opóźnienie reakcji na oczywistą sprawę powoduje narastający ciąg problematyczny kwestii do rozwiązania, który można by całkowicie uniknąć.