Change log
Co się zmieniło, co jest w budowie, co planuje.
Pierwsza ekspansja poza Polskę. Architektura multi-rejestr była zaprojektowana od pierwszego dnia właśnie z myślą o tym kroku — nowy kraj to nowe źródło danych, ten sam spójny format wyjściowy.
Konfiguracja alertów oparta na severity (info → critical), z filtrowaniem po event_class (initialization, change, growth, risk, anomaly, recovery) i kategorii (status, identity, location, activities…). Ustawienia globalne lub per firma z możliwością wymuszenia przez force. Uwaga: zbyt wąski filtr event_class lub category przy niskim progu severity może skutecznie wyciszy wszystkie powiadomienia.
Każdy z 29 typów eventów otrzymał przypisaną wartość severity, klasę (event_class) i kategorię. Sześć poziomów ważności: info, notice, warning, high, error, critical. Sześć klas semantycznych: initialization, change, growth, risk, anomaly, recovery. Osiem kategorii danych: status, identity, location, ownership, activities, contacts, web_presence, finance.
Spłata zaległości: pole severity dodane do struktury domenowej, zaktualizowane odpowiedzi wszystkich endpointów zwracających eventy (Companies Events, Watchlist Events Feed) oraz przeparsowanie pipeline z przypisaniem severity do historycznych rekordów.
System gotowy. API dostępne publicznie, dokumentacja, pricing, rejestracja.
Błąd w logice fallback pola event_date — zamiast daty wykrycia zdarzenia, 100% eventów zwracało activity_start. Naprawione, pipeline przeparsowany ponownie.
Pełny reset i test produkcyjny — 48 godzin parsowania, 2.1M podmiotów, 67M rekordów, 28 GiB danych.
Wszystkie endpointy przetestowane: Company Search, Company Monitor, Events, Wallet. Znalezienie buga.
Authentication, Tokens, Wallet, Companies, Watchlist, Events — każdy endpoint z parametrami, przykładami curl i prawdziwymi response'ami. Cztery przewodniki integracyjne w PL i EN. Przewodniki →
Company Search i Company Monitor — pierwsze dwa produkty platformy na produkcji. Search z filtrowaniem po branży, lokalizacji, kontakcie. Monitor z asynchronicznym kolejkowaniem do 100 podmiotów per request i 29 typami wykrywanych zdarzeń. Szczegóły w API Reference →
Integracja Paddle, system kredytowy, middleware autoryzacji. Master Token i tokeny API z granularnym zakresem dostępu.
Pipeline przeniesiony do schedulera. Codziennie w nocy — pobieranie, parsowanie, wykrywanie zmian, generowanie eventów. System zaczął działać bez udziału człowieka.
System wykrywania zmian generujący eventy. 29 typów zdarzeń: zmiany nazwy, adresu, działalności, statusu, upadłości i inne. Każdy event ma typ, starą wartość, nową wartość i datę wykrycia.
Silos po silosie, typ raportu po typie — czyste przepięcie do domeny. Testy i stabilizacja, codzienne uruchomienia manualne z terminala.
3-etapowy pipeline: fetch raportów historycznych → download XML, parse do JSON, tworzenie batchy → parse batchy do domeny. Kod był spaghetti — logika w złych miejscach. Przepisanie konieczne. V2 w styczniu.
Warstwa domenowa gotowa — DTO, Writer, Cleaner, Factory, Resolver. Pełne słowniki, testy jednostkowe i integracyjne.
Laravel 12, PHP 8.3, MySQL. Architektura domain-first od pierwszego dnia — DTO, Writer, Cleaner, Factory, Resolver, Event. Decyzja o multi-rejestr design od razu, żeby France i kolejne kraje były rozszerzeniem, nie refactorem. API-first, bez frontu.
Pierwszy kontakt z danymi rejestrowymi w 2017 — zainteresowanie tym co kryje się za publicznie dostępnymi rejestrami firm. Przez osiem lat zbieranie danych z GUS i CEIDG jako projekt poboczny. W 2025 decyzja: zbudować z tego produkt. Rok później — działające API z trzema narzędziami na produkcji.