Allegro WebAPI

Interfejs programistyczny platformy Allegro

Aktualności RSS - changelog RSS - Wszystkie

Tutaj znajdziesz najnowsze informacje dotyczące zmian i wydarzeń związanych z WebAPI.

22 września 2011 r.

Changelog

Aukro Plus dla Aukro.cz

Data wdrożenia: 29 września 2011 r.
W przyszłym tygodniu, w czeskim serwisie aukcyjnym Aukro.cz wdrożony zostanie odpowiednik naszego Standardu Allegro - Aukro Plus. W związku z faktem iż działanie obu programów pokrywa się w dużym stopniu, w WebAPI zajdą jedynie drobne zmiany związane z tym faktem:

  • Parametr cat-item-option (doShowCat) poszerzony zostanie o nową wartość: 256, pozwalającą na odfiltrowanie ofert Aukro Plus (po zalogowaniu do kraju 56) oraz Standard Allegro (po zalogowaniu do kraju 1).

Oprócz powyższego, kilka innych metod dostosowanych zostanie do czeskich aukcji oznaczanych jako Aukro Plus (w zakresie pokrywającym się ze zmianami dla Standardu Allegro, wprowadzanymi w WebAPI w zeszłym miesiącu). W każdej z metod obowiązuje zasada, że aby zweryfikować czy dany przedmiot oznaczony jest jako Standard Allegro, czy jako Aukro Plus - należy dodatkowo sprawdzić informacje o kraju, w którym przedmiot został wystawiony (1 = PL = Standard Allegro, 56 = CZ = Aukro Plus).

Podyskutuj o zmianach na forum usługi

15 września 2011 r.

Changelog

Dane małżonka oraz transakcje łamiące Regulamin

Data wdrożenia: 22 września 2011 r.
W przyszłym tygodniu, w związku ze zmianami w serwisie, planowane są następujące zmiany w usłudze Allegro WebAPI:

  • Na koniec danych zwracanych przez doGetMyData dodana zostanie nowa struktura:

       7. related-persons | RelatedPersonsStruct
           Struktura zawierająca dane małżonka korzystającego z konta.
              1. spouse-first-name | string
                  Imię małżonka
              2. spouse-last-name | string
                  Nazwisko małżonka

  • Na koniec struktury fe-wait-list (zwracanej przez doGetWaitingFeedbacks) dodane zostanie nowe pole:

       6. fe-possibility-to-add | int
         Informacja o tym, czy dla danej transakcji możliwe jest wystawienie komentarza (1 - tak, 0 - nie, ponieważ transakcja złamała Regulamin).

  • Do metody doFeedback(Many) dodany zostanie nowy kod błędu:

       ERR_FEEDBACK_NOT_ALLOWED
      Nie można wystawić komentarza do wskazanej transakcji, gdyż złamała ona Regulamin. Skontaktuj się z Allegro przez formularz kontaktowy.

Podyskutuj o zmianach na forum usługi

29 sierpnia 2011 r.

Changelog

Operowanie na porcjach danych w doGetMyIncomingPayments

Data wdrożenia: 9 sierpnia 2011 r.
Na początku bieżącego miesiąca, wraz ze zmianami w WebAPI dla wdrażanej w serwisie opcji jednej płatności do wielu sprzedających, wdrożona została w usłudze dodatkowa zmiana, o której niestety zapomnieliśmy wspomnieć w komunikacie. Zmianie uległ sposób operowania na zwracanych porcjach danych w metodzie doGetMyIncomingPayments. Wcześniej metoda pozwalała na operowanie na zwracanych danych na zasadzie offsetowania, obecnie mechanizm działa jak klasyczny paging (w polu trans-page-limit ustawiany jest rozmiar wynikowej paczki, a pole trans-offset służy do sterowania pobieraniem kolejnych porcji danych). Przepraszamy za to komunikacyjne przeoczenie - podjęliśmy już odpowiedniej kroki, mające zapobiec tego typu sytuacjom w przyszłości.

Podyskutuj o zmianach na forum usługi

26 sierpnia 2011 r.

Changelog

Proces pozakupowy (i nie tylko)

Data wdrożenia: 1 września 2011 r.
W przyszłym tygodniu planujemy wdrożyć dziewięć nowych metod, dzięki którym możliwe będzie m.in. obsłużenie przez WebAPI praktycznie w stu procentach pełnego procesu pozakupowego (czyli wszystkiego co dzieje się po kliknięciu przez użytkownika w przycisk KT/zakończeniu aukcji do przekazania płatności na stronę danego banku).

  • Poniżej lista nowych metod związanych ściśle z procesem pozakupowym:
    1. doSendPostBuyForm  (metoda główna - pozwala na wypełnienie i wysłanie formularza pozakupowego i przekazanie użytkownika na stronę banku)
    2. doGetFilledPostBuyForms (metoda pomocnicza - pozwala m.in. na wstępne wypełnienie nowego formularza danymi wybranymi wcześniej przez kupującego)
    3. doGetRelatedItems (metoda pomocnicza - realizuje pierwszy krok procesu pozakupowego i pozwala na pobieranie aukcji, dla których nastąpić ma wypełnienie formularza pozakupowego)
    4. doGetShipmentDataForRelatedItems (metoda pomocnicza - pozwala na pobieranie wspólnych sposobów dostawy dla aukcji podanych na wejściu)
    5. doGetPaymentMethods (metoda pomocnicza - pozwala na pobieranie wszystkich metod płatności dostępnych  do wyboru dla zalogowanego użytkownika)
    6. doGetMyAddresses (metoda pomocnicza - pozwala na pobieranie informacji o zapisanych na koncie użytkownika danych teleadresowych)

  • Lista pozostałych nowych metod:
    1. doGetMessageToBuyer (metoda pozwala na pobieranie wiadomości do kupującego, która dołączana jest do informacji o złożeniu oferty po każdym zakupie w aukcji)
    2. doGetMyPaymentsInfo (metoda pozwala na pobieranie kompletu informacji dot. ustawień PzA z konta zalogowanego użytkownika)
    3. doRequestPayout (metoda pozwala na realizację wypłaty środków PzA na rachunek przypisany do konta użytkownika).

  • Konieczna będzie także modyfikacja i rozszerzenie danych zwracanych przez metody doGetPostBuyFormsData(ForBuyers/ForSellers):
    • w polu post-buy-form-pay-type - zamiast pełnej nazwy płatności (jak działa to w chwili obecnej) - zwracany będzie jej typ (zgodny z PayU - pełną listę typów znaleźć można w dokumentacji technicznej usługi),
    • na koniec struktur korzystających z PostBuyFormAddressStruct, dodane zostanie nowe pole: post-buy-form-adr-type (int, informacja o typie adresu, który wkazał kupujący wypełniając formularz pozakupowy - analogiczna z typami zwracanymi przez doGetMyAddresses). Dla adresów wpisanych ręcznie, zwracane będzie w tym polu zawsze 0.

Podyskutuj o zmianach na forum usługi

18 sierpnia 2011 r.

Changelog

Zakupy bez rejestracji dla Aukro.cz

Data wdrożenia: 6 października 2011 r.
Na początku października, w czeskim serwisie aukcyjnym Aukro.cz wdrożona zostanie możliwość dokonywania zakupów bez rejestracji (program: Neregistrovaný, analogiczny do polskiego rozwiązania). W związku z faktem iż oba programy pokrywają się praktycznie 1:1, w WebAPI nie zajdą żadne konkretne zmiany związane z tym obszarem - jedynie już działające metody dostosowane zostaną do czeskich użytkowników (zalogowanych do kraju 56), w zakresie pokrywającym się ze zmianami dla użytkowników niezarejestrowanych w Polsce, wprowadzanych w WebAPI w zeszłym roku.

Podyskutuj o zmianach na forum usługi

16 sierpnia 2011 r.

Changelog

Pakiet zmian w metodach

Data wdrożenia: 25 sierpnia 2011 r.

W przyszłym tygodniu planujemy wprowadzić następujące zmiany w metodach WebAPI:

  • usuniemy metodę doCheckItemIdByFutureItemId - od czasu ujednolicenia identyfikatorów aukcji trwających oraz planowanych, metoda ta przestała spełniać swoje zadania, a co za tym idzie - jej dalsze utrzymywanie stało się zbyteczne.

  • rozbudujemy metody: doGetPostBuyFormsData(ForBuyers/ForSellers) - na koniec zwracanych przez nie danych dodamy nowe pole: 
    • post-buy-form-payment-amount | float
      Kwota wpłacona przez kupującego za pośrednictwem PzA.

  • w metodzie doBidItem, zmodyfikowana zostanie logika składania za jej pomocą ofert Kup Teraz - tak aby maksymalnie ograniczyć możliwość błędnego złożenia oferty na kwotę inną niż faktycznie widnieje w aukcji (sytuacje gdy np. sprzedający w międyczasie - pomiędzy wyświetleniem oferty użytkownikowi, a zakupem w niej - podniósł cenę towaru). W związku z powyższym wprowadzimy obowiązek wysyłania w polu bid-user-price wartości równej cenie Kup Teraz (obecnie dla zakupów przez KT pole to nie musi być wypełniane).
    • przekazanie kwoty różnej od stanu Kup Teraz na aukcji spowoduje zwrócenie błędu: ERR_INCORRECT_BUY_NOW_PRICE,
    • przy okazji do metody dodamy też nowy kod błędu: ERR_ITEMS_PER_USER_LIMIT_EXCEEDED - występujący w przypadku, w którym użytkownik złoży ofertę w aukcji na liczbę przedmiotów przekraczającą ustalony w niej limit (dotyczy tylko aukcji promowanych jako Okazje Allegro, które mają narzucony limit ofert dla jednego użytkownika).

  • zmienimy w dwóch miejscach pola formularza sprzedaży:
    • dla dwóch fidów (2: Kategoria oraz 9: Kraj) zmienione zostaną niepoprawne sell-form-type (z - odpowiednio - 12 oraz 10 na 2 - czyli integer),
    • dla aukro.cz (kod kraju 56), poprawiona zostanie kolejność zwracanych wartości dla pól (fidy: 2585-2623 - Doba dodání (od obdržení platby)). Kolejne wartości zostaną uszeregowane rosnąco.

  • w końcu - zmienimy nazwę standardowego elementu SOAP fault, w którym przesyłamy tłumaczenia zwracanych kodów błędów - z niepoprawnego <faultfactor> na <faultactor>.

Podyskutuj o zmianach na forum usługi

5 sierpnia 2011 r.

Changelog

Informacje o oznaczeniu aukcji jako Standard Allegro

Data wdrożenia: 11 sierpnia 2011 r.

W związku z nadchodzącym wdrożeniem kolejnego etapu projektu Standard Allegro, w przyszłym tygodniu planujemy wprowadzić zmiany, polegające na dodaniu nowych pól, informujących o tym czy aukcja będzie/jest oznaczona jako Standard Allegro, na koniec struktur zwracanych przez poniższe metody WebAPI:

  • doCheckNewAuctionExt/doNewAuctionExt:
          3. item-is-allegro-standard | int
              Informacja o tym, czy aukcja będzie oznaczona jako Standard Allegro (1 - będzie, 0 - nie będzie).

  • doShowItemInfoExt (struktura ItemInfoExt):
        38. it-is-allegro-standard | int
              Informacja o tym, czy aukcja jest oznaczona jako Standard Allegro (1 - jest, 0 - nie jest).

  • doGetItemsInfo (struktura ItemInfo):
        34. it-is-allegro-standard | int
              Informacja o tym, czy aukcja jest oznaczona jako Standard Allegro (1 - jest, 0 - nie jest).

  • doSearch/doShowCat (struktura SearchResponseType):
        22. s-it-is-allegro-standard | int
              Informacja o tym, czy aukcja jest oznaczona jako Standard Allegro (1 - jest, 0 - nie jest).

  • doGetUserItems (struktura UserItemList):
        16. it-is-allegro-standard | int
              Informacja o tym, czy aukcja jest oznaczona jako Standard Allegro (1 - jest, 0 - nie jest).

  • doGetSpecialItems (struktura SpecialAuctionStruct):
        17. it-is-allegro-standard | int
              Informacja o tym, czy aukcja jest oznaczona jako Standard Allegro (1 - jest, 0 - nie jest).

  • doMyAccount2 (struktura MyAccountStruct2):
    • dodanie na koniec tablicy stringów pola, informującego o tym, czy aukcja jest oznaczona jako Standard Allegro (1 - jest, 0 - nie jest, dotyczy typów: won, not_won, watch, watch_cl, sell, sold, not_sold).

Podyskutuj o zmianach na forum usługi

4 sierpnia 2011 r.

Komunikaty techniczne

Przerwa techniczna


Informujemy, że w środę, 10 sierpnia, w związku z planowaną przerwą techniczną, która będzie miała miejsce od godziny 01:00 do 04:30, usługa Allegro WebAPI będzie niedostępna.

Podyskutuj o zmianach na forum usługi

28 lipca 2011 r.

Changelog

Jedna płatność do wielu sprzedających

Data wdrożenia: 9 sierpnia 2011 r.

W przyszłym tygodniu, w związku z wdrożeniem w serwisie opcji jednej płatności do wielu sprzedających dla transakcji koszykowych, planujemy wprowadzić następujące zmiany w usłudze:

  • udostępnimy dwie nowe metody do pobierania formularzy pozakupowych - osobno dla sprzedających oraz kupujących:
    • doGetPostBuyFormsDataForBuyers - przeznaczona dla kupujących (sprzedający wywołujący tę metodę otrzyma pustą strukturę).
    • doGetPostBuyFormsDataForSellers - przeznaczona dla sprzedających (kupujący wywołujący tę metodę otrzyma pustą strukturę). Metoda ta będzie kopią obecnej metody doGetPostBuyFormsData, która tym samym stanie się zbędna i jako nadmiarowa zostanie usunięta pod koniec września b.r. (o czym poinformujemy z wyprzedzeniem w osobnym komunikacie).

  • dodatkowo - konieczna będzie poważna modyfikacja metody doGetMyPayments:
    • parametry wejściowe - zmianie ulegną nazwy pól:
      • session-handle na session-id,
      • trans-create-date-from/to na payment-time-from/to,
      • trans-page-limit na page-size,
      • trans-offset na page-number.
    • dane zwracane - struktura wyjściowa przebudowana zostanie na kształt podany niżej:
      1. pay-trans-payment | UserPaymentStruct[]
        Tablica struktur zawierających informacje o wpłatach zalogowanego użytkownika.
        1. pay-trans-id | long
          Identyfikator transakcji.
        2. pay-trans-sellers | PaymentSellersStruct[]
          Tablica struktur zawierających informację o przedmiotach składających się na transakcję, zakupionych od określonych sprzedających.
          1. pay-trans-seller-id | int
            Identyfikator sprzedającego.
          2. pay-trans-seller-name | string
            Nazwa sprzedającego.
          3. pay-trans-items | PaymentItemsStruct[]
            Tablica struktur zawierających informacje o przedmiotach zakupionych u danego sprzedającego.
            1. pay-trans-it-id | long
              Identyfikator aukcji.
            2. pay-trans-it-name | string
              Tytuł aukcji.
            3. pay-trans-it-count | int
              Liczba przedmiotów zakupionych na aukcji.
            4. pay-trans-it-price | float
              Wartość przedmiotów zakupionych na aukcji.
          4. pay-trans-seller-postage-amount | float
            Łączny koszt sposobów dostawy wybranych dla aukcji danego sprzedającego.
        3. pay-trans-type | string
          Metoda płatności (mBank, Multibank, BZ WBK, Pekao SA, BPH, Inteligo, Nordea, iPKO BP, ING, Raiffeisen Bank, Millennium, Kredyt Bank, Polbank, Citi Handlowy, Deutsche Bank, Getin Bank, Invest-Bank, Meritum Bank, Eurobank, Alior Bank, BGŻ, Karta płatnicza, Przelew bankowy, Zwykły przelew (poza systemem Płacę z Allegro), Płacę przy odbiorze).
        4. pay-trans-status | string
          Status transakcji PzA (listę wszystkich możliwych statusów dla wpłat podejrzeć można tutaj).
        5. pay-trans-amount | float
          Wysokość kwoty wpłaty użytkownika.
        6. pay-trans-create-date | long
          Data utworzenie transakcji PzA (w formacie Unix time).
        7. pay-trans-price | float
          Wartość przedmiotów zakupionych przez użytkownika w ramach transakcji i opłaconych przez PzA (lub 0 w przypadku dopłaty).
        8. pay-trans-postage-amount | float
          Łączne koszta wybranego przez użytkownika sposobu dostawy, opłacone w ramach transakcji PzA (lub 0 w przypadku dopłaty).
        9. pay-trans-incomplete | int
          Informacja o kompletności wpłaty (1 - wpłata niekompletna, 0 - wpłata kompletna).

Podyskutuj o zmianach na forum usługi

22 lipca 2011 r.

Changelog

Poszerzenie możliwości operowania na formularzach pozakupowych

Data wdrożenia: 28 lipca 2011 r.

W przyszłym tygodniu planowane są następujące zmiany w usłudze:

  • udostępniona zostanie nowa metoda dla sprzedających, umożliwiająca dodawanie informacji o przesyłkach do formularzy pozakupowych. Z jej kształtem można zapoznać się w dokumentacji:
  • w metodzie doGetPostBuyFormsData, modyfikacjom ulegnie - zwracana przez tę metodę - struktura post-buy-form-data:
    • w polu post-buy-form-operator-id - struktury post-buy-form-shipment-tracking - zwracane będą być mogły od tej pory dwie nowe wartości: 6 - Poczta Polska, 7 - Siódemka
    • na koniec struktury dodane zostanie nowe pole, zwracające status przesyłki:
          3. post-buy-form-package-status | string

  • aby umożliwić filtrowanie transakcji po wybranym przez kupującego sposobie dostawy, w metodzie doGetTransactionsIDs dodana do parametrów wejściowych zostanie nowa tablica, przyjmująca identyfikatory sposobów dostawy (do pobrania za pomocą doGetShipmentData):
                  4. shipment-id-array | long[] | niewymagany 

  • Jeżeli metoda ma działać w sposób dotychczasowy, wystarczy przekazać pusty shipment-id-array, jeżeli konieczne jest pobranie listy transakcji dla konkretnego sposobu dostawy - wystarczy podać jego identyfikator (lub kilka identyfikatorów). Jeżeli dla wskazanego shipment-id-array nie zostaną znalezione żadne transakcje - zwrócona zostanie pusta struktura.

Podyskutuj o zmianach na forum usługi