Przegląd
Ta dokumentacja opisuje, jak zarejestrować i skonfigurować publiczną aplikację Shopify (Shopify Public App) w Shopify Dev Dashboard oraz zintegrować ją z AdlerDo V6.1 w celu instalacji OAuth. Proces ten generuje Client ID i Client Secret, których AdlerDo używa do uwierzytelniania względem każdego sklepu Shopify instalującego aplikację.
Kontekst architektury
AdlerDo udostępnia /api/shopify/install jako punkt wejścia OAuth. Aplikacja w Dev Dashboard przekierowuje każde żądanie instalacji do tego punktu końcowego, który przeprowadza wymianę kodu OAuth, zapisuje token dostępu w bazie danych tenanta i rejestruje wymagane webhooki za pomocą zadań w tle Hangfire.
Wymagania wstępne
Przed rozpoczęciem upewnij się, że:
- Masz dostęp do organizacji Shopify TecSee GmbH z uprawnieniami do zarządzania aplikacjami
- Middleware AdlerDo jest wdrożone i osiągalne przez HTTPS na publicznym hoście skonfigurowanym dla docelowego środowiska
- Punkty końcowe
/api/shopify/install oraz /api/shopify/callback są osiągalne i zwracają prawidłowe odpowiedzi
- Dostępny jest sklep deweloperski do testów end-to-end przed przeniesieniem danych uwierzytelniających do środowiska produkcyjnego
- Lista zakresów (scopes) OAuth wymaganych przez AdlerDo została sfinalizowana i zapisana w konfiguracji
Krok 1 — Otwórz stronę App Development

Zaloguj się do organizacji Shopify i przejdź do Settings → Apps and sales channels → App development. Kliknij przycisk "Build apps in Dev Dashboard".
Ważne: NIE używaj przycisku "Create an app" w panelu Legacy custom apps. Starsze aplikacje niestandardowe (legacy custom apps) przestaną działać dla nowych sprzedawców od 1 stycznia 2026 r.
Krok 2 — Utwórz nową aplikację w Dev Dashboard

Dev Dashboard otwiera się pod adresem dev.shopify.com/dashboard/{organizationId}/apps. Kliknij przycisk "Create app" w prawym górnym rogu listy aplikacji.
Krok 3 — Wybierz ścieżkę tworzenia i ustaw nazwę aplikacji

Dostępne są dwie ścieżki tworzenia:
- Start with Shopify CLI — tworzy lokalnie szkielet projektu Node/Remix. AdlerDo nie potrzebuje tej ścieżki.
- Start from Dev Dashboard — rejestruje metadane aplikacji bezpośrednio w panelu i natychmiast generuje Client ID i Secret. Użyj tej ścieżki dla AdlerDo.
Wprowadź nazwę aplikacji (na przykład: AdlerDo) i kliknij Create.
Konwencja nazewnictwa
Użyj stabilnej nazwy widocznej dla klienta, wyświetlanej na ekranie zgody podczas instalacji. Dla TecSee dodaj prefiks dla każdego środowiska, jeśli to konieczne: AdlerDo (Production), AdlerDo Staging, AdlerDo Dev.
Krok 4 — Skonfiguruj adresy URL, wersję webhooków i zakresy

Po utworzeniu aplikacja otwiera się na karcie Versions z nową wersją roboczą. To tutaj definiowane są adres URL instalacji, wersja API webhooków oraz zakresy.
6.1 App URL
Ustaw App URL na publiczny punkt końcowy instalacji AdlerDo:
https://whlvm133440.wawihost.de/api/shopify/install
Jest to adres URL, na który Shopify przekierowuje, gdy sprzedawca instaluje aplikację. ShopifyInstallController w AdlerDo odczytuje parametry zapytania shop i hmac, weryfikuje HMAC i przekierowuje na stronę przyznania zgody OAuth Shopify.
6.2 Embed app in Shopify admin
Pozostaw zaznaczone pole wyboru "Embed app in Shopify admin". AdlerDo udostępnia osadzony interfejs administracyjny wewnątrz ramki administracyjnej Shopify przy użyciu App Bridge.
6.3 Preferences URL
Opcjonalne. Pozostaw puste, chyba że aplikacja udostępnia oddzielną stronę ustawień poza osadzonym środowiskiem.
6.4 Wersja API webhooków
Jawnie przypnij wersję API webhooków. W przykładzie pokazano 2026-04, czyli wersję, którą AdlerDo obecnie wykorzystuje. Zmiana tej wartości wymaga przeglądu mapowania każdego ładunku (payload) webhooka.
6.5 Zakresy dostępu
Kliknij "Select scopes" i zaznacz zakresy wymagane przez AdlerDo. Ogranicz listę do minimum, którego AdlerDo faktycznie używa — sprzedawcy widzą pełną listę na ekranie zgody podczas instalacji.
Dokładnie ta sama lista musi również zostać zapisana w konfiguracji AdlerDo (appsettings.Shopify.json → Shopify:Scopes), ponieważ kontroler instalacji przekazuje ją jako parametr zapytania scope. Niezgodność wymusi ponowne instalacje.
Zakresy opcjonalne a wymagane
Zakresy opcjonalne mogą być żądane w czasie działania po instalacji. AdlerDo traktuje wszystkie wymienione zakresy jako wymagane podczas początkowej instalacji, dlatego pozostaw blok Optional scopes pusty.
6.6 Redirect URLs
Dodaj adres URL przekierowania OAuth — publiczny adres URL wywołania zwrotnego (callback) OAuth AdlerDo:
https://whlvm133440.wawihost.de/api/shopify/callback
Dodaj po jednym adresie URL przekierowania na każde środowisko. Shopify odrzuca wywołanie zwrotne OAuth, jeśli adres URL podany w parametrze redirect_uri nie znajduje się na tej białej liście.
Krok 5 — Opublikuj wersję

Po zapisaniu wszystkich pól kliknij Release na dole strony wersji.
- Version name — czytelna dla człowieka etykieta. Konwencja TecSee:
alderdoo-{n}, gdzie n to automatycznie zwiększany numer wydania
- Version message — krótki dziennik zmian (np. "added read_locales scope", "bumped webhooks API to 2026-04")
Kliknij Release. Nowa wersja natychmiast staje się aktywna (Active) i zastępuje poprzednią aktywną wersję dla wszystkich nowych instalacji.
Zmiany zakresów po wydaniu
Dodanie nowego zakresu do wydanej wersji NIE nadaje go automatycznie w już zainstalowanych sklepach. Właściciel sklepu musi zatwierdzić ponowną autoryzację. AdlerDo wykrywa rozbieżność zakresów przy każdym żądaniu i w razie potrzeby uruchamia przekierowanie do ponownej instalacji.
Krok 6 — Zweryfikuj aktywną wersję

Otwórz kartę Versions z paska bocznego po lewej. Ostatnio wydana wersja jest oznaczona zieloną plakietką "Active". Wszystkie poprzednie wersje pozostają widoczne do celów audytowych.
Z tego widoku możesz kliknąć dowolną wersję historyczną, aby sprawdzić jej konfigurację, co jest przydatne podczas debugowania instalacji w starszym sklepie.
Krok 7 — Pobierz Client ID i Secret

Otwórz kartę Settings z paska bocznego po lewej. Blok Credentials u góry udostępnia Client ID i Secret.
9.1 Client ID
Publiczny identyfikator. Można go bezpiecznie umieścić w konfiguracji. Skopiuj go ikoną schowka i wklej do konfiguracji AdlerDo.
9.2 Client Secret
Wrażliwy. Traktuj jak dane uwierzytelniające. Sekret jest wyświetlany tylko raz, przy pierwszym wygenerowaniu; później pokazywana jest wyłącznie forma zamaskowana. Użyj ikony oka, aby jednorazowo go ujawnić w celu skopiowania, a następnie zapisz go standardową ścieżką przechowywania sekretów AdlerDo.
W AdlerDo sekrety integracji z platformami handlowymi są zapisywane w bazie danych tenanta z szyfrowaniem AES-256 za pośrednictwem MarketplaceCredentialEncryptor.
9.3 Rotacja sekretu
Kliknij Rotate, aby wygenerować nowy sekret. Poprzedni sekret jest natychmiast unieważniany. Skoordynuj rotację z wdrożeniem nowego sekretu do AdlerDo.
9.4 Adres e-mail kontaktowy API
Ustaw go na monitorowaną skrzynkę pocztową (obecnie dev@tecsee.de). Shopify wysyła na ten adres powiadomienia o wycofaniu API oraz zalecenia dotyczące bezpieczeństwa.
Podłączanie danych uwierzytelniających do AdlerDo
Gdy masz już Client ID i Secret, dodaj dane uwierzytelniające do konfiguracji AdlerDo.
10.1 Konfiguracja
Dodaj następujący blok do konfiguracji specyficznej dla środowiska:
"Shopify": {
"ClientId": "1d15c8413f636e7cfda6f4402d9ef552",
"ClientSecret": "<from Settings page>",
"Scopes": "read_products,write_products,read_orders,write_orders,…",
"WebhooksApiVersion": "2026-04",
"InstallRedirectUrl": "https://whlvm133440.wawihost.de/api/shopify/callback"
}
10.2 Przebieg instalacji
Kompletny uścisk dłoni (handshake) instalacji end-to-end wygląda następująco:
- Sprzedawca klika link instalacyjny → Shopify przekierowuje na App URL z parametrami zapytania shop i hmac
- AdlerDo
/api/shopify/install weryfikuje HMAC względem Client Secret i przekierowuje na https://{shop}/admin/oauth/authorize ze skonfigurowaną listą zakresów i wygenerowanym nonce'em stanu (state)
- Sprzedawca zatwierdza zakresy na ekranie zgody Shopify
- Shopify przekierowuje na
/api/shopify/callback z parametrami code, hmac i state
- AdlerDo weryfikuje HMAC oraz nonce stanu, a następnie wysyła metodą POST code + Client ID + Client Secret na
https://{shop}/admin/oauth/access_token, aby otrzymać token dostępu offline
- Token jest zapisywany z szyfrowaniem AES-256 przypisanym do tenanta; rejestrowane są subskrypcje webhooków oraz cykliczne zadania synchronizacji Hangfire
- AdlerDo przekierowuje sprzedawcę na osadzony adres URL administracji
10.3 Weryfikacja instalacji
Po uścisku dłoni (handshake):
- Potwierdź, że w bazie danych tenanta istnieje nowa encja
ShopifyConnection z niepustym EncryptedAccessToken oraz przyznaną listą zakresów
- Potwierdź, że cykliczne zadania (
SyncShopifyOrdersV2026, SyncShopifyProductsV2026) są zarejestrowane w Hangfire pod nowym identyfikatorem tenanta
- Wyzwól testowy webhook z panelu administracyjnego Shopify i potwierdź, że handler AdlerDo przetwarza go bez błędów HMAC
Załącznik A — Typowe zakresy używane przez AdlerDo
| Zakres |
Zastosowanie w AdlerDo |
read_products, write_products |
Synchronizacja katalogu: tworzenie/aktualizacja produktów i wariantów z Odoo lub JTL-Wawi |
read_orders, write_orders |
Pobieranie zamówień do AdlerDo oraz odsyłanie edycji zamówień / realizacji |
read_inventory, write_inventory |
Synchronizacja poziomów zapasów według lokalizacji |
read_locations |
Rozpoznawanie lokalizacji realizacji dla zapasów i wysyłki |
read_fulfillments, write_fulfillments |
Tworzenie realizacji i przekazywanie numerów śledzenia od przewoźników: DHL, GLS, DPD, DB Schenker |
read_assigned_fulfillment_orders, write_assigned_fulfillment_orders |
Wymagane, gdy AdlerDo działa jako zarejestrowana usługa realizacji zamówień |
read_customers, write_customers |
Synchronizacja klientów i segmentacja B2B |
read_shipping |
Odczyt konfiguracji przewoźnika i stref do obliczania stawek |
read_app_proxy, write_app_proxy |
Wymagane dla osadzonych tras proxy administracji |
read_analytics |
Pulpity raportowe w osadzonym panelu administracyjnym |
Załącznik B — Rozwiązywanie problemów
Przekierowanie instalacji zwraca 401 / Invalid HMAC
Przyczyna: Client Secret w konfiguracji AdlerDo nie zgadza się z sekretem w Settings albo sekret został poddany rotacji bez ponownego wdrożenia.
Działanie: Skopiuj sekret ze strony Settings w Dev Dashboard i wdróż ponownie.
Wywołanie zwrotne OAuth zwraca 'redirect_uri is not whitelisted'
Przyczyna: Adres URL wywołania zwrotnego nie znajduje się w polu Redirect URLs aktywnej wersji.
Działanie: Otwórz aktywną wersję, dodaj adres URL, opublikuj nową wersję i ponów instalację.
Sklep się instaluje, ale nie pojawiają się zadania Hangfire
Przyczyna: Wymiana kodu OAuth powiodła się, ale zainicjowanie po instalacji (bootstrap) nie powiodło się (np. provisioning tenanta).
Działanie: Przejrzyj logi AdlerDo w okolicy znacznika czasu instalacji; ShopifyInstallController emituje log poziomu Information dla każdego etapu oraz log poziomu Error z krokiem, który się nie powiódł.
Dostarczanie webhooków kończy się błędami HMAC
Przyczyna: AdlerDo obliczył HMAC webhooka na podstawie sparsowanego ładunku zamiast surowego ciała (raw body).
Działanie: Potwierdź, że middleware żądań buforuje surowe ciało żądania przed model bindingiem dla tras /api/shopify/webhooks/*.
Sprzedawca zgłasza brakujące dane po dodaniu zakresu
Przyczyna: Sklep został zainstalowany względem starszej wersji, która nie zawierała tego zakresu.
Działanie: Wyzwól przekierowanie do ponownej instalacji — AdlerDo wykrywa rozbieżność zakresów w ShopifyConnectionMiddleware i przekierowuje do punktu końcowego instalacji, gdzie sprzedawca zatwierdza nowy zakres.