Jak uzyskać Shopify Access Token w 2026 — gdy Develop Apps już nie działa

Co się zmieniło 1 stycznia 2026

Przez lata standardową ścieżką uzyskania Admin API access tokenu dla integracji z Shopify była opcja Develop apps, dostępna w panelu administratora sklepu pod ścieżką Settings → Apps and sales channels → Develop apps. Wystarczyło utworzyć aplikację, zaznaczyć wymagane scopes, kliknąć Install app i skopiować gotowy token. Cały proces zajmował dwie minuty i nie wymagał konta deweloperskiego ani zewnętrznego adresu callback.

W praktyce oznacza to, że każda integracja z systemem zewnętrznym — ERP, PIM, własny skrypt, hurtownia danych — wymaga utworzenia pełnoprawnej aplikacji w dev.shopify.com i przejścia przez standardowy flow autoryzacyjny OAuth 2.0.

Dlaczego Shopify wprowadził tę zmianę

Shopify nie podał szczegółowego uzasadnienia, ale z naszej perspektywy decyzja jest spójna z kierunkiem, który platforma utrzymuje od kilku lat — ujednolicenie modelu autoryzacji wokół OAuth i eliminacja długo żyjących statycznych tokenów tworzonych ad hoc przez właścicieli sklepów.

Naszym zdaniem zmiana ma trzy główne powody:

• Audytowalność — aplikacja w dev.shopify.com ma identyfikator, właściciela i historię instalacji. Token z Develop apps był przypisany do sklepu, a często powstawał poza wiedzą zespołu IT.
• Kontrola scope'ów — w modelu OAuth każda zmiana zakresu uprawnień wymaga ponownej zgody właściciela sklepu. Token z Develop apps można było rozszerzać po cichu.
• Spójność z ekosystemem partnerskim — wszystkie publiczne aplikacje już działały na OAuth. Utrzymywanie drugiej, uproszczonej ścieżki dla aplikacji prywatnych komplikowało dokumentację i zwiększało powierzchnię ataku.

Czego potrzebujesz zanim zaczniesz

Zanim przejdziemy do procesu, upewnij się, że masz wszystkie wymagane elementy:

• Konto deweloperskie Shopify — darmowe, do założenia na https://dev.shopify.com
• Sklep Shopify, na którym aplikacja zostanie zainstalowana — produkcyjny lub development store
• Klient HTTP do wysłania jednego requesta — curl, Postman lub Insomnia
• Adres URL callbacku — w tym przewodniku użyjemy bezpłatnego serwisu webhook.site, dzięki czemu nie trzeba stawiać własnego serwera

Krok 1: Utworzenie aplikacji w dev.shopify.com

Aplikacja w dev.shopify.com jest właścicielem klucza klienta (Client ID) i sekretu (Client secret) — dwóch wartości, których będziemy potrzebować w dalszej części procesu.

Krok 2: Konfiguracja webhook.site jako adresu callback

Adres callback to URL, na który Shopify przekieruje przeglądarkę po wyrażeniu zgody na instalację aplikacji. Zamiast stawiać tymczasowy serwer, użyjemy bezpłatnego serwisu, który generuje publiczny URL i pokazuje wszystkie przychodzące requesty.

Krok 3: Konfiguracja API scopes i URL-i aplikacji

Wracamy do panelu dev.shopify.com, do utworzonej w kroku pierwszym aplikacji. Należy uzupełnić dwie sekcje konfiguracji.

Configuration → URLs

W zakładce Configuration znajdź sekcję URLs i wypełnij pola:

• App URL — adres URL z webhook.site (Shopify wymaga, żeby pole było wypełnione, ale dla integracji wewnętrznej nie ma znaczenia funkcjonalnego)
• Allowed redirection URL(s) — ten sam adres URL z webhook.site. To pole jest kluczowe — Shopify odmówi przekierowania na adres, którego nie ma na białej liście

Configuration → API access scopes

W tej samej zakładce znajdź sekcję API access scopes i zaznacz uprawnienia, których będzie wymagała Twoja integracja. Po zaznaczeniu zatwierdź zmiany przyciskiem Save. Pełna lista scopes dostępna jest w dokumentacji Shopify pod hasłem Admin API access scopes.

Krok 4: Custom distribution w partners.shopify.com

Domyślnie aplikacja utworzona w dev.shopify.com nie da się zainstalować na żadnym sklepie produkcyjnym — instalacja działa wyłącznie w development stores należących do Twojego konta deweloperskiego. Dla integracji wewnętrznej, która ma działać na konkretnym sklepie klienta, trzeba dodatkowo skonfigurować kanał dystrybucji.

Konfiguracja dystrybucji odbywa się w partners.shopify.com — oddzielnym panelu dla partnerów Shopify, do którego logujemy się tym samym kontem co do dev.shopify.com.

Krok 5: Instalacja aplikacji i przechwycenie kodu

W standardowej publicznej aplikacji Shopify w tym miejscu pojawiałby się formularz instalacji oferowany przez App Store. Dla aplikacji prywatnej zbudujemy URL instalacji ręcznie i wkleimy go do przeglądarki zalogowanej jako właściciel sklepu.

Format URL-a autoryzacji:

https://{nazwa-sklepu}.myshopify.com/admin/oauth/authorize
  ?client_id={CLIENT_ID}
  &scope=read_products,write_products,read_orders
  &redirect_uri={URL_Z_WEBHOOK_SITE}
  &state={DOWOLNY_RANDOM_STRING}

Podstaw wartości:

• {nazwa-sklepu} — pełna nazwa sklepu z poddomeną .myshopify.com (nie własna domena marki)
• {CLIENT_ID} — wartość z sekcji Client credentials z kroku pierwszego
• scope — lista scopes rozdzielonych przecinkiem, bez spacji
• redirect_uri — URL z webhook.site, identyczny z tym wpisanym w Allowed redirection URL
• state — dowolny ciąg znaków, służy do ochrony przed CSRF; w procesie ręcznym wystarczy losowa wartość

Krok 6: Wymiana kodu na Access Token

Kod autoryzacyjny ma krótki czas ważności i można go wymienić tylko raz. Wymiana odbywa się przez request POST na endpoint /admin/oauth/access_token Twojego sklepu, z trzema parametrami: client_id, client_secret i code.

Komenda curl:

curl -X POST https://{nazwa-sklepu}.myshopify.com/admin/oauth/access_token \
  -d "client_id={CLIENT_ID}" \
  -d "client_secret={CLIENT_SECRET}" \
  -d "code={CODE_Z_WEBHOOK_SITE}"

Odpowiedź serwera:

{
  "access_token": "shpat_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "scope": "read_products,write_products,read_orders"
}

Przykład pierwszego wywołania — pobranie listy produktów:

curl https://{nazwa-sklepu}.myshopify.com/admin/api/2025-10/products.json \
  -H "X-Shopify-Access-Token: shpat_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Dlaczego to tylko workaround, a nie docelowe rozwiązanie

Proces opisany powyżej pozwala uzyskać działający Access Token bez stawiania własnej infrastruktury, ale ma sens wyłącznie w dwóch scenariuszach: jednorazowego skryptu migracyjnego albo szybkiego prototypu integracji. Nie jest to rozwiązanie, na którym można oprzeć produkcyjną integrację z Shopify.

Jak wygląda poprawne, docelowe rozwiązanie

Naszym zdaniem produkcyjna integracja z Shopify wymaga aplikacji uruchomionej na publicznym serwerze HTTPS, która samodzielnie obsługuje cały flow OAuth. Klucze elementy takiej architektury:

• Endpoint instalacji — własny URL pod kontrolą zespołu, do którego Shopify przekierowuje przeglądarkę po wyrażeniu zgody. Aplikacja odczytuje parametry code, shop, hmac, state i weryfikuje ich autentyczność.
• Weryfikacja HMAC — każdy request z Shopify zawiera podpis HMAC-SHA256 wyliczony z client secret. Aplikacja musi zweryfikować ten podpis, zanim zaufa zawartości requesta — w workaroundzie ten krok jest pomijany.
• Automatyczna wymiana kodu na token — aplikacja po stronie serwera wykonuje request POST na /admin/oauth/access_token bez udziału użytkownika. Token nigdy nie pojawia się w przeglądarce ani w logach pośrednika.
• Trwałe przechowywanie tokenu — token zapisywany jest w bazie danych aplikacji, powiązany z identyfikatorem sklepu, zaszyfrowany lub umieszczony w secret managerze.
• Obsługa zmian scope'ów — gdy integracja wymaga nowych uprawnień, aplikacja sama inicjuje ponowną autoryzację i odświeża token, bez ingerencji administratora sklepu w ustawienia aplikacji.
• Webhook na app/uninstalled — aplikacja nasłuchuje, kiedy właściciel sklepu odinstalowuje integrację, i czyści lokalnie zapisany token, zamiast trzymać martwy klucz w bazie.

Z naszego doświadczenia minimalna stack-owa implementacja takiej aplikacji to publiczny serwer (np. VPS lub PaaS), certyfikat HTTPS, jeden endpoint /auth/callback, weryfikacja HMAC oraz baza danych do przechowywania tokenów per sklep. Shopify dostarcza gotowe biblioteki OAuth dla Node, Ruby, PHP i Pythona, które obsługują ten flow w kilkunastu liniach kodu — problem jest infrastrukturalny, nie programistyczny.

Podsumowanie

Blokada Develop apps wydłużyła proces uzyskania Access Tokenu z dwóch minut do około piętnastu, ale w zamian ujednoliciła model autoryzacji i wymusiła kontrolę nad tym, kto i w jakim zakresie integruje się ze sklepem. Kluczowe wnioski z tego przewodnika:

• Każda integracja wymaga aplikacji w dev.shopify.com — nawet jednorazowy skrypt
• webhook.site eliminuje konieczność stawiania własnego serwera tylko po to, żeby odebrać kod autoryzacyjny
• redirect_uri w URL-u autoryzacji musi być identyczny z wpisanym w Allowed redirection URL
• Kod autoryzacyjny można wymienić tylko raz i wygasa po kilku minutach
• Token shpat_ to długo żyjący klucz — przechowuj go jak hasło produkcyjne