Reactor API (dawniej Adobe Launch API) to interfejs REST Adobe do zarządzania każdym zasobem wewnątrz Adobe Experience Platform Tags, właściwościami, regułami, data elements, rozszerzeniami, bibliotekami i środowiskami publikacji, bez tknięcia UI. Działa pod adresem reactor.adobe.io, autoryzuje przez Adobe I/O OAuth Server-to-Server i udostępnia około 20 typów zasobów, które pokrywają się z tym, co widać w konsoli AEP Tags.
A gdyby każda reguła w Twojej właściwości AEP Tags mogła być pod kontrolą wersji, recenzowana w pull requestcie i wdrażana przez CI pipeline, dokładnie tak jak kod aplikacji?
Właśnie to umożliwia Reactor API. Jeśli kiedykolwiek klikałeś przez 47 reguł, żeby podmienić jedno Data Element po redesignie strony, wiesz już, dlaczego to ma znaczenie. UI jest spoko przy małym wolumenie. Rozpada się w momencie, gdy masz 100+ reguł, trzy właściwości albo deadline migracji.
Poniżej opiszę, co faktycznie robi Reactor API w 2025, jak działa autoryzacja po odejściu Adobe od JWT, które zasoby musisz rozumieć i use case'y, w których to API zwraca się już przy pierwszym projekcie. Używam Reactor API do audytów, migracji z Adobe Launch do AEP Tags i setupów CI/CD tag management dla europejskich zespołów mid-market od 2022 roku.
Kluczowe wnioski
Reactor API to to samo API, które było znane jako Adobe Launch API, tylko pod nową nazwą po tym, jak Adobe rebrandował Launch na AEP Tags w 2021. Endpoint (reactor.adobe.io) i większość kształtów zasobów pozostały identyczne, więc istniejące integracje nie padły
Od poczatku 2025 autoryzacja JWT jest w pełni wycofana. Wszystkie integracje Reactor API muszą teraz korzystać z OAuth Server-to-Server z Adobe Developer Console
Limit to 120 requestów na minutę na integrację, z nagłówkiem retry-after 10 sekund przy odpowiedziach 429. Oficjalny klient @adobe/reactor-sdk dla Node.js obsługuje throttling automatycznie
Use case'y, które uzasadniają inwestycję w API: backup i restore właściwości, masowa migracja reguł (200+), pipeline'y publikacji CI/CD, zautomatyzowane audyty wielu właściwości brandowych
API nic dodatkowo nie kosztuje, jest w cenie licencji Adobe Experience Platform Tags. Kosztuje za to czas inżyniera na setup autoryzacji, obsługi błędów i testów przeciwko właściwości non-prod
Czym tak naprawdę jest Reactor API
AEP Tags, narzędzie znane dawniej jako Adobe Launch, to system zarządzania tagami z trzyśrodowiskowym workflow publikacji (Development, Staging, Production), marketplace'em rozszerzeń i silnikiem reguł opartym o Data Elements oraz Rule Components.
Reactor API to interfejs REST pod tym UI. Każde kliknięcie w konsoli AEP Tags finalnie staje się wywołaniem API do reactor.adobe.io. Kiedy tworzysz regułę, POST-ujesz do /properties/{id}/rules. Kiedy publikujesz bibliotekę, PATCH-ujesz zasób Build. UI to klient. API to źródło prawdy.
Od Adobe Launch API do Reactor API
Adobe wypuścił narzędzie jako "Launch by Adobe" w 2018 roku. API wewnętrznie zawsze nazywało się "Reactor", widać to w endpoincie i w oficjalnym SDK Node.js (@adobe/reactor-sdk), oba poprzedzają rebranding. W 2021 Adobe przeniósł Launch pod parasol Experience Platform i zmienił nazwę produktu na "Tags in Adobe Experience Platform", w skrócie AEP Tags.
Nazwa API nie zmieniła się. Dokumentacja, SDK i endpointy wciąż mówią Reactor. Jeśli dziedziczysz kod, który importuje @adobe/reactor-sdk, to integracja z Reactor API (AEP Tags API).
Praktyczna konsekwencja: szukając "Adobe Launch API documentation" dziś trafisz na przedawnione posty z forów. Szukaj "Reactor API", żeby znaleźć aktualne docsy Adobe na developer.adobe.com.
Co faktycznie możesz z tym zrobić
API eksponuje każdy typ zasobu AEP Tags, który widzisz w UI, plus kilka administracyjnych:
- Properties: kontener najwyższego poziomu dla strony albo aplikacji. Zwykle jedna property na domenę.
- Rules: logika if-this-then-that (eventy + warunki + akcje).
- Data Elements: reusable definicje zmiennych (nazwa strony, user ID, wartość koszyka).
- Extensions: zainstalowane moduły (Adobe Analytics, Web SDK, Google Analytics 4, własne rozszerzenia).
- Rule Components: pojedyncze eventy, warunki i akcje dołączone do reguły.
- Libraries: wdrażalny pakiet reguł, data elements i rozszerzeń.
- Environments: Development, Staging, Production na property.
- Builds: skompilowany artefakt, który trafia do środowiska.
- Hosts: skąd serwowane są biblioteki (Adobe-managed albo własny CDN).
- Callbacks: webhooki do notyfikacji statusu buildów.
Możesz listować, tworzyć, aktualizować, kasować i w większości przypadków rewidować każdy z nich. To pokrywa 95% tego, co chciałbyś automatyzować.
Jak działa autoryzacja Reactor API w 2025
To jest sekcja, na której potykają się zespoły, bo Adobe zmienił model autoryzacji w 2024-2025.
Stary sposób (wycofany): credentiale JWT Service Account. Jeśli miałeś integrację Reactor API zbudowaną przed 2024, to prawie na pewno używała JWT. Adobe wyłączył autoryzację JWT dla wszystkich API Experience Platform z dniem 1 stycznia 2025. Jeśli Twoja integracja cicho padła na początku 2025, to najbardziej prawdopodobna przyczyna.
Obecny sposób: credentiale OAuth 2.0 Server-to-Server z Adobe Developer Console.
Flow setupu:
- Wejdź na console.adobe.io i stwórz Project.
- Dodaj do projektu Adobe Experience Platform Tags API (wciąż z ikoną Reactor).
- Wybierz OAuth Server-to-Server jako typ credentiali.
- Przypisz integrację do Product Profile, który ma dostęp do AEP Tags w Twojej organizacji Adobe Admin Console.
- Dostajesz Client ID, Client Secret, Organization ID i listę scope'ów.
- Wymień je na krótkoterminowy access token (24h) pod ims-na1.adobelogin.com/ims/token/v3.
- Dołączaj access token, Client ID i Organization ID w nagłówkach każdego requesta Reactor API.
Produkcyjna integracja odświeża access token przed każdą paczką wywołań API albo on-demand, kiedy dostaje 401. Oficjalne SDK obsługuje to automatycznie, jeśli podasz mu credentiale OAuth.
Ważne uwagi o uprawnieniach: user albo service account przypisany do integracji musi mieć dostęp do konkretnej Property, do której wołasz. Rola "Developer" na property wystarczy do odczytu i większości operacji zapisu. Rola "Approver" jest wymagana do publikacji do Staging albo Production.
Core zasoby Reactor API, których faktycznie będziesz używał
Większość realnej pracy z Reactor API dotyka czterech-pięciu zasobów, nie wszystkich dwudziestu. Oto co musisz wiedzieć o każdym.
Properties
GET /properties/{PROPERTY_ID} zwraca metadata pojedynczej property AEP Tags. Używasz tego, żeby potwierdzić, że integracja ma dostęp, i żeby wylistować zainstalowane na property Extensions.
Property ma pole platform (web albo mobile), tablicę domains (strony, które ta property obsługuje) i flagę rule_component_sequencing_enabled (ważna przy debugowaniu race conditions).
Rules
GET /properties/{id}/rules zwraca wszystkie reguły w property, paginowane. Reactor API paginuje domyślnie po 25 wyników na stronę, maksymalnie 100. Dla property ze 100+ regułami zawsze dokładaj logikę paginacji.
Reguła ma nazwę, opis i flagę enabled na najwyższym poziomie. Właściwy trigger i logika akcji żyje w przypisanych Rule Components, to osobny zasób.
Rule Components
GET /properties/{id}/rules/{rule_id}/rule_components zwraca eventy, warunki i akcje pojedynczej reguły. Tutaj spędzisz najwięcej czasu w API, jeśli audytujesz albo migrujesz.
Rule component ma delegate_descriptor_id (referencja do Extension), pole settings (skonfigurowane wartości jako JSON string) i rule_component_type równy events, conditions albo actions.
Data Elements
GET /properties/{id}/data_elements zwraca wszystkie Data Elements. Każdy ma blob JSON settings, który zależy od typu (atrybut DOM, zmienna JavaScript, Local Storage itd.). Aktualizowanie settings Data Elements to najczęstsza operacja masowa, którą puszczam przez API.
Libraries i Builds
Library to kolekcja reguł, data elements i rozszerzeń, które chcesz wdrożyć razem. Build to skompilowany output biblioteki.
POST /properties/{id}/libraries tworzy bibliotekę. Potem dołączasz zasoby przez /libraries/{id}/relationships/rules (i analogiczne endpointy). Dalej POST /libraries/{id}/builds, żeby skompilować. Potem przeprowadzasz bibliotekę przez stany: development → submitted → approved → published.
Tak właśnie CI/CD pipeline triggeruje publish. Zero kliknięć w UI.
Chcesz sprawdzić, czy automatyzacja API ma sens w Twoim setupie AEP Tags? Napisz do mnie po szczerą ocenę. Jeśli odpowiedź brzmi "UI wystarczy", powiem to wprost.
Praktyczne use case'y, które uzasadniają API
Reactor API jest potężny, ale nie zawsze to właściwe narzędzie. Oto cztery use case'y, w których inwestycja w API się zwróciła u zespołów, z którymi pracowałem.
Use case 1: CI/CD dla tag management
Kiedy Marek, lead developer w polskim fintechu, przejął property AEP Tags swojej firmy w marcu 2025, workflow publikacji to był czysty chaos. Każdy analityk z rolą "Approver" mógł pushować bezpośrednio do Production. Nie było changeloga, code review ani sposobu na rollback złej reguły poza ręcznym cofnięciem.
Zbudowaliśmy pipeline Reactor API w trzy tygodnie. Każda zmiana reguły żyje teraz w repo Git jako plik JSON. Workflow GitHub Actions waliduje strukturę reguły, diffuje ją względem live property przez API, puszcza dry-run build przeciwko środowisku Staging i otwiera pull request z wynikami. Drugi analityk recenzuje PR. Po merge workflow PATCH-uje żywą regułę i publikuje bibliotekę Staging. Klikamy Production promotion ręcznie w UI, ten gate celowo zostawiliśmy manualny.
Sześć miesięcy później zespół ma zero incydentów produkcyjnych ze złych deployów tagów. Przed pipelinem średnio jeden zły deploy na kwartał.
Use case 2: Masowa migracja (Launch → AEP Tags albo między property)
Agnieszka, martech architect w europejskiej grupie retailowej, musiała zmigrowac property z 340 regułami z jednej Adobe Organization do drugiej po restrukturyzacji korporacyjnej w 2025. UI AEP Tags nie wspiera klonowania property między organizacjami. Agencje wyceniały ręczny rebuild na 40 000 EUR.
Napisaliśmy 200-linijkowy skrypt Node.js z Reactor SDK. Wyeksportował wszystkie reguły, data elements, rule components i rozszerzenia ze źródłowej property do JSON-a. Potem re-importował je do świeżo stworzonej property w docelowej organizacji, tłumacząc delegate_descriptor_id między dwiema instalacjami Extension. Cała migracja to 4 dni pracy inżyniera plus 2 dni walidacji danych. Całkowity koszt: poniżej 6 000 EUR.
Ten sam pattern działa przy duplikowaniu property między wieloma stronami brandowymi albo przy backupie property przed ryzykowną zmianą.
Use case 3: Zautomatyzowane audyty cross-property
Jeśli zarządzasz AEP Tags w 5+ property (częste w enterprise z wieloma stronami brandowymi), UI staje się bezużyteczny przy audytach kwartalnych. Nie odpowiesz na pytanie "które reguły odpalają się na page load checkoutu w naszych wszystkich property" bez API.
Skrypt audytowy Reactor API może odpytać wszystkie property, zrzucić ich reguły i rule components i zbudować arkusz odpowiadający dokładnie na to pytanie. Dla Tomasza, analytics leada w grupie ubezpieczeniowej, z którym pracowałem latem 2025, skrypt wyflagował 23 reguły w 7 property, które wciąż odpalały się na przestarzałą nazwę eventu, której nikt nie posprzątał po redesignie strony w 2024. Poprawienie ich zredukowało fantomowe beacony Adobe Analytics o 11% grupowo.
Use case 4: Integracje oparte o webhooki
Zasób Callbacks pozwala zarejestrować webhook, który odpala się, kiedy Build się uda, padnie, albo Library zmieni stan. Tak właśnie integruje się publikacje AEP Tags z notyfikacjami Slack, automatyzacją ticketów Jira albo downstream systemami deploymentu.
Typowy setup: kiedy Production Build się kończy, webhook postuje sformatowaną wiadomość na kanał #martech-deploys zespołu, z nazwą biblioteki, kto to zaakceptował i linkiem do logów buildu.
Masz konkretną automatyzację w głowie? Robię jednorazowe projekty Reactor API i ongoing support. Zobacz moje usługi GTM i AEP Tags do wyceny scope'owanych zleceń.
Limity, błędy i best practice'y
Reactor API ma miękki limit 120 requestów na minutę na integrację. W praktyce widziałem bursty do 200 RPM przechodzące bez throttlingu, ale planuj na 120.
Kiedy dobijesz do limitu, dostajesz odpowiedź 429 Too Many Requests z nagłówkiem Retry-After w sekundach. Oficjalne SDK cofa się automatycznie. Jeśli piszesz surowe wywołania fetch, zaimplementuj exponential backoff z jitterem.
Inne kody odpowiedzi, z którymi się spotkasz:
400: zmalformowane ciało requesta, zwykle naruszenie schematu JSON. W ciele odpowiedzi jest konkretne pole.401: wygasły albo brakujący access token. Odśwież token i spróbuj raz.403: Twoja integracja albo user nie ma wymaganej roli na Property.404: złe property ID, rule ID albo zasób został usunięty.409: konflikt równoległej modyfikacji. Często kiedy dwa procesy aktualizują tę samą regułę naraz. Re-fetch i retry.500: błąd po stronie Adobe. Retry z backoffem. Jeśli utrzymuje się, sprawdź status.adobe.com.
Best practice 1: zawsze testuj najpierw na property non-prod. Stwórz sandbox property w swojej organizacji Adobe specjalnie pod development Reactor API. Przypisz do niej swoją integrację. Psuj tam rzeczy.
Best practice 2: revisions to twój przyjaciel. Reguły, data elements i rule components wspierają revisions (historię wersji). Przed masową aktualizacją wylistuj obecne revisions jako backup. Jeśli coś pójdzie źle, PATCH każdy zasób z powrotem do poprzedniego revision_number.
Best practice 3: używaj SDK, nie surowego fetch, do czegokolwiek nietrywialnego. Klient @adobe/reactor-sdk dla Node.js obsługuje paginację, odświeżanie access tokena, retry i normalizację kształtu odpowiedzi. Czas, który zaoszczędzisz w pierwszym tygodniu developmentu, spłaca naukę SDK.
Best practice 4: ustaw monitoring Callback wcześnie. Nawet jeśli nie budujesz jeszcze integracji Slack, zarejestruj Callback, który POST-uje na endpoint logujący. Podziękujesz sobie pierwszy raz, kiedy Production build padnie cicho o 3 nad ranem.
Kiedy NIE używać Reactor API
Szczera odpowiedź: większość zespołów AEP Tags w ogóle nie powinna ruszać Reactor API.
- Jeśli Twoja property ma poniżej 50 reguł i zarządza nią jedna osoba, UI jest szybszy niż jakikolwiek workflow API.
- Jeśli nie masz w zespole developera, który może utrzymać autoryzację, obsługę błędów i okazjonalne upgrade'y SDK, integracja API zgnije w 18 miesięcy.
- Jeśli oceniasz, czy AEP Tags to w ogóle właściwa platforma, zacznij od kompletnego poradnika AEP Tags (Adobe Launch) i pytania o to, czy potrzebujesz pomocy z tag management, zanim zainwestujesz w automatyzację.
- Jeśli jesteś małym zespołem na Google Analytics 4 i GTM, z AEP Tags tylko pod jedną legacy property, rozważ przeniesienie legacy property na GTM Server-Side zamiast inwestować w ekspertyzę Reactor API.
API to inwestycja. Zwraca się zespołom, które mają dość pracy na AEP Tags, żeby amortyzować koszt setupu.
Najczęściej zadawane pytania
Jaka jest różnica między Adobe Launch API a Reactor API?
To to samo API. "Adobe Launch API" to nazwa, której zespoły używały w latach 2018-2021, kiedy produkt nazywał się Adobe Launch. Kiedy Adobe rebrandował produkt na "AEP Tags" w 2021, API zachowało swoją wewnętrzną nazwę, Reactor. Endpoint (reactor.adobe.io) i SDK (@adobe/reactor-sdk) nigdy się nie zmieniły. Dowolna dokumentacja albo kod odnoszący się do "Adobe Launch API" aplikuje się bez zmian do dzisiejszego Reactor API.
Jak autoryzuję się do Reactor API w 2025?
Użyj credentiali OAuth Server-to-Server z Adobe Developer Console (console.adobe.io). Stwórz Project, dodaj API Adobe Experience Platform Tags, wygeneruj credentiale OAuth Server-to-Server i wymień je na access token 24-godzinny pod ims-na1.adobelogin.com/ims/token/v3. Autoryzacja JWT Service Account została wycofana 1 stycznia 2025 i nie działa już.
Jaki jest limit Reactor API?
120 requestów na minutę na integrację. Kiedy przekroczysz, API zwraca status 429 z nagłówkiem Retry-After. Oficjalny @adobe/reactor-sdk obsługuje retry automatycznie. Planuj na 120 RPM, nawet jeśli bursty sporadycznie przechodzą bez throttlingu.
Czy mogę użyć Reactor API do backupu property AEP Tags?
Tak, i to jeden z najczęstszych legalnych use case'ów. Skrypt backupu odpytuje wszystkie property, reguły, data elements, rule components, extensions i biblioteki, a potem zapisuje JSON do repo Git albo cloud storage. Restore jest trudniejsze, bo delegate ID przesuwają się między instalacjami Extension, ale strona eksportu jest prosta i wart cotygodniowego uruchamiania na dowolnej produkcyjnej property.
Jakie języki programowania działają z Reactor API?
Dowolny język z klientem HTTP. Adobe wypuszcza oficjalny SDK Node.js (@adobe/reactor-sdk), który jest najwygodniejszy. Zespoły, z którymi pracowałem, budowały produkcyjne integracje w Pythonie (używając biblioteki requests), Go i PowerShellu dla jednego Windows-based enterprise. Nie ma language lock-inu, to czyste REST API.
Czy muszę dopłacać za Reactor API?
Nie. Dostęp do API jest w cenie dowolnej licencji Adobe Experience Platform Tags. Płacisz za czas inżyniera na budowę i utrzymanie integracji. Prosty skrypt backupu to kilka dni pracy. Pełen pipeline CI/CD to 2-4 tygodnie.
Podsumowanie
Reactor API to to samo Adobe Launch API, którego zespoły używają od 2018, tylko pod nowym brandem AEP Tags. Jeśli masz mniej niż 50 reguł i nie masz dedykowanego developera, zostań przy UI. Jeśli zarządzasz setkami reguł, wieloma property albo migracją, API to różnica między weekendem klikania a popołudniem skryptowania.
Trzy najbardziej wartościowe use case'y to publikacja CI/CD tagów, audyty cross-property i masowe migracje. Każdy z nich spłaca koszt setupu już przy pierwszym projekcie, jeśli zespół ma odpowiedni wolumen. Zacznij od postawienia integracji OAuth Server-to-Server przeciwko sandbox property. Sklonuj kilka reguł programowo. Kiedy poczujesz się komfortowo, zescope'uj konkretny projekt, backup property to najbezpieczniejszy pierwszy realny workload.
Gotowy sprawdzić, czy Reactor API pasuje do Twojego stacku tag management? Napisz do mnie po zescope'owaną ocenę. Przejrzę Twój obecny setup AEP Tags, zidentyfikuję use case'y automatyzacji, które faktycznie się zwracają, i podam realny estymat inżynieryjny. Bez slajdów sprzedażowych, bez upsellu. Po prostu szczera odpowiedź, co warto zbudować.
Potrzebujesz szczerej oceny Reactor API?
Przegladam setupy AEP Tags i scopuje prace na Reactor API, ktore faktycznie sie zwraca. Bez slajdow, bez upsellu.
Zobacz moje uslugiPotrzebujesz pomocy? Napisz do mnie
Masz pytanie dotyczące analityki? Wypełnij formularz, zwykle odpowiadam w ciągu 24 godzin.
