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/search \
  -H "Authorization: Bearer jp_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{ "job_title_or": ["staff engineer"], "posted_at_max_age_days": 1 }'

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