Automatyzacja Easytools: webhooki, API i serwer MCP

Automatyzacje w panelu: poziom produktu i poziom sklepu

Zanim wejdę w webhooki, przechodzę przez panel. Sporo procesów po sprzedaży Easytools domyka sam, a nieużyta funkcja z panelu jest zawsze tańsza w utrzymaniu niż scenariusz na zewnątrz.

Ustawienia siedzą w dwóch miejscach i robią co innego:

• Poziom produktu, w edytorze koszyka. Scenariusze, czyli pary „to zdarzenie uruchamia tę akcję w tej aplikacji”, oraz adres webhooka dla tego jednego produktu.
• Poziom sklepu, w ustawieniach sklepu. Globalny adres webhooka dziedziczony przez każdy nowy koszyk, klucz do podpisu webhooka i klucze API.

Z tego podziału bierze się kolejność przy wdrożeniu. Globalny webhook i klucze ustawia się raz na sklep, a scenariusze dokłada się tam, gdzie pojedynczy produkt ma prowadzić inną ścieżkę niż reszta oferty.

Osobno stoi warstwa sprzedażowa, która działa bez żadnej integracji: odzyskiwanie porzuconego koszyka, upselle i cross-selle, oferty czasowe, kody rabatowe, linki afiliacyjne, faktury i podatki oraz kampanie w easymail.

Poziom produktu: scenariusze i webhook w koszyku

Menu Automatyzacje w edytorze produktu ma dwie pozycje: Scenariusze i Webhook. Siedzą obok siebie, ale rozwiązują różne problemy. Scenariusz to jedno zdarzenie spięte z jedną akcją w konkretnej aplikacji, całość klikana w panelu. Webhook to surowy strumień zdarzeń wypchnięty pod Twój adres, gdzie logikę dopisujesz sam.

Uwaga na słownictwo: samo „scenariusz” oznacza tu funkcję z panelu Easytools. Scenariusze w Make i n8n nazywam dalej po nazwie narzędzia.

Scenariusze: jedno zdarzenie, jedna akcja, wybrane warianty

Kreator „Nowa automatyzacja” mieści się na jednym ekranie:

• Nazwa i przełącznik włączający całą automatyzację, w prawym górnym rogu.
• Zdarzenie z listy dziesięciu pozycji (niżej). Po wyborze pod polem pojawia się opis, co dokładnie je wyzwala.
• W momencie zdarzenia - przełącznik, domyślnie włączony.
• Wyślij email o niepowodzeniu automatyzacji - domyślnie wyłączony. Włączam go zawsze. Bez tego nieudany scenariusz milczy, a dowiadujesz się o nim od klienta, który nie dostał dostępu.
• Przypisz do Wariantów - domyślnie „Wszystkie warianty”, ale listę da się zawęzić do pojedynczych wariantów cenowych. Ten sam produkt może więc inaczej obsługiwać pakiet roczny i miesięczny bez zakładania drugiego koszyka.
• Integracja - przełącznik „Istniejąca integracja” albo „Nowa integracja”. Raz utworzone połączenie wraca na liście przy kolejnych scenariuszach.

Panel i webhook nazywają te same rzeczy inaczej, a dokumentacja nie zestawia obu list. Poniżej moje zestawienie:

Zdarzenie w panelu	Odpowiednik w webhooku
Zrealizowano zamówienie	single_product_bought, subscription_created
Przypisano produkt do klienta	product_assigned
Zmiana planu subskrypcji	subscription_plan_changed
Anulowanie subskrypcji	subscription_canceled
Dostęp wygasa za 3 dni	product_access_expiring
Dostęp wygasł	product_access_expired
Odzyskiwanie koszyka	brak
Kod QR zeskanowany	brak
Synchronizuj zamówienia	brak
Klient na liście oczekujących	brak

Trzy rzeczy widać dopiero po zestawieniu obu list.

Pierwsza: „Zrealizowano zamówienie” obejmuje trzy sytuacje naraz. Opis w panelu brzmi „Klient rozpoczął subskrypcję, kupił produkt lub odebrał go za darmo”, więc darmowy odbiór produktu uruchomi ten scenariusz tak samo jak płatny zakup.

Druga: „Dostęp wygasa za 3 dni” ma okno wpisane w nazwę. Przypomnienie siedem dni wcześniej wymaga webhooka i własnego harmonogramu.

Trzecia: cztery zdarzenia z panelu nie mają odpowiednika w webhooku, a siedem zdarzeń webhooka nie ma odpowiednika w panelu. Odnowienie subskrypcji, zbliżające się odnowienie, nieudane pobranie środków, ostateczne wygaśnięcie, wznowienie, trwałe usunięcie i zmiana danych klienta istnieją wyłącznie po stronie webhooka. Windykacja nieudanych płatności i higiena danych klienta zaczynają się więc poza panelem.

Dwadzieścia aplikacji do wyboru

Lista przy tworzeniu nowego połączenia, w kolejności z panelu:

Obszar	Aplikacje
Mailing	Active Campaign, ConvertKit, GetResponse, Mailchimp, MailerLite, MailerLite Classic, Sendgrid
CRM	HubSpot, Pipedrive
Kursy i społeczności	Circle.so, Discord, Kajabi, Publigo, WebToLearn
Strona i dane	Airtable, Wordpress, Woocommerce
Wysyłka i spotkania	Furgonetka, Zencal
Własny odbiornik	Webhook

Dwie pozycje warto rozpoznać osobno. Webhook jest tu zwykłą aplikacją, więc scenariusz potrafi wysłać pod Twój adres jedno wybrane zdarzenie z jednego wybranego wariantu. To coś innego niż pole Webhook w menu Automatyzacje, które wysyła wszystko. MailerLite i MailerLite Classic to dwa osobne wpisy pod dwie generacje tego samego narzędzia; wybór złego kończy się połączeniem, które autoryzuje się poprawnie i nie widzi żadnej listy.

Easymail i Powiadomienia nie wymagają zakładania połączenia. Są w rozwijanej liście istniejących integracji od razu, bo należą do ekosystemu Easytools.

Statystyki wykonań zbierają się w osobnej zakładce Automatyzacje, w menu Sklep. Tam sprawdzasz, czy scenariusz w ogóle się uruchamia, zanim zaczniesz szukać błędu po drugiej stronie.

Webhook produktu: wszystkie zdarzenia pod jeden adres

Druga pozycja w tym samym menu to pole na adres webhooka dla tego konkretnego koszyka. Wpis nadpisuje ustawienie globalne ze sklepu.

Różnica wobec scenariusza jest zasadnicza. Scenariusz filtruje: jedno zdarzenie, jeden wariant, jedna akcja. Webhook wypycha komplet zdarzeń tego koszyka i zostawia Ci decyzję, co z nich obsłużyć. Dlatego scenariusze biorę na pojedyncze, dobrze opisane ruchy w gotowych narzędziach, a webhook wszędzie tam, gdzie potrzebuję warunków, danych z trzeciego systemu albo narzędzia, którego na liście dwudziestu nie ma.

Poziom sklepu: globalny webhook, klucz podpisu i klucze API

Ekran jest krótki, bo poziom sklepu ma tylko trzy rzeczy do ustawienia. Za to każda z nich obowiązuje wszędzie.

Adres webhooka. Trafia do każdego nowego koszyka, dopóki produkt go nie nadpisze. Zmiana adresu tutaj nie przestawia koszyków, które mają własny wpis, więc przy migracji scenariusza z Make do n8n sprawdzam oba poziomy.

Klucz do podpisu webhooka. Easytools podpisuje żądanie i wkłada wynik w nagłówek X-Webhook-Signature. Po stronie odbiornika liczysz SHA256 z treści żądania przy użyciu tego samego klucza i porównujesz wartości. Bez tego kroku Twój endpoint przyjmie dowolne żądanie, które ktoś pod ten adres wyśle, a webhook Make jest publiczny. Dokumentacja Easytools ma gotowe fragmenty w JavaScripcie, PHP, Pythonie i C#.

Klucz wyświetla się raz, przy tworzeniu, i nie da się go później odczytać. Panel pokazuje tylko datę utworzenia oraz przyciski „Usuń” i „Zmień klucz”. Wymiana klucza oznacza, że odbiornik liczący podpis starym kluczem od tej chwili go nie potwierdzi, więc jedno i drugie przestawiam w tym samym oknie.

Klucze API. Sekcja niżej, z tabelą: data utworzenia, nazwa, sklepy i ostatnie użycie. Opis w panelu mówi wprost, że klucz działa w każdym sklepie, w którym masz dostęp do API. Klucz jest osobisty i sięga do każdego sklepu, do którego zespół dał Ci dostęp przez API. Odebranie komuś uprawnień w sklepie odbiera je więc również jego kluczom, od następnego żądania.

Kolumna „Ostatnio używany” jest jedynym łatwym sposobem, żeby sprawdzić, który klucz można skasować bez wywalania działającej integracji. Dlatego każdy klucz nazywam po tym, co go używa, zamiast zostawiać „klucz 1”.

Webhooki: 14 zdarzeń i jedno, na którym warto oprzeć automatyzację

Pod adres webhooka, wpisany na którymkolwiek z dwóch poziomów, trafia czternaście typów zdarzeń:

Zdarzenie	Kiedy przychodzi
single_product_bought	zakup pojedynczego produktu
product_assigned	dostęp do produktu został przypisany użytkownikowi
product_access_expiring	dostęp niedługo wygaśnie
product_access_expired	dostęp wygasł
subscription_created	zakup nowej subskrypcji
subscription_renewed	odnowienie subskrypcji
subscription_renewal_upcoming	zbliża się odnowienie
subscription_renewal_failed	nieudana próba pobrania środków
subscription_plan_changed	zmiana planu z panelu
subscription_canceled	anulowanie subskrypcji, ważnej do końca okresu rozliczeniowego
subscription_expired	ostateczne wygaśnięcie subskrypcji
subscription_resumed	wznowienie subskrypcji
subscription_deleted	trwałe usunięcie subskrypcji
customer_data_changed	zmiana danych klienta

Zakup wysyła dwa zdarzenia

Po udanej transakcji Easytools wysyła single_product_bought albo subscription_created, a zaraz po tym product_assigned. Powodem jest funkcja „Kup dla kogoś innego”: kupujący i osoba z dostępem to nie zawsze ta sama osoba, więc przypisanie dostępu jest osobnym zdarzeniem. Nawet przy wyłączonej funkcji Easytools wysyła oba, dla spójności.

Scenariusz w Make nasłuchujący obu zdarzeń wykona się dwa razy po jednym zakupie. Dokumentacja Easytools zaleca oprzeć automatyzację na product_assigned i to jest też moja praktyka: obsługuje zakup dla siebie i dla kogoś innego, więc późniejsze włączenie tej funkcji niczego nie zepsuje.

Praktyczny dodatek: webhook potrafi przyjść ponownie. Zapisuję identyfikator zdarzenia i sprawdzam go przed utworzeniem kolejnego rekordu, zamiast ufać, że każda dostawa jest pierwsza.

Dwa API: easycart i easymail

To dwa osobne systemy z osobnymi tokenami, osobnymi adresami i różnym kształtem odpowiedzi. Traktowanie ich jako jednego API jest najczęstszym źródłem zaskoczenia przy pierwszej integracji.

	easycart	easymail
Adres bazowy	https://cart.easy.tools/api/v1	https://email.easy.tools/api/v1
Token	ustawienia sklepu, sekcja Developer	ustawienia easymail, sekcja Developer
Zakres tokena	osobisty, sięga do każdego sklepu z dostępem	należy do konta
Wybór celu	nagłówek X-Easycart-Store z UUID sklepu	brak, konto jest jedno
Limit	100 żądań / 60 s per sklep	100 żądań / 60 s per konto
Sukces	dane bezpośrednio w odpowiedzi	dane opakowane w klucz data
Błąd	{"message": "..."}	{"error": {"code": "...", "message": "..."}}

Token easycart generujesz pod adresem cart.easy.tools/creator/store-settings/developer, token easymail pod cart.easy.tools/creator/email/settings/developer. Wspólne dla obu: uwierzytelnianie tokenem w nagłówku Authorization: Bearer, do tego Content-Type: application/json i Accept: application/json w każdym żądaniu.

curl -H "Authorization: Bearer TWOJ_TOKEN" \
     -H "Content-Type: application/json" \
     -H "Accept: application/json" \
     "https://cart.easy.tools/api/v1/orders?status=completed&per_page=100"

Token easycart należy do użytkownika i sięga do Twojego sklepu oraz do każdego, którego zespół nadał Ci uprawnienie do korzystania z API. Gdy sklep tego dostępu nie dał, każdy endpoint zwraca 403, a odebranie uprawnienia działa od następnego żądania. Przy więcej niż jednym sklepie zawsze wskazuję sklep jawnie nagłówkiem X-Easycart-Store, zamiast liczyć na domyślny.

W easymail jest jeszcze jedna bramka. Dostęp do publicznego API jest domyślnie wyłączony i wygenerowanie tokena go nie włącza. Do czasu włączenia przez wsparcie każdy endpoint zwraca 403 z kodem PUBLIC_API_DISABLED. Zły token daje 401, więc te dwa przypadki da się rozróżnić w logach.

Co da się zrobić przez API

easycart

Zasób	Operacje
Sklep	lista sklepów, dane sklepu i jego walut
Produkty	lista, odczyt, tworzenie, aktualizacja, publikacja, wycofanie ze sprzedaży
Warianty cenowe	lista, odczyt, tworzenie, aktualizacja
Zamówienia	lista z filtrami, odczyt pojedynczego
Klienci	lista z filtrami, odczyt pojedynczego
Dostęp do produktu	nadanie, odebranie
Transakcje	lista, odczyt, zwrot pełny lub częściowy
Faktury	lista, odczyt, pobranie pliku, ponowna wysyłka
Kody rabatowe	lista, odczyt, tworzenie, aktualizacja, archiwizacja
Subskrypcje	lista, odczyt, anulowanie, wznowienie, zmiana planu
Statystyki	pojedyncza statystyka z porównaniem do poprzedniego okresu

easymail

Zasób	Operacje
Kontakty	lista, odczyt, tworzenie, upsert, aktualizacja, usunięcie, wypisanie, ponowny zapis, historia zdarzeń
Listy	lista, odczyt, tworzenie, aktualizacja, usunięcie, dodawanie i usuwanie kontaktów
Segmenty	lista, odczyt
Pola dodatkowe	definicje i wartości na kontakcie
Kampanie	tworzenie, edycja, wysyłka, planowanie, cofnięcie planu, anulowanie, e-mail testowy, usunięcie
Raportowanie kampanii	odbiorcy, kliknięcia w linki, statystyki otwarć
Nadawcy i strefy czasowe	lista zweryfikowanych adresów nadawcy, lista stref

Filtrowanie zamówień jest dobrze pomyślane i warto z niego korzystać zamiast pobierać wszystko: status, created_from, created_to, customer, product i query, wszystko łączone warunkiem „i”. Strona bierze maksymalnie 100 pozycji. Jeśli potrzebujesz samej liczby wyników, wywołaj endpoint z per_page=1 i odczytaj pagination.total, zamiast przewijać całą listę.

Cztery pułapki, pod które projektuję integrację

Zwrot jest asynchroniczny. POST /transactions/{id}/refunds zwraca 202, co znaczy tyle, że operator płatności przyjął zlecenie. Wpis o zwrocie, jego rozbicie podatkowe i powiadomienie klienta powstają dopiero po potwierdzeniu od operatora. Odczyt transakcji zaraz po zwrocie może jeszcze nie pokazać zmiany w refunds ani w refunded_amount. Scenariusz w Make, który potraktuje ten brak jako niepowodzenie i ponowi żądanie, zwróci pieniądze drugi raz.

Statystyki to jedno wywołanie na jedną liczbę. Endpoint GET /statistics przyjmuje jeden type naraz, a type i currency są obowiązkowe. Nieznana waluta zwraca 400 zamiast zer. Zakres podaje się slugiem (today, monthToDate, lastMonth, yearToDate, last7days, last30days, last3months, last12months, all) albo parą dat. Pulpit z sześcioma liczbami to sześć równoległych wywołań i sześć pozycji z limitu.

Limit dzieli się na wszystko. Sto żądań na sześćdziesiąt sekund obejmuje scenariusz w Make, własny skrypt i ruch z serwera MCP. Nocna synchronizacja, która pobiera zamówienia rekord po rekordzie, potrafi zablokować asystenta w środku pracy. Dlatego pobieram stronami po 100 pozycji i rozkładam ciężkie zadania w czasie.

Nieudane odnowienie subskrypcji rozciąga się w czasie. subscription_renewal_failed może przyjść kilka razy przed subscription_expired. Automatyzacja odbierająca dostęp przy pierwszym niepowodzeniu wyrzuci klienta, któremu karta odrzuciła płatność raz. Dostęp wygaszam na subscription_expired albo product_access_expired, a wcześniejsze niepowodzenia obsługuję komunikacją.

Trzy przepływy, które składam najczęściej

Zakup zakłada rekord w CRM-ie. Webhook product_assigned startuje scenariusz, który szuka osoby po adresie e-mail, tworzy ją tylko wtedy, gdy jej nie ma, wiąże z firmą, dopisuje szansę albo notatkę o zakupie i zapisuje identyfikator zamówienia po stronie CRM-u. Ten identyfikator jest później jedynym sposobem, żeby dowiązać zwrot do właściwego rekordu.

Dostęp do społeczności z wygaszaniem. product_assigned nadaje dostęp w Discordzie albo Circle, product_access_expiring wysyła przypomnienie, product_access_expired odbiera dostęp. Trzy zdarzenia, trzy różne skutki i żadnego cyklicznego sprawdzania, kto jeszcze ma opłacone.

Tygodniowy raport z API. Harmonogram pobiera przychód i sprzedaż z GET /statistics dla wybranego okresu razem z porównaniem do poprzedniego, dokłada liczbę nowych subskrypcji i wysyła zestawienie na kanał zespołu. Bez eksportów CSV i bez arkusza, który ktoś musi odświeżyć.

Serwer MCP Easytools: sklep i mailing w rozmowie z asystentem

Easytools wystawia własny, oficjalny serwer MCP. Jedno połączenie sięga do easycart i easymail.

Adres	https://mcp.easy.tools
Transport	Streamable HTTP
Autoryzacja	logowanie do konta Easytools albo token easycart
Limit	100 żądań / 60 s, wspólny z API

Klienci obsługujący OAuth podłączają się przez logowanie. W Claude Desktop wchodzisz w Ustawienia, sekcja Connectors, dodajesz własny konektor i podajesz adres serwera. Klienci bez OAuth wysyłają token easycart w nagłówku:

claude mcp add --transport http easytools https://mcp.easy.tools \
  --header "Authorization: Bearer TWOJ_TOKEN_EASYCART"

Akcje easymail wymagają dodatkowo uprawnienia do zarządzania kluczami API easymail na sklepie, na którym pracujesz.

Zakres jest szeroki. Po stronie easycart: sklep, produkty i warianty, zamówienia, klienci, dostęp do produktów, transakcje i zwroty, faktury, kody rabatowe, subskrypcje i statystyki. Po stronie easymail: kontakty, listy, segmenty, pola dodatkowe, kampanie razem z wysyłką i planowaniem oraz raportowanie kliknięć i odbiorców.

Które akcje trzeba trzymać krótko

Asystent działa jako Ty i z Twoimi uprawnieniami, więc lista rzeczy, które może zrobić bez pytania kogokolwiek, jest dokładnie tak długa jak Twoje uprawnienia w panelu. Warto wiedzieć, co na tej liście rusza pieniądze i klientów:

• Zwrot transakcji przenosi realne środki. Pełny zwrot dodatkowo odbiera klientowi dostęp do produktu i wysyła mu wiadomość.
• Archiwizacja kodu rabatowego jest nieodwracalna.
• Anulowanie subskrypcji, odebranie dostępu i ponowna wysyłka faktury dotykają klienta bezpośrednio.
• Wysyłka i zaplanowanie kampanii oraz e-mail testowy wysyłają prawdziwą pocztę.
• Wypisanie i ponowny zapis kontaktu zmieniają jego zgodę marketingową.
• Usunięcie kontaktu, listy, kampanii albo pola dodatkowego jest trwałe, a skasowanie pola usuwa jego wartość z każdego kontaktu.

Moje zasady przy uruchamianiu tego u klienta są trzy. Osobny token zamiast tego, którego używa produkcyjna integracja. Zaczynamy od pytań o dane, a operacje zapisujące wchodzą dopiero, gdy zespół zna zakres. Przed każdym potwierdzeniem człowiek czyta, co asystent zamierza zrobić, razem z kwotą i adresem klienta.

Kiedy MCP, a kiedy scenariusz w Make

Te dwie drogi rozwiązują różne problemy i nie zastępują się nawzajem.

MCP nadaje się do pracy, która za każdym razem wygląda inaczej i ma człowieka na końcu: sprawdzenie, dlaczego przychód spadł, znalezienie zamówienia po fragmencie adresu, wystawienie kodu na jedno wydarzenie, przygotowanie szkicu kampanii. Asystent składa kilka odczytów w odpowiedź, a Ty decydujesz, czy coś z tym zrobić.

Scenariusz w Make albo n8n nadaje się do przepływu, który ma wyglądać tak samo za każdym razem i działać, gdy nikogo nie ma przy komputerze: nadanie dostępu po zakupie, zapis w CRM-ie, faktura, raport o siódmej rano. Ma powtarzalny kształt, historię wykonań i alert, gdy coś padnie.

W większości wdrożeń kończy się na obu. Scenariusze pilnują powtarzalnych przepływów, a MCP siedzi obok jako narzędzie do pytań i akcji ad hoc.

Powiązane materiały

• Jak działają webhooki, ponowienia i ochrona przed duplikatami: Haki na automatyzację, czyli webhook i mailhook
• Jak oceniam API narzędzia przed zakupem: Dlaczego warto kierować się podejściem API-first
• Dokumentacja techniczna producenta: developers.easy.tools i instrukcja podłączenia serwera MCP
• Panel od strony użytkownika: lista zdarzeń webhooka i generowanie klucza do podpisu

Jeśli chcesz spiąć Easytools z resztą swoich narzędzi albo bezpiecznie podłączyć do sklepu asystenta AI, napisz do mnie.