HubSpot API 2026-09: dlaczego integracja CRM odrzuca zapis i co sprawdzić przed migracją

HubSpot API - dlaczego integracja CRM odrzuca zapis i co sprawdzić przed migracją

Od 8 września 2026 r. wersja HubSpot CRM API /2026-09/ egzekwuje wybrane reguły walidacji skonfigurowane przez administratora konta również podczas zapisu danych przez API. Wcześniej część tych wymagań obowiązywała w interfejsie HubSpot, ale nie była w ten sam sposób sprawdzana na odpowiednich ścieżkach API.

Dla integracji CRM z ERP, systemem sprzedaży lub własną aplikacją oznacza to, że żądanie wcześniej akceptowane może zostać odrzucone po przejściu na nową wersję. Nie oznacza to jednak problemu ze wszystkimi integracjami HubSpot. Wynik zależy od używanego endpointu, operacji, konfiguracji konta i sposobu uwierzytelnienia.

Podstawą diagnozy powinno być ustalenie wersji i kontraktu API, odczytanie przyczyny błędu, sprawdzenie reguł portalu oraz poprawienie danych lub uprawnień. Dopiero po usunięciu przyczyny należy rozważyć ponowienie żądania.

Co zmieniło się w HubSpot CRM API /2026-09/?

HubSpot ogłosił zmianę 11 sierpnia 2026 r., wskazując jako datę jej wprowadzenia 8 września 2026 r., wraz z wydaniem API /2026-09/.

Zmiana dotyczy trzech mechanizmów:

1. Właściwości wymaganych warunkowo, czyli pól, których obowiązkowość zależy od wartości innych właściwości.

2. Wymaganych właściwości i asocjacji podczas tworzenia rekordu, określonych w konfiguracji Create Record.

3. Uprawnienia Edit Associations, istotnego przy modyfikowaniu powiązań przez aplikacje korzystające z user-level OAuth.

Są to odrębne mechanizmy, dlatego wymagają odrębnej diagnostyki.

HubSpot podkreśla, że opisane zachowania występują wtedy, gdy odpowiednie reguły lub ograniczenia zostały skonfigurowane na danym koncie. Jeżeli takich ustawień nie ma, producent nie przewiduje zmiany zachowania wynikającej z tych trzech mechanizmów.

Nie oznacza to, że wersja /2026-09/ pozbawiona jest innych zmian. Analizowany komunikat dotyczy konkretnie egzekwowania wymagań administracyjnych przy zapisie.

Źródło: HubSpot Developer Changelog, CRM API Write Validation Enforcement

Dlaczego wersja endpointu ma znaczenie?

HubSpot wprowadził model date-based API versioning, w którym wersja API jest identyfikowana datą wydania, np. /2026-03/ lub /2026-09/.

W referencji wersji 2026-09 producent podaje między innymi następujący przykład odczytu kontaktów:

GET /crm/objects/2026-09/contacts

Zastępuje to wcześniejszy model oznaczania wersji numerami v1, v2, v3 i v4. Poszczególne API mogą jednak różnić się strukturą ścieżek, dlatego nie należy zakładać, że migracja zawsze polega wyłącznie na podmianie fragmentu adresu URL.

Wydanie nowej wersji nie oznacza automatycznego przełączenia wszystkich dotychczasowych żądań integracji. Trzeba sprawdzić, które wersje są rzeczywiście wykorzystywane przez aplikację i czy biblioteka kliencka kieruje wywołania do właściwych endpointów.

Podczas diagnozy podstawowe pytanie brzmi więc: czy problematyczne żądanie rzeczywiście korzysta z API /2026-09/?

Źródła: HubSpot, Introducing date-based API versioning oraz referencja API 2026-09.

Trzy wymagania, które trzeba rozróżnić

1. Pole wymagane zależnie od wartości innego pola

Administrator HubSpot może skonfigurować regułę, zgodnie z którą jedna właściwość staje się wymagana, gdy inna przyjmuje określoną wartość.

Producent ilustruje ten mechanizm przykładem daty zamknięcia wymaganej po ustawieniu etapu transakcji na closedwon. Jest to przykład reguły warunkowej, a nie stwierdzenie, że każdy portal HubSpot posiada identyczną konfigurację.

Jeżeli żądanie zapisu uruchamia warunek, ale nie zawiera wymaganej wartości, objęty zmianą endpoint może zwrócić HTTP 400.

W dokumentacji przedstawiono kod:

MISSING_CONDITIONAL_REQUIRED_PROPERTY

Przykładowa struktura odpowiedzi wykorzystuje kategorię VALIDATION_ERROR oraz pola errors[].code i errors[].context.propertyName, pozwalające zidentyfikować problematyczną właściwość.

Taki błąd nie oznacza sam w sobie chwilowej niedostępności HubSpot. Wskazuje na niespełnienie konkretnego wymagania walidacyjnego.

Co sprawdzić?

Najpierw należy ustalić, która wartość uruchomiła warunek, jakie pole stało się wymagane i czy integracja rzeczywiście przesłała odpowiednią wartość.

Jeżeli brakujące dane istnieją w systemie źródłowym, rozwiązaniem może być korekta mapowania lub transformacji. Jeżeli wartości nie ma, problem wymaga uzgodnienia z właścicielem danych.

Możliwa jest również sytuacja, w której sama reguła nie odpowiada aktualnemu procesowi biznesowemu. Jej zmianę powinien jednak zatwierdzić administrator wspólnie z właścicielem procesu. Nie należy usuwać wymagań wyłącznie po to, aby wcześniej stosowany payload przeszedł walidację.

2. Wymagane właściwości i asocjacje przy tworzeniu rekordu

Drugi mechanizm dotyczy ustawień Create Record.

Administrator może oznaczyć wybrane właściwości oraz powiązania z innymi rekordami jako wymagane podczas tworzenia nowego rekordu. HubSpot dokumentuje egzekwowanie tych wymagań przy odpowiednich operacjach POST.

Jeżeli zabraknie wymaganej właściwości, API może zwrócić:

MISSING_REQUIRED_PROPERTY

Producent ilustruje ten przypadek brakującą właściwością firstname.

Osobno należy rozpatrywać wymagane asocjacje, czyli powiązania między rekordami. Przykładowo konfiguracja konkretnego konta może wymagać utworzenia rekordu wraz z określoną relacją.

Komunikat HubSpot potwierdza egzekwowanie wymaganych asocjacji podczas tworzenia rekordów, ale nie przypisuje wszystkim takim przypadkom jednego uniwersalnego kodu błędu.

Dlatego przy odrzuceniu zapisu trzeba przeanalizować pełną odpowiedź endpointu i sprawdzić rzeczywistą konfigurację Create Record.

Ważne jest również rozróżnienie tworzenia rekordu od jego późniejszej edycji.

Nie należy automatycznie zakładać, że wymagania Create Record mają identyczne zastosowanie do wszystkich operacji PATCH, batch lub upsert. Zakres walidacji i sposób przekazania relacji trzeba sprawdzić dla używanego endpointu.

Wymagania dotyczące tworzenia rekordów mogą zależeć także od planu subskrypcji i uprawnień administratora. HubSpot opisuje te zależności w dokumentacji konfiguracji Create Record.

Źródło: HubSpot Knowledge Base, Customize the create form for each object

3. Uprawnienie Edit Associations przy user-level OAuth

Trzeci mechanizm nie dotyczy brakującej wartości właściwości, lecz prawa do modyfikowania relacji między rekordami.

HubSpot wskazuje, że aplikacja korzystająca z user-level OAuth może otrzymać błąd podczas tworzenia, aktualizowania lub usuwania asocjacji, jeżeli użytkownik instalujący aplikację nie posiada wymaganego uprawnienia Edit Associations.

W komunikacie producenta występuje również identyfikator:

CRM_ASSOCIATIONS_WRITE_ACCESS

HubSpot zaznacza, że opisane ograniczenie nie dotyczy w ten sam sposób portal-level app tokens.

Jeżeli problem występuje przy zapisie powiązania, poprawianie wartości właściwości rekordu może nie przynieść żadnego rezultatu.

W takiej sytuacji należy sprawdzić model uwierzytelnienia, użytkownika instalującego aplikację, przypisane uprawnienia oraz operację wykonywaną przez integrację.

Nie należy też automatycznie przypisywać każdemu takiemu odrzuceniu statusu HTTP 403. Komunikat producenta przedstawia przykład błędu uprawnienia, ale nie ustanawia uniwersalnego statusu HTTP dla wszystkich objętych nim operacji.

Źródło: HubSpot Developer Changelog, CRM API Write Validation Enforcement

Błąd 400 w HubSpot: jak ustalić przyczynę odrzucenia?

Status 400 Bad Request nie wystarcza do poprawnego zdiagnozowania problemu.

W omawianej zmianie HubSpot przedstawia przykłady odpowiedzi z kategorią VALIDATION_ERROR, kodami poszczególnych naruszeń oraz kontekstem wskazującym problematyczną właściwość.

Nie należy jednak zakładać, że wszystkie endpointy i wszystkie kategorie błędów zwracają identyczny zestaw pól.

W diagnostyce trzeba uwzględnić metodę HTTP, adres endpointu, wersję API, typ obiektu, pełną odpowiedź błędu oraz ustawienia konkretnego portalu.

Jakie informacje zachować w logach?

Aby umożliwić późniejszą diagnozę, warto rejestrować:

• Wersję API, metodę HTTP i endpoint.

• Typ obiektu oraz bezpieczny identyfikator operacji.

• Status HTTP i kategorię błędu.

• Kod błędu oraz potrzebny do diagnozy kontekst.

• Identyfikator korelacyjny, jeżeli został zwrócony.

• Stan operacji po odrzuceniu i ewentualnej korekcie.

Jest to zalecany model logowania operacyjnego, a nie obowiązkowy schemat wymagany przez HubSpot.

Logowanie nie powinno prowadzić do niepotrzebnego przechowywania tokenów dostępowych, danych osobowych ani pełnych wartości poufnych właściwości. Zakres rejestrowanych danych należy dostosować do potrzeb diagnostycznych i zasad bezpieczeństwa organizacji.

Jak sprawdzić konfigurację HubSpot przed migracją?

Przygotowanie integracji nie powinno ograniczać się do odczytu listy właściwości.

HubSpot dokumentuje zarówno definicje właściwości CRM, jak i odrębny mechanizm odczytu reguł walidacji właściwości. Osobno funkcjonują ustawienia Create Record, wymagane asocjacje oraz uprawnienia użytkowników.

Dla wersji 2026-09 udokumentowano między innymi endpoint:

GET /crm/property-validations/2026-09/{objectTypeId}

Służy on do odczytu reguł walidacji właściwości danego typu obiektu.

Nie należy jednak zakładać, że odpowiedź tego endpointu stanowi kompletny wykaz wszystkich wymagań administratora, w szczególności wymaganych asocjacji Create Record, całej logiki warunkowej i ograniczeń uprawnień.

Odczyt metadanych jest elementem kontroli, ale nie zastępuje sprawdzenia konfiguracji portalu i testów rzeczywistych operacji.

Źródło: HubSpot API Reference, Read all property validation rules for an object

Lista kontrolna przed zmianą wersji

1. Zidentyfikuj rzeczywiste wywołania API.

Przygotuj wykaz endpointów, metod POST i PATCH, operacji asocjacji oraz używanych wersji API. Uwzględnij wywołania wykonywane przez biblioteki klienckie.

Nie zakładaj, że wszystkie moduły integracji korzystają z jednej wersji.

2. Sprawdź właściwy portal.

Porównaj konfigurację środowiska testowego i produkcyjnego. Zwróć uwagę na różnice w regułach administratora, dostępnych funkcjach i uprawnieniach.

Sukces żądania w jednym portalu nie gwarantuje takiego samego wyniku w innym.

3. Przejrzyj wymagania administratora.

Sprawdź warunkowo wymagane właściwości, wymagania Create Record, wymagane asocjacje oraz uprawnienia użytkownika instalującego aplikację korzystającą z user-level OAuth.

4. Porównaj reguły z mapowaniem danych.

Dla każdej wymaganej wartości ustal jej źródło, moment dostępności i sposób transformacji.

Oddziel brak danych w systemie źródłowym od sytuacji, w której integracja posiada dane, ale nie przekazuje ich w żądaniu.

5. Zweryfikuj bibliotekę kliencką.

Sprawdź nazwę, wersję i dokumentację rzeczywiście używanego SDK.

HubSpot ogłosił 10 czerwca 2026 r. aktualizację bibliotek obsługujących wersjonowanie datowe, obejmującą PHP, Javę, Ruby, Go, TypeScript i Pythona.

Nie należy bez dodatkowego sprawdzenia przenosić zachowania starszego klienta API na nowy pakiet. Dotyczy to między innymi obsługi błędów i automatycznych ponowień.

Źródło: HubSpot, Updated SDKs for Date-based Versioning

6. Zaplanuj obsługę odrzucenia.

Ustal, co dzieje się z rekordem, którego nie udało się zapisać. Integracja powinna umożliwiać rozpoznanie przyczyny, przekazanie problemu do właściwej osoby oraz bezpieczne wznowienie po korekcie.

7. Przygotuj kontrolowane wdrożenie.

Zaplanuj testy przed zmianą, obserwację wyników po przełączeniu i sposób ograniczenia skutków ewentualnego błędu.

Powrót do wcześniejszej wspieranej wersji API może być rozwiązaniem przejściowym, jeżeli pozwala na to kontrakt danego endpointu i plan wdrożenia. Nie powinien jednak zastępować docelowej migracji.

Koniec wsparcia starszych API: jakie terminy uwzględnić?

Zmiana walidacji /2026-09/ jest częścią szerszego przejścia HubSpot na wersjonowanie datowe.

Producent ogłosił również harmonogram wycofywania wsparcia dla starszych wersji API:

HubSpot zaleca migrację bezpośrednio do wersjonowania datowego, bez traktowania v3 lub v4 jako obowiązkowego etapu pośredniego.

Koniec wsparcia nie musi oznaczać natychmiastowego technicznego wyłączenia każdego endpointu. Oznacza natomiast brak gwarancji dalszego utrzymania, poprawek i stabilności nieobsługiwanych wersji.

Istotne jest również rozróżnienie migracji API od migracji architektury aplikacji. HubSpot osobno ogłosił zakończenie wsparcia dla starszych modeli aplikacji publicznych i prywatnych. Przejście na nowszy endpoint nie jest zatem automatycznie równoznaczne z zakończeniem wszystkich prac migracyjnych.

Dla organizacji utrzymującej integrację oznacza to potrzebę sprawdzenia dwóch rzeczy: wersji używanych endpointów oraz architektury aplikacji, która te wywołania wykonuje.

Źródła: HubSpot, Legacy APIs and Apps: What's Going Unsupported and When oraz Deprecating Support for HubSpot v4 APIs.

Poprawić payload, zmienić uprawnienie czy ponowić żądanie?

Wybór działania powinien zależeć od rozpoznanej przyczyny błędu, a nie wyłącznie od statusu HTTP.

Jeżeli żądanie narusza regułę wymaganej właściwości, należy sprawdzić brakujące dane i sposób ich przekazywania. Jeżeli problem dotyczy uprawnień do asocjacji, właściwym obszarem kontroli jest model uwierzytelnienia i konfiguracja dostępów.

W przypadku wymagań Create Record konieczne może być również dostosowanie kolejności operacji lub sposobu tworzenia relacji między rekordami. Nie można jednak zakładać, że każdy endpoint umożliwia przekazanie asocjacji w identyczny sposób.

Dlaczego automatyczny retry nie rozwiązuje każdego błędu?

HubSpot zaleca poprawienie danych lub konfiguracji przed ponowieniem żądania odrzuconego z powodu omawianych reguł walidacji.

Ponawianie identycznego żądania, które nadal nie spełnia wymagania, nie usuwa jego przyczyny.

Inaczej należy traktować wybrane błędy przejściowe i ograniczenia liczby żądań. Mogą one kwalifikować się do ponowienia, ale konkretna polityka retry musi odpowiadać dokumentacji używanego endpointu i klienta API.

Przykładowo dokumentacja starszej biblioteki Node.js @hubspot/api-client opisuje opcję numberOfApiCallRetries dla błędów 5xx oraz określonego przypadku 429 z limitem TEN_SECONDLY_ROLLING.

Dokumentacja ta identyfikuje jednak klienta jako SDK API v3. Nie stanowi zatem samodzielnego potwierdzenia, że taki sam parametr i identyczna polityka obowiązują w każdej nowej bibliotece obsługującej /2026-09/.

Źródło: dokumentacja @hubspot/api-client

Dodatkowej ostrożności wymagają operacje tworzące rekordy.

Jeżeli poprzednie żądanie mogło zostać wykonane, ale aplikacja nie otrzymała jednoznacznego potwierdzenia, automatyczne powtórzenie operacji może doprowadzić do duplikacji.

Przed retry trzeba zatem ustalić, czy operacja została wykonana, czy istnieje możliwość identyfikacji utworzonego rekordu i w jaki sposób integracja kontroluje wielokrotne wykonanie tego samego procesu biznesowego.

Samo użycie SDK z funkcją ponowień nie gwarantuje idempotencji całego procesu.

warnings po udanym zapisie: normalizacja wartości datetime

W komunikacie dotyczącym /2026-09/ HubSpot opisał także zmianę obsługi określonych danych typu datetime.

Producent wskazuje, że API może przyjąć niektóre wartości, które wcześniej powodowały błędy walidacji, dokonać ich normalizacji i zwrócić udaną odpowiedź z informacją o tej operacji w tablicy warnings.

Ostrzeżenie nie jest więc automatycznie równoznaczne z odrzuceniem rekordu.

W integracjach, w których daty wpływają na raportowanie, harmonogramy lub procesy biznesowe, warto odróżniać techniczny sukces zapisu od zgodności zapisanej wartości z oczekiwaniem systemu źródłowego.

Kontrola powinna obejmować wartość przesłaną, treść ewentualnego ostrzeżenia i wartość faktycznie zapisaną.

Nie należy jednak zakładać, że każda wartość datetime zostanie znormalizowana ani że wszystkie udane odpowiedzi muszą zawierać warnings.

Źródło: HubSpot Developer Changelog, sekcja Datetime validation improvements

Jak przetestować integrację przed przełączeniem na /2026-09/?

Test wykonany wyłącznie na prawidłowym rekordzie nie sprawdzi mechanizmów odpowiedzialnych za opisane zmiany walidacji.

Plan powinien uwzględniać rzeczywiste ustawienia portalu, model uwierzytelnienia i typy operacji wykorzystywane przez integrację.

Poniższe scenariusze stanowią propozycję testów akceptacyjnych. Nie są wynikami testów przeprowadzonych przez CAJVO.

T1. Zapis bez dodatkowej reguły

Wykonaj odpowiednią operację w środowisku, w którym badana reguła nie jest aktywna.

Sprawdź, czy zapis jest zgodny z udokumentowanym kontraktem endpointu. Powodzenie tej próby nie oznacza, że pozostałe portale mają identyczną konfigurację.

T2. Brak właściwości wymaganej warunkowo

Skonfiguruj odpowiednią regułę w środowisku testowym, a następnie wykonaj żądanie, które uruchamia warunek, ale nie zawiera zależnej wartości.

Sprawdź rzeczywisty status HTTP, kategorię i kod błędu oraz sposób przekazania odrzucenia do obsługi.

T3. Zapis po uzupełnieniu wymaganej właściwości

Powtórz scenariusz T2 po skorygowaniu wartości.

Sprawdź, czy wcześniejsze naruszenie zostało usunięte. Nie zakładaj automatycznie powodzenia całej operacji, ponieważ mogą obowiązywać również inne reguły.

T4. Wymagania Create Record

Osobno przetestuj tworzenie rekordu bez wymaganej właściwości oraz bez wymaganej asocjacji.

Dla obu wariantów zarejestruj odpowiedź rzeczywiście używanego endpointu.

Jeżeli integracja obsługuje późniejszą aktualizację tych samych rekordów, porównaj wynik z odpowiednią operacją edycji. Nie przenoś automatycznie zaobserwowanego zachowania POST na PATCH.

T5. Uprawnienia user-level OAuth

Sprawdź operację modyfikacji asocjacji przy odpowiednio skonfigurowanych uprawnieniach oraz w kontrolowanym wariancie bez wymaganego dostępu.

Potwierdź, który użytkownik i model autoryzacji są faktycznie wykorzystywane.

T6. Normalizacja datetime

Wykonaj próbę z wartością datetime odpowiadającą udokumentowanemu przypadkowi normalizacji.

Zarejestruj wynik operacji, ewentualne warnings i wartość zapisaną.

Nie uznawaj samego sukcesu HTTP za wystarczający dowód poprawności transformacji danych.

T7. Operacje batch i upsert

Jeżeli integracja korzysta z operacji zbiorczych lub upsert, przetestuj obsługę wejść poprawnych i niepoprawnych.

Zbadaj rzeczywisty format odpowiedzi, sposób identyfikacji poszczególnych wyników i możliwość bezpiecznego ponawiania operacji.

Nie zakładaj jednego uniwersalnego mechanizmu raportowania błędów dla wszystkich endpointów zbiorczych.

T8. Błąd walidacyjny a błąd przejściowy

Zweryfikuj, czy żądanie odrzucone z powodu brakujących danych nie jest bez końca ponawiane bez korekty.

Osobno sprawdź obsługę błędów kwalifikujących się do retry, zgodnie z dokumentacją używanej biblioteki i endpointu.

Kiedy uznać testy za zakończone?

Dla każdego scenariusza należy określić używany endpoint, warunki początkowe, dane wejściowe, oczekiwany wynik, rezultat rzeczywisty oraz decyzję o akceptacji.

Testy powinny również potwierdzić, że integracja potrafi zachować informację o odrzuconej operacji, wskazać osobę odpowiedzialną za korektę i bezpiecznie wznowić przetwarzanie.

Dopiero weryfikacja tych warunków w rzeczywistym środowisku pozwala ocenić gotowość konkretnego przepływu do przełączenia na nową wersję.

Kiedy wystarczy zmiana ustawień HubSpot, a kiedy trzeba przebudować integrację?

Odrzucenie zapisu nie zawsze oznacza konieczność zmiany kodu.

Jeżeli reguła administratora została ustawiona nieprawidłowo lub nie odpowiada uzgodnionemu procesowi, rozwiązaniem może być korekta konfiguracji konta.

Jeżeli reguła jest uzasadniona, a integracja nie dostarcza wymaganych danych, konieczne może być rozszerzenie mapowania, zmiana transformacji lub dostosowanie kolejności operacji.

Osobną kategorią są problemy z obsługą błędów. Integracja, która nie rozróżnia odrzucenia walidacyjnego od problemu przejściowego, nie przechowuje informacji o stanie operacji i wielokrotnie ponawia te same błędne żądania, wymaga przeglądu mechanizmu przetwarzania.

Zakres prac powinien wynikać z diagnozy konkretnego procesu, a nie wyłącznie z informacji o wydaniu nowej wersji API.

W CAJVO kwestie te mieszczą się w obszarze integracji systemów i automatyzacji procesów, obejmującym projektowanie wymiany danych i obsługi procesów pomiędzy systemami.

Podsumowanie: co sprawdzić przed migracją HubSpot API?

Wersja HubSpot CRM API /2026-09/ wprowadziła egzekwowanie wybranych wymagań administracyjnych, które wcześniej nie były w ten sam sposób stosowane na odpowiednich ścieżkach zapisu API.

Zmiana nie oznacza, że wszystkie integracje muszą zacząć zwracać błędy. Jej znaczenie zależy od konfiguracji portalu, używanej wersji API, konkretnej operacji oraz modelu uwierzytelnienia.

Przed migracją należy przede wszystkim ustalić rzeczywiste endpointy, sprawdzić wymagane właściwości i asocjacje, zweryfikować uprawnienia oraz przetestować obsługę błędów i ponowień.

Równolegle trzeba uwzględnić harmonogram końca wsparcia starszych wersji API, aby rozwiązanie przejściowe nie stało się niekontrolowaną zależnością od niewspieranej infrastruktury.

Kryterium poprawnie przygotowanej integracji jest nie tylko skuteczny zapis prawidłowych danych. Równie ważne jest rozpoznawanie odrzuceń, zachowywanie stanu operacji i możliwość bezpiecznego wznowienia przetwarzania po usunięciu problemu.

Dokumentacja HubSpot pozwala określić oczekiwane zachowanie API. Gotowość konkretnej integracji musi zostać potwierdzona testami w środowisku organizacji.

Stan źródeł: 8 października 2026 r. Artykuł opisuje zachowania udokumentowane przez HubSpot oraz proponowaną procedurę diagnostyczną i testową. Nie przedstawia wyników testów przeprowadzonych na produkcyjnym ani testowym koncie CAJVO. Przed wdrożeniem należy sprawdzić właściwe endpointy, dostępne funkcje, uprawnienia i odpowiedzi API w konkretnym środowisku.