HubSpot API na czym stoi ta integracja
Warstwa techniczna spięcia z HubSpotem: uwierzytelnianie prywatną aplikacją albo OAuth 2.0, właściwości z nazwą techniczną, której po utworzeniu pola nie zmienisz, wyszukiwanie i stronicowanie kursorem, limity zapytań, webhooki wobec odpytywania, operacje wsadowe, konto testowe i obsługa błędów. Dla osoby, która chce wiedzieć, na czym to stanie, zanim zaakceptuje zakres.
- 100 rekordówtyle wchodzi w jedno wywołanie wsadowe zamiast stu osobnych zapytań; większe paczki dzielimy i pilnujemy limitu po drodze
- 429kod, który HubSpot zwraca po przekroczeniu limitu zapytań. Kolejka zwalnia, ponawia z narastającym odstępem i nie gubi zdarzenia
- 14 dniod warsztatu do pierwszej integracji działającej na Waszym koncie, sprawdzonej wcześniej na koncie testowym
Problem
Dlaczego integracja z HubSpotem psuje się miesiąc po wdrożeniu?
W dniu wdrożenia działa wszystko, bo dane są czyste, a ruch mały. Miesiąc później import wysypuje się w połowie, bo HubSpot odbił część zapytań limitem, a skrypt poleciał dalej i nie zapisał, które rekordy przeszły. Dwa miesiące później nikt nie umie odtworzyć tokenu, bo powstał w prywatnej aplikacji, którą zakładał ktoś, kto już tu nie pracuje.
Druga grupa problemów siedzi w polach. Właściwość w HubSpocie ma etykietę dla człowieka i nazwę techniczną dla integracji. Etykietę zmienisz w każdej chwili, nazwy technicznej po utworzeniu pola już nie, co opisuje dokumentacja HubSpota dla programistów. Pomyłka z tego etapu zostaje w kodzie każdego scenariusza, który po tym polu decyduje, a naprawa oznacza nowe pole, przepisanie danych i zmianę w każdym miejscu, które je czyta.
Trzecia grupa to zdarzenia. Odpytywanie co 15 minut jest proste w napisaniu i drogie w utrzymaniu: mnoży zapytania, gubi zmiany między cyklami i opóźnia reakcję. Webhook oddaje zdarzenie w sekundy, tylko wymaga sprawdzenia podpisu, natychmiastowego potwierdzenia odbioru i założenia, że to samo zdarzenie może przyjść dwa razy i nie w tej kolejności, w której nastąpiło.
- Import kończy się po części rekordów i nikt nie wie, które weszły, a które nie
- Token żyje w pliku na jednym laptopie, bez listy uprawnień i bez procedury wymiany
- Webhook przyjmuje każde żądanie, bo nikt nie sprawdza podpisu
- Pole „Branża” powstało jako zwykły tekst, więc żaden automat nie potrafi po nim decydować
- Lista w CRM pokazuje inną liczbę niż raport, bo wyszukiwanie nie zdążyło zobaczyć zmian
Dlaczego teraz
Dlaczego takiej integracji nie pisze się dziś od zera?
HubSpot ma REST API na wszystkie obiekty CRM, osobny endpoint wyszukiwania, operacje wsadowe i webhooki. Do automatyzacji wewnętrznej wystarczy prywatna aplikacja z tokenem i wybraną listą uprawnień. OAuth 2.0 zostaje tam, gdzie faktycznie jest potrzebny: w aplikacji, którą instalują u siebie inne firmy, i w marketplace HubSpota.
Druga zmiana to środowisko testowe. Konto developerskie jest darmowe i daje konta testowe, a pakiet Enterprise dodaje sandbox. Pilot chodzi więc na prawdziwych, brzydkich danych, a produkcyjny CRM nie jest poligonem. Konto testowe startuje puste, więc dane do testu trzeba tam wstawić, i to jest osobna pozycja w planie, nie efekt uboczny.
Trzecia zmiana to warstwa pośrednia. n8n, Make i Zapier mają gotowe węzły do HubSpota z uwierzytelnianiem tokenem, więc własny kod zostaje tam, gdzie jest potrzebny: przy nietypowej transformacji danych, przy systemie bez API i przy wsadach, które trzeba dzielić samemu. O tym, co z tego wynika dla procesu i kto ma prawo nadpisać którą właściwość, jest osobna strona integracja z HubSpot.
Co się zmienia
Co dostaje osoba, która to potem utrzymuje?
Uwierzytelnianie, które przetrwa odejście autora
Prywatna aplikacja z listą uprawnień nadaną osobno na odczyt i na zapis, token w sekretach, spisana procedura wymiany. Dla aplikacji instalowanej u innych firm robimy OAuth 2.0 z odświeżaniem tokenu i obsługą wygaśnięcia.
Lista uprawnień spisana pole po polu i wymiana tokenu bez przerwy w działaniu
Limit zapytań przestaje wywalać import
Ruch idzie przez kolejkę, która czyta nagłówki z pozostałym limitem i odpuszcza, zanim HubSpot odpowie kodem 429. Po odbiciu ponawia z narastającym odstępem, a nie w pętli.
Zdarzenie odłożone i powtórzone zamiast rekordu, który znika w logu bez śladu
Zdarzenie w sekundy, nie w cyklu odpytywania
Utworzenie kontaktu i zmiana właściwości przychodzą webhookiem od razu po zdarzeniu. Podpis żądania sprawdzamy przy wejściu, odbiór potwierdzamy natychmiast, a robotę robi kolejka za nim.
Obsługa idempotentna, więc powtórzone zdarzenie nie zakłada drugiego rekordu
Wsad zamiast setek pojedynczych zapytań
Zapis i odczyt masowy idą operacjami wsadowymi po 100 rekordów, z dopasowaniem po polu unikalnym, na przykład po e-mailu albo NIP. Odpowiedź czytamy rekord po rekordzie, bo część paczki może nie przejść.
Do 100 rekordów w jednym wywołaniu i osobny wynik dla każdego z nich
Właściwości zaprojektowane raz
Nazwy techniczne, typy i słowniki wartości ustalamy przed założeniem pól, na warsztacie. Pole, po którym ma decydować automat, powstaje jako słownik, a nie jako tekst do wpisania z ręki.
Nazwa techniczna ustalona przed utworzeniem pola, bo po nim się jej nie zmienia
Błąd widać, zanim zauważy go klient
Każde nieudane wywołanie ląduje w alercie z kodem odpowiedzi, nazwą właściwości i identyfikatorem korelacji z odpowiedzi HubSpota. Zdarzenia, które nie przeszły, czekają w osobnej kolejce do powtórzenia.
Identyfikator korelacji do wklejenia w zgłoszenie do wsparcia HubSpota
Dowód
Czy sami tak pracujecie na API?
Tak. Agent AI w agencji naszych założycieli od marca 2026 rozmawia z HubSpotem i z pozostałymi systemami wyłącznie przez API, ten sam, który stoi za liczbami na stronie AI dla firm. Poniżej skala tego ruchu razem z tym, czego ta liczba NIE dowodzi.
Wdrożone u nas. To nie są wdrożenia u klienta zewnętrznego, tylko w spółkach założycieli JustAutomate. Piszemy to wprost, bo dowód, którego nie da się sprawdzić, nie jest dowodem.
JustBotich agentJustIdea Agency, agencja performance marketingu, około 30 osób
- 23
- osób z firmy pracuje z agentem
- 38
- systemów wpiętych na stałe
- 112
- procesów chodzi bez człowieka
- 475
- tysięcy linii kodu agenta
Agent spięty z HubSpot, formularzami na stronie, Slackiem i hurtownią danych. Uwierzytelnianie tokenem, zapis przez API, zdarzenia z formularzy odbierane w sekundy po wysłaniu.
8 z 38 systemów, w których pracuje
Google Ads
Meta Ads- HubSpot
- ActiveCollab
- Ahrefs
GA4
Search Console
BigQuery
- Przedtem
- Rekordy powstawały z ręki, więc nie było czego logować: nikt nie wiedział, ile operacji dziennie przechodzi, ile się wywala i na czym.
- Po zmianie
- Każda operacja idzie przez API i zostawia wpis w logu, z rodzajem wywołania i wynikiem. Dopiero to pozwoliło policzyć limity, błędy i to, co realnie dzieje się bez człowieka.
64 903 wywołania narzędzi w 30 dni, z tego 29 854 bez udziału człowieka, w tym 3 432 operacje na leadach i 1 301 na zgłoszeniach z formularzy
A u Ciebie
Co, jeśli macie już własną integrację?
Cztery zdania, które słyszymy najczęściej od osób technicznych, i to, co na nie odpowiadamy.
Dane osobowe kontaktów przetwarzamy według rozporządzenia 2016/679, więc do orkiestratora idą tylko pola potrzebne do decyzji, a usuwanie rekordów robimy przez przeznaczony do tego endpoint, nie przez zwykłe skasowanie obiektu.
Mamy skrypt, który dowozi dane i działa.
To dobrze i zwykle zostaje. Sprawdzamy w nim cztery rzeczy: czy respektuje limit i ponawia po 429, czy przy webhooku sprawdza podpis, czy token siedzi w sekretach z procedurą wymiany i czy po nieudanym wsadzie wie, które rekordy przeszły. Naprawiamy tylko to, co nie przechodzi tej listy, zamiast pisać całość od nowa.
Nie damy dostępu do całego CRM.
I nie trzeba. Prywatna aplikacja dostaje uprawnienia wybrane pole po polu, osobno na odczyt i osobno na zapis, a zmiana zakresu wymaga ponownego zatwierdzenia w panelu. Zaczynamy od samego odczytu, zapis włączamy po pilocie i na wąskiej liście operacji. Scenariusz może stać na Waszej infrastrukturze, wtedy dane nie opuszczają Waszych serwerów.
Nasze IT napisze to samo.
Często tak i mówimy to wprost. Wtedy warsztat kończy się specyfikacją, którą Wasz zespół realizuje bez nas: lista obiektów i właściwości z nazwami technicznymi, zakresy uprawnień, plan obsługi limitów i błędów, scenariusze testowe. Możemy zostać tylko do przeglądu kodu i do konfiguracji monitoringu.
Mamy darmowego HubSpota, więc API nam nic nie da.
Odczyt i zapis przez API działa na każdym pakiecie i to się nie zmienia. Pakiet decyduje o tym, co da się zrobić wewnątrz HubSpota: obiekty własne są od Enterprise, workflow od Professional, sandbox też jest funkcją Enterprise. Na darmowym koncie testy robimy na koncie testowym z konta developerskiego, a logika mieszka w n8n albo Make.
- Obiekty HubSpota
- Kontakty, firmy, transakcje, zgłoszenia, pozycje oferty, produkty, aktywności, obiekty własne od Enterprise
- Interfejsy
- REST API v3, endpoint wyszukiwania, operacje wsadowe, powiązania, właściwości, webhooki
- Uwierzytelnianie
- Prywatna aplikacja z tokenem, OAuth 2.0 dla aplikacji publicznej, uprawnienia osobno na odczyt i zapis
- Warstwa automatyzacji
- n8n, Make, Zapier, własne integracje przez API w Node.js albo Pythonie
- Systemy po drugiej stronie
- Fakturownia, iFirma, Comarch Optima, Subiekt, BaseLinker, Allegro, Shopify, WooCommerce, PrestaShop
- Dane i monitoring
- BigQuery, Google Sheets, GA4, bazy SQL, alerty na Slacku i w Microsoft Teams
Rodzaje operacji na HubSpot API i o czym pamiętać
Siedem rzeczy, które w tej integracji trzeba rozstrzygnąć zawsze. Trzecia kolumna jest tu najważniejsza, bo w niej siedzą powody, dla których integracja przestaje działać po pierwszym miesiącu.
| Rodzaj operacji | Jak to realizujemy | O czym pamiętać |
|---|---|---|
| Uwierzytelnianie | prywatna aplikacja z tokenem w nagłówku żądania; OAuth 2.0, gdy aplikację instalują u siebie inne firmy | uprawnienia nadajesz osobno na odczyt i zapis, a ich zmiana wymaga ponownego zatwierdzenia; token OAuth trzeba odświeżać, token prywatnej aplikacji rotować ręcznie |
| Odczyt jednego rekordu | pobranie obiektu po identyfikatorze albo po właściwości unikalnej, z jawną listą właściwości | domyślnie wraca tylko część właściwości, więc lista pól jest częścią kontraktu danych, a nie szczegółem wywołania |
| Wyszukiwanie | endpoint wyszukiwania z grupami filtrów, jedno sortowanie, kursor do kolejnych stron | świeżo zapisany rekord bywa widoczny z opóźnieniem, a pula wyników jest ograniczona; przy większych pobraniach dzielimy zapytanie po dacie modyfikacji |
| Stronicowanie | kursor „after” z odpowiedzi, do 100 rekordów na stronę | nie ma numerów stron; przy długich pobraniach zapisujemy kursor, żeby dało się wznowić po błędzie, a nie zaczynać od początku |
| Zapis masowy | operacje wsadowe do 100 rekordów w jednym wywołaniu, dopasowanie po właściwości unikalnej | odpowiedź bywa częściowa: część paczki przechodzi, część nie, więc wynik czytamy rekord po rekordzie i ponawiamy tylko nieudane |
| Zdarzenia | webhooki na utworzenie obiektu i zmianę właściwości; odpytywanie po dacie modyfikacji tam, gdzie webhooka nie ma | podpis sprawdzamy przy każdym żądaniu, odbiór potwierdzamy od razu; kolejność nie jest gwarantowana, a to samo zdarzenie może przyjść dwa razy |
| Limity i błędy | kolejka z ponawianiem: po 429 odczekanie, po 5xx narastający odstęp, po 4xx bez ponawiania | 400 to zwykle zła nazwa techniczna albo typ właściwości, 403 to brakujące uprawnienie; identyfikator korelacji z odpowiedzi zapisujemy w alercie |
Wartości liczbowe limitów podajemy według dokumentacji HubSpota i sprawdzamy je na Waszym koncie przed wdrożeniem, bo zależą od pakietu i zmieniają się w czasie. Aktualne progi są na <a href="https://developers.hubspot.com/" rel="noopener">developers.hubspot.com</a>.
Jak to robimy
Pięć kroków od pomysłu do integracji, którą da się utrzymać
Każdy krok kończy się czymś, co możesz ocenić, zanim zdecydujesz o następnym.
Warsztat i audyt konta przez API
Czytamy właściwości, etapy transakcji, obiekty własne, workflow i pakiet, i liczymy fakty: które pola są realnie wypełniane, które powstały jako tekst zamiast słownika, ile jest duplikatów. Sprawdzamy też, jakie integracje i tokeny już istnieją, bo zwykle jest ich więcej, niż ktokolwiek pamięta.
Kontrakt danych i uprawnienia
Spisujemy obiekty, właściwości z nazwami technicznymi i typami, klucz do dopasowania rekordów przy zapisie masowym oraz listę uprawnień osobno na odczyt i na zapis. Rozstrzygamy tu też, co idzie webhookiem, a co odpytywaniem, i gdzie mieszka logika: w workflow HubSpota czy w orkiestratorze.
Pilot na koncie testowym
Integrację uruchamiamy najpierw na koncie testowym z konta developerskiego, a na Enterprise na sandboxie. Puszczamy przez nią przypadki brzydkie: rekord bez wymaganego pola, duplikat, wsad, w którym część rekordów nie przechodzi, i celowo wywołany limit, żeby zobaczyć, jak zachowa się ponawianie.
Produkcja z monitoringiem
Przełączamy na produkcję z alertami na kody błędów i z osobną kolejką na zdarzenia, które nie przeszły. Zostawiamy runbook: co robić po 429, co po 5xx, jak powtórzyć zdarzenie i skąd wziąć identyfikator korelacji do zgłoszenia w HubSpocie.
Pomiar po 30 i 90 dniach
Po 30 dniach patrzymy na liczbę zdarzeń, które nie przeszły, i na to, ile z nich wróciło po ponowieniu samo. Po 90 na to, czy ktoś w ogóle musiał dotknąć integracji ręcznie. Jeśli musiał, poprawiamy to miejsce, a nie dopisujemy instrukcji.
Przed i po
Jak zmienia się dzień osoby, która utrzymuje integrację
Przedtem
- Token integracji siedzi w pliku konfiguracyjnym na jednym laptopie
- Import zatrzymuje się w połowie i nikt nie wie, które rekordy weszły
- Zmiana etapu transakcji trafia do drugiego systemu przy najbliższym odpytaniu, po 15 minutach
- Po odpowiedzi 400 ktoś zgaduje, która właściwość ma złą nazwę albo zły typ
Po zmianie
- Token w sekretach, z listą uprawnień i spisaną procedurą wymiany
- Wsad po 100 rekordów zwraca wynik osobno dla każdego, nieudane wracają do kolejki
- Webhook oddaje zdarzenie w sekundy, z podpisem sprawdzonym przy wejściu
- Alert niesie kod odpowiedzi, nazwę właściwości i identyfikator korelacji
Pilot na koncie testowym w pierwszym tygodniu, pierwsza integracja na produkcji 14 dni od warsztatu. Liczbę zdarzeń, które nie przeszły, oceniamy po 30 dniach, a to, czy ktoś dotykał integracji ręcznie, po 90.
Dla osoby, która to zamawia
Co z tego ma osoba, która odpowiada za systemy
Ryzyko w takim projekcie nie siedzi w napisaniu integracji, tylko w tym, co zostaje po jej napisaniu. Kontrakt danych, lista uprawnień i runbook sprawiają, że integracja nie jest wiedzą jednej osoby. Gdy ta osoba odejdzie albo pójdzie na urlop, następna zaczyna od dokumentu, nie od czytania kodu i zgadywania, po czym dopasowują się rekordy.
Druga rzecz zdejmuje z Ciebie ryzyko decyzji przed wdrożeniem. Zamiast zgadywać zakres, dostajesz specyfikację po tygodniu warsztatu procesowego, z listą pól, uprawnień i przypadków brzegowych. Jeśli po tym uznasz, że robicie to sami, dokument zostaje u Was i nadal ma wartość.
- Kontrakt danych spisany: obiekty, właściwości, nazwy techniczne, typy, klucz dopasowania
- Token w sekretach i procedura wymiany, więc odejście autora nie zatrzymuje integracji
- Pilot na koncie testowym, więc produkcyjny CRM nie jest poligonem
- Runbook: co robić po 429, po 5xx i przy zdarzeniu, które nie przeszło
Ile to kosztuje
Warsztat ma cenę jawną, integracja wycenę po nim
Warsztat procesowy kosztuje 2500 zł netto za tydzień. Przy jednej integracji zwykle wystarcza jeden tydzień, bo zakres jest wąski: które operacje, na których obiektach, z jakimi uprawnieniami i co się dzieje, gdy się nie udadzą. Integrację wyceniamy po warsztacie, gdy wiadomo, ile operacji wchodzi w grę i w jakim stanie są właściwości.
Licencję HubSpota płacisz bezpośrednio HubSpotowi, tak samo koszt działania scenariuszy w Make albo n8n, albo nie płacisz go wcale, gdy scenariusz stoi na Waszej infrastrukturze. Bez naszej prowizji. Konto developerskie i konta testowe są darmowe, sandbox jest funkcją pakietu Enterprise.
Warsztat procesowy
2500 zł netto
za tydzień, przy jednej integracji zwykle jeden
Zamknięta całość. Kończy się specyfikacją techniczną, którą Wasz zespół zrealizuje bez nas.
- Audyt konta przez API: właściwości, obiekty, workflow, pakiet i istniejące tokeny
- Kontrakt danych: obiekty, nazwy techniczne, typy, klucz dopasowania rekordów
- Plan obsługi limitów, błędów i zdarzeń: webhook czy odpytywanie, co ponawiamy
- Lista uprawnień osobno na odczyt i zapis oraz scenariusze testowe
- Najczęściej wybierany
Warsztat i integracja
Wycena po warsztacie
zakres wynika z liczby operacji i stanu właściwości
Najczęściej wybierany wariant. Działająca integracja sprawdzona najpierw na koncie testowym, potem na produkcji.
- Wszystko z warsztatu
- Integracja w n8n, Make albo we własnym kodzie, z uwierzytelnianiem tokenem
- Kolejka z ponawianiem, operacje wsadowe, webhooki z weryfikacją podpisu
- Pilot na koncie testowym i przełączenie z monitoringiem błędów
- Runbook i szkolenie osoby, która ma to utrzymywać bez nas
Integracja i agent AI
Wycena po warsztacie
dla zespołów, które o dane z HubSpota pytają kilkanaście razy dziennie
Wszystko z integracji plus BOND, firmowy agent AI, który czyta z HubSpota przez to samo API.
- Wszystko z integracji
- Agent AI spięty z HubSpot: karta klienta, etapy, transakcje bez ruchu, źródła
- Uprawnienia agenta ustalone osobno na odczyt i na zapis, zapis po pilocie
- Odpowiedź z aktualnych danych w 5 do 10 sekund, każda operacja w logu
Warsztat kończy się dokumentem, który obroni się bez nas: kontraktem danych, listą uprawnień i planem obsługi błędów. Jeśli audyt konta pokaże, że wystarczy gotowy konektor w Make albo workflow, które już macie, mówimy to i sprawa kończy się na warsztacie, a nie na integracji, której nie potrzebujecie.
Najczęstsze pytania
Token prywatnej aplikacji czy OAuth 2.0?
Do automatyzacji wewnętrznej token prywatnej aplikacji: nadajesz uprawnienia raz, wpisujesz token do sekretów i integracja działa, dopóki go nie wymienisz. OAuth 2.0 bierzemy wtedy, gdy aplikację ma instalować u siebie inna firma albo gdy ma trafić do marketplace HubSpota, bo tam każde konto autoryzuje się samo. Token dostępu w OAuth żyje krótko i trzeba go odświeżać, więc integracja musi to obsłużyć od pierwszego dnia.
Ile zapytań do HubSpot API można wysłać?
Limit jest liczony w krótkim oknie czasowym i zależy od pakietu oraz od typu integracji, a wyszukiwanie ma własny, niższy próg. Konkretne wartości podaje dokumentacja HubSpota i sprawdzamy je na Waszym koncie przed wdrożeniem, bo zmieniają się w czasie. Praktyczna zasada jest niezależna od liczby: integracja czyta nagłówki z pozostałym limitem, zwalnia sama i ma kolejkę, więc nie zależy od tego, czy próg to sto czy dwieście zapytań.
Co robicie, gdy HubSpot zwróci 429?
Zdarzenie wraca do kolejki i jest ponawiane z narastającym odstępem, z drobnym losowym rozrzutem, żeby kilka procesów nie wróciło w tej samej sekundzie. Kod 429 nie jest błędem integracji, tylko normalnym stanem przy większym ruchu, więc nie alarmujemy przy pierwszym, a przy serii, która nie mija. Rekordy z wsadu, które nie przeszły, ponawiamy pojedynczo, żeby nie powtarzać całej paczki.
Czy da się zmienić nazwę techniczną właściwości po utworzeniu pola?
Nie. Etykietę widoczną dla użytkownika zmienisz w każdej chwili, nazwy technicznej, po której odwołuje się do pola każda integracja, już nie. Dlatego nazwy i typy ustalamy przed założeniem pól, a pole, po którym ma decydować automat, powstaje jako słownik wartości, nie jako tekst. Naprawa po fakcie oznacza nowe pole, przepisanie danych i zmianę w każdym miejscu, które to pole czyta.
Webhooki czy odpytywanie cykliczne?
Webhook wszędzie, gdzie HubSpot ma odpowiednie zdarzenie, bo oddaje zmianę w sekundy i nie generuje pustych zapytań. Odpytywanie po dacie modyfikacji zostaje jako uzupełnienie: dla zdarzeń, których webhook nie obejmuje, i jako siatka bezpieczeństwa na wypadek, gdy odbiorca był chwilę niedostępny. Przy webhookach zakładamy, że zdarzenie może przyjść dwa razy i nie w kolejności, więc obsługa jest idempotentna.
Jak działają operacje wsadowe i co, gdy część rekordów nie przejdzie?
Jedno wywołanie obejmuje do 100 rekordów, a dopasowanie do istniejących idzie po właściwości unikalnej, na przykład po e-mailu albo po NIP zapisanym jako pole unikalne. Odpowiedź może być częściowa, więc czytamy wynik dla każdego rekordu osobno i ponawiamy tylko te, które się nie udały. Bez tego import wygląda na udany, a w CRM brakuje części danych.
Jak testujecie integrację, żeby nie ruszać produkcji?
Najpierw konto testowe zakładane z darmowego konta developerskiego HubSpota, a na pakiecie Enterprise sandbox. Konto testowe startuje puste, więc dane do testu wstawiamy tam sami, w tym przypadki brzydkie: rekord bez wymaganego pola, duplikat i wsad, w którym część rekordów nie przechodzi. Tokeny środowisk trzymamy osobno, żeby test nigdy nie trafił na produkcyjne konto przez pomyłkę w konfiguracji.
Jak wyszukiwanie radzi sobie z dużą bazą kontaktów?
Wyszukiwanie oddaje wyniki stronami po 100 rekordów, po kursorze, i ma ograniczoną pulę wyników na jedno zapytanie, dlatego duże pobrania dzielimy na zakresy po dacie modyfikacji. Trzeba też pamiętać, że świeżo zapisany rekord bywa widoczny w wyszukiwaniu z opóźnieniem, więc scenariusz, który zapisuje i natychmiast szuka tego samego rekordu, jest błędem projektowym. Konkretne progi sprawdzamy w dokumentacji przed wdrożeniem.
Sprawdźmy, na czym stoi Wasza integracja z HubSpotem
Bezpłatna konsultacja trwa 30 minut. Mówisz, co dziś wysyła i odbiera dane z HubSpota, na czym się uwierzytelnia i co się dzieje, gdy zapytanie się nie uda. Pokazujemy, które trzy rzeczy poprawić najpierw i co da się zrobić gotowym konektorem, a co wymaga własnego kodu. Nie musisz na tym etapie dawać dostępu do konta.
Prowadzimy najwyżej dwa wdrożenia równocześnie, żeby przy każdym ktoś realnie siedział.
Umów bezpłatną konsultacjęPS. Jeśli u Was ktoś w tym miesiącu wznawiał import z ręki albo szukał, dlaczego HubSpot odpowiedział 400, to jest dokładnie ten problem. Integracja, która ma kontrakt danych, kolejkę z ponawianiem i alert z identyfikatorem korelacji, przestaje wymagać ludzkiej czujności. Zaczynamy od warsztatu, bo bez ustalonych nazw technicznych i uprawnień szybciej dowozi się tylko bałagan.