Web application
Radar przetargów DV
Three government APIs into one stream of leads
How Digital Vantage folded three incompatible government APIs into a single lead stream — 1,253 lines, two dependencies, two days
An internal Digital Vantage tool: a headless bot that sweeps three government tender sources every day, filters out the noise and delivers only genuine matches to Discord and email. The case sells integration competence — going into a badly built public API and pulling a usable data stream out of it. A reference build, not yet in production use.
71 → 6
Notices fetched → genuine matches (72 h)
- Client
- Radar przetargów DV
- Year
- 2026
- Tech stack
- Node.js 24 · TypeScript · MongoDB
- Timeline
- 31 commits over 2 days
- Location
- Poland
01Context
Challenge
Public tenders for development work exist in Poland, but they are scattered across three systems nobody designed to be read by a machine: national procurement, the EU threshold register, and calls for proposals from EU-funded projects. Knowing what the market is doing meant opening three places and reading past notices about toner deliveries.
Manual review fails not because it is dull, but because the signal density is too low: over a 72-hour window the three sources produced 71 notices, of which only 6 were genuine matches. Six hits in three days is too few to justify opening three portals daily — and far too many to afford missing. On top of that sit three APIs with no contract and no service guarantee, free to change the shape of their responses on any given Thursday.
02Solution
Approach
Each of the three APIs is broken differently and each needed a different answer. The first filters server-side, so precision is 1:1 and bandwidth is saved. The second matches classification codes far too broadly (fourteen times more noise than signal), so we added a local filter. The third has no public listing at all — you can only ask "does notice number N exist", so we walk ascending identifiers behind a durable cursor.
Everything converges on one data type, and the devil sits in normalising code and date formats. Channel cadence is split without a second mechanism: Discord gets a notification immediately, email is a digest at set hours. The whole thing is 1,253 lines of TypeScript and two production dependencies — because with three APIs that can change without warning, the cheapest code to maintain is the code that is not there.
03Proof
Results
71 → 6
Notices fetched → genuine matches (72 h)
70 → 5
EU-register noise removed by a local filter
1 → 1
National register precision (server-side filter)
2 days
From an empty directory to a working pipeline
1,253 / 2
Lines of TypeScript / production dependencies
3
Government APIs in a single stream
Three incompatible sources became one stream in two days — from an empty directory to an end-to-end run with notifications on two channels. The radar now measures real signal: 71 notices fetched → 6 matches in a 72-hour window, with full precision on one source and a fourteen-to-one noise ratio filtered out of another.
This is an engineering result, not a business one, and we read it that way. The radar is not in production yet, so there is no uptime figure and no leads-per-month; we do not claim it sped anything up, because it has not sped anything up yet. The value is in the competence: writing this case study uncovered a genuine bug in someone else's API (an endpoint that ignores the page number) — the most honest possible proof of the point, that with a contract-free API the hard part is not writing the client but noticing that the server does not do what it declared.
Three contract-free government APIs folded into one stream of matches (71 → 6 in 72 h) in 1,253 lines and two dependencies.
Tech stack
- Node.js 24
- TypeScript
- MongoDB
- nodemailer
- Docker
- Discord webhook
YOUR PROCESS
Losing time to searching the same sources by hand?
I will automate the repetitive part — from monitoring data to the notifications, as in this radar.