Job posting API: one endpoint for every job on the web

If you’ve ever shopped for a “job posting API” and ended up with three vendors, four scrapers, and a Python script to dedupe the overlap — this post is for you. A single normalized job-posting endpoint is the foundation for any product that touches hiring data, and it’s harder to build well than it looks.

Why three vendors

Most jobs-data products end up multi-vendor because no single vendor covers everything. JSearch has Indeed but not Workday. Coresignal has historical bulk but no real-time webhooks. ScrapingDog is great for one site but you maintain the normalization yourself. So you glue them together, write a dedup script, and add monitoring for each one.

What “unified” actually means

A real unified job-posting API needs four things at minimum:

• Source breadth — at least 20+ ATSs and the major boards. Anything less means you still need a second vendor.
• One JSON schema — same fields, same types, regardless of source. Otherwise your application code branches per source and you’ve gained nothing.
• Cross-source dedup — the same job posted to a Greenhouse board and mirrored to Indeed must collapse into one record. Without this, you ship duplicates to your downstream UI.
• Parsed structured fields — salary, location, remote flag, all extracted from free text into machine-readable types. Otherwise “structured data” is a marketing claim, not a feature.

JobsPipe’s endpoint

curl https://api.jobspipe.dev/v1/jobs \
  -H "Authorization: Bearer $JOBSPIPE_KEY" \
  -G \
  -d "query=staff engineer" \
  -d "salary_min=200000" \
  -d "posted_after=24h"

Returns every matching job across every source we index, deduped, with parsed comp, in one paginated response. Add ?source= to scope to one source or ?source=-indeed to exclude aggregator listings.