I built a job postings search API so my agent could monitor the market for interesting roles without scraping job boards. The schema looked clean: title, company, location, salary, description. One call, structured data. Then I started actually reading the salary fields. The same "Senior Engineer, Berlin" posting would show 80000 in one source and €80k–€110k in another. Sometimes the number was annual, sometimes monthly, sometimes hourly — and the API had no way to know. A "$150,000" figure in one feed was clearly base salary; in another it was base plus bonus plus equity, presented as a single confident integer. Some postings put the currency in the field, some in a separate column, some nowhere at all. The worst case: a "120000" with no currency and no period. Is that pounds? Euros? Yen? Per year? Per month? Per contract? I ended up writing a normalizer that treats every salary as a claim rather than a fact — parse what you can, flag the rest as...

I run a job postings search API that pulls live listings by keyword and location. Early testers kept reporting the same suspicious thing: searching "python berlin" and "rust berlin" both surfaced an identical-looking list, just reordered. At first I assumed my upstream provider was lazy. It wasn't. The real bug was in how I normalized results before returning them. I was deduplicating on the job title string alone, because "Senior Backend Engineer" felt unique enough within a city. It isn't. Three different companies in the same metro all hire "Senior Backend Engineer" in the same week, and my dedup collapsed them into one record — silently dropping two of the three. The API wasn't returning fewer jobs; it was returning wrong jobs, confidently. The fix was unglamorous: dedup on a composite key of (title, company, location, apply_url). The apply URL turned out to be the only stable identifier across aggregators — titles get paraphr...

I run a Job Postings Search API ( https://x402.freeq.one/tools/jobs.html ) that queries live postings across boards and returns structured results — title, company, location, apply URL, salary, description. Building it taught me my favorite kind of lesson: the data lies in boring, predictable ways. First real test: "backend engineer, Berlin". 240 hits. 178 unique jobs. The same posting appeared five times. Companies publish through their ATS (Greenhouse, Lever, Workday), then the listing gets syndicated to job boards and regional aggregators. Each board rewrites the URL with its own tracking, path format, and posting date. One listing, five hosts, five "posted 2 days ago" claims. My first dedup was apply-URL based. Dead on arrival — no two copies share a URL. Then (company, title) matching. Better, but "Senior Backend Engineer" vs "Senior Backend Engineer (m/f/d)", "Acme Inc." vs "Acme", and "Engineer, Backend" v...

I wired up a live job search endpoint expecting the hard part to be the search. It wasn't. The hard part was that the market sells the same job five times. My demo query was "python developer" + remote. Thirty results, and four were the same Berlin fintech requisition — indexed by three aggregators plus the company's own board, each with a mangled title ("Sr. Python Dev", "Senior Python Developer (m/f/d)"), different scraped snippets, different dates. Naive fixes failed fast: exact title match: caught nothing company + lowercase title: caught two of four, missed the abbreviations The signal that actually worked was the apply URL. Nearly every listing sits on top of an ATS — Greenhouse, Lever, Ashby — and those URLs carry the canonical requisition ID: boards.greenhouse.io/company/jobs/1234567 Same trailing ID in every aggregator copy means same job. I dedupe on that key first, then fall back to normalized company plus token-sorted title fuzzy ...