Aplikacja webowa
Radar przetargów DV
Trzy urzędowe API w jeden strumień leadów
Jak Digital Vantage złożyło trzy niekompatybilne API urzędowe w jeden strumień leadów — 1 253 linie, dwie zależności, dwa dni
Wewnętrzne narzędzie DV: headless bot, który codziennie przeczesuje trzy urzędowe źródła przetargów, odsiewa szum i dostarcza tylko realne dopasowania na Discorda i mailem. Case sprzedaje kompetencję integracyjną — wejście w byle jakie API urzędowe i wyciągnięcie z niego użytecznego strumienia danych. Reference build, przed wdrożeniem.
71 → 6
Ogłoszenia pobrane → realne dopasowania (72 h)
- Klient
- Radar przetargów DV
- Branża
- Automatyzacja / narzędzia wewnętrzne
- Rok
- 2026
- Zakres
- Systemy i integracje · Aplikacje webowe
- Stack techniczny
- Node.js 24 · TypeScript · MongoDB
- Czas realizacji
- 31 commitów w 2 dni
- Lokalizacja
- Polska
01Kontekst
Wyzwanie
Dev-owe przetargi publiczne w Polsce istnieją, ale są rozsypane po trzech systemach, których nikt nie zaprojektował do czytania maszynowo: krajowe postępowania, próg unijny i zapytania ofertowe z projektów UE. Żeby wiedzieć, co się dzieje na rynku, trzeba było zaglądać w trzy miejsca, mieląc oczami ogłoszenia o dostawie tonerów.
Ręczny przegląd odpada nie dlatego, że jest nudny, lecz dlatego, że gęstość sygnału jest za niska: w oknie 72 godzin trzy źródła dały 71 ogłoszeń, z czego tylko 6 to realne dopasowania. Sześć trafień na trzy dni to za mało, by codziennie otwierać trzy portale — i zdecydowanie za dużo, by móc je przegapić. Do tego trzy API bez kontraktu i bez SLA, które mogą zmienić kształt odpowiedzi w dowolny czwartek.
02Rozwiązanie
Podejście
Każde z trzech API jest zepsute inaczej i każde wymagało innej odpowiedzi. Pierwsze filtruje po stronie serwera, więc precyzja jest 1:1 i oszczędza transfer. Drugie dopasowuje kody zbyt szeroko (czternastokrotnie więcej szumu niż sygnału), więc dołożyliśmy lokalny filtr. Trzecie nie ma nawet publicznej listy — da się tylko zapytać „czy istnieje ogłoszenie numer N”, więc chodzimy po rosnących identyfikatorach z trwałym kursorem.
Wszystko schodzi się w jeden typ danych, a diabeł siedzi w normalizacji formatów kodów i dat. Kadencję kanałów rozdzieliliśmy bez drugiego mechanizmu: Discord dostaje powiadomienie natychmiast, mail to zbiorczy digest o ustalonych godzinach. Całość to 1253 linie TypeScriptu i dwie zależności produkcyjne — bo przy trzech API, które mogą się zmienić bez ostrzeżenia, najtańszy w utrzymaniu jest kod, którego nie ma.
03Dowód
Rezultaty
71 → 6
Ogłoszenia pobrane → realne dopasowania (72 h)
70 → 5
Szum TED odsiany lokalnym filtrem
1 → 1
Precyzja BZP (filtr po stronie serwera)
2 dni
Od pustego katalogu do działającego pipeline’u
1 253 / 2
Linie TypeScriptu / zależności produkcyjne
3
Urzędowe API w jednym strumieniu
Trzy niekompatybilne źródła zeszły się w jeden strumień w dwa dni — od pustego katalogu do przebiegu end-to-end z powiadomieniami na dwóch kanałach. Radar mierzy dziś realny sygnał: 71 pobranych ogłoszeń → 6 dopasowań w oknie 72 godzin, z pełną precyzją na jednym źródle i odsianiem czternastokrotnego szumu z drugiego.
To wynik inżynierski, nie biznesowy — i tak go czytamy. Radar nie stoi jeszcze na produkcji, więc nie ma uptime’u ani liczby leadów na miesiąc; nie twierdzimy, że coś przyspieszył, bo jeszcze niczego nie przyspieszył. Wartość jest w kompetencji: samo pisanie tego case wykryło realnego buga w cudzym API (endpoint ignoruje numer strony) — najuczciwszy dowód tezy, że przy API bez kontraktu problemem nie jest napisanie klienta, tylko wykrycie, że serwer nie robi tego, co zadeklarował.
Trzy urzędowe API bez kontraktu złożone w jeden strumień dopasowań (71 → 6 w 72 h) w 1253 liniach i dwóch zależnościach.
Branża
- Automatyzacja / narzędzia wewnętrzne
Obszary Kompetencji
- Systemy i integracje
- Aplikacje webowe
Stack techniczny
- Node.js 24
- TypeScript
- MongoDB
- nodemailer
- Docker
- Discord webhook
TWÓJ PROCES
Tracisz czas na ręczne przeszukiwanie przetargów?
Zautomatyzuję powtarzalną pracę — od monitoringu danych po powiadomienia, jak w Radarze Przetargów.