Job Postings Are the Most Underused B2B Intent Signal (And You Don't Even Need to Scrape)

A funding announcement tells you a company has money. A job posting tells you exactly where they're about to spend it - and it's published weeks before the pain becomes a purchase. If a target account just opened its first platform-engineer role, they're about to have infrastructure problems. First "Head of Demand Gen"? Marketing budget incoming. Three sales roles in a month? They found product-market fit and every vendor selling to sales teams should already be in their inbox. Job postings are, I think, the most underused intent signal in B2B - and unlike most intent data, they're public, structured, and free to read. This post covers the mechanics: where the data actually lives, why you don't need to "scrape" in any painful sense, and how to turn it into an alerting system. The secret: almost nobody hosts their own job board Most companies' careers pages are a skin over an ATS (applicant tracking system) - Greenhouse, Lever, Ashby, Workable, SmartRecruiters, Recruitee, and a few others. And the big ones expose public JSON endpoints per company, no auth required: https://boards-api.greenhouse.io/v1/boards/{company}/jobs https://api.lever.co/v0/postings/{company}?mode=json https://api.ashbyhq.com/posting-api/job-board/{company} That's not scraping; that's a GET request. When I tested this, stripe on Greenhouse returned 576 open roles and openai on Ashby returned 734, each with title, location, and apply URL, in a couple of seconds. No headless browser, no proxies, no anti-bot war - companies want this data distributed. The two actual problems are less obvious: 1. Discovery - which ATS does a given company use? You can probe: normalize the company name into slug candidates and try each ATS endpoint until one answers. It works surprisingly often. For stragglers, the careers link on their website gives it away instantly (jobs.lever.co/... in the href). 2. Newness - for intent purposes you don't care about the 576 open roles; you care about the 3 that appeared this week. That means state: store the job IDs you've seen per company, diff on each run, and emit only the delta. This is the step everyone skips and then regrets, because without it your "alerts" are the same 576 jobs every morning. The architecture - Input: a list of target companies (your dream accounts, competitors, whoever) - Resolve: detect each company's ATS and fetch its board as JSON - Normalize: six ATS formats into one schema - title, department, location, remote flag, employment type, URL, posted date - Diff: compare against the stored seen-set; keep only new postings - Filter: keyword match on titles ("sales", "engineer", whatever maps to your product) and locations - Alert: push the delta to a webhook (n8n/Make/Zapier) or straight into Slack Run it daily on a schedule and you get a morning message like "Acme just posted: Head of RevOps (Remote)" - which for the right seller is worth more than any purchased lead list, for the same reason fresh beats stale everywhere in sales. Who actually uses this - Sales/GTM: hiring in your category = budget + timing. The trigger beats the list. - Recruiters: watch competitor postings to know who's growing and what talent they're fighting for. - Job seekers (underrated): monitor your 20 dream companies directly instead of refreshing aggregators that lag by days. - Analysts/founders: a competitor's job board is their roadmap, published voluntarily. Watch what they hire for. If you'd rather not build the plumbing I packaged this whole loop as an Apify Actor: Job Postings Monitor. Disclosure: mine. You give it company names (it auto-detects the ATS - typing stripe is enough), flip on monitor mode, and schedule it; it remembers what it's seen, returns only new postings, and can hit your webhook or Slack directly. Pay-per-job-returned, and in monitor mode you only pay for the new ones - watching 50 quiet companies costs cents. But honestly, if you're comfortable with a cron job, the endpoints above plus a key-value store get you a working version in an afternoon. The moat isn't the code - it's actually running it every day, which is exactly the part people stop doing by week three. (That's the real argument for scheduling it on managed infrastructure, whether mine or your own.) One closing thought Most intent data is inferred: someone visited a page, downloaded a whitepaper, matched a lookalike model. Job postings are declared intent - the company wrote down what it's investing in and posted it publicly, with a date on it. It's the difference between guessing someone is hungry and watching them book a table. Feature requests (more ATS platforms - Workday and BambooHR are the common asks) land in the Actor's Issues tab and genuinely shape what I build next. Top comments (0)