What is a data API?

A data API is an interface whose purpose is to deliver records: you send a query with filters and paging, and it returns structured data such as JSON rows. It differs from an application API, which exposes the actions of a product, like creating an order or sending a message. A data API is read-heavy and built for retrieval.

The design choices follow from that purpose. A data API needs a stable schema, because consumers store what it returns. It needs filters that map to real questions, not just a primary key lookup. It needs cursor pagination so a consumer can walk a large result set without missing or repeating rows. It needs a way to fetch only what changed since the last call, so pipelines do not re-read the whole corpus. And it needs provenance on each record: where the row came from and when it was last confirmed. Application APIs rarely need any of these, since their unit of work is an action, not a dataset.

JobsPipe is a data API for job postings. One endpoint, POST /v1/jobs/search, accepts filters such as job_title_or, job_country_code_or, remote, skills_or, min_salary_usd and status, and returns normalized rows with fields including job_title, company, date_posted, discovered_at, last_seen_at, status, closed_at and ghost_score, each with its source board under sources. A cursor pages through results, discovered_at_gte returns only postings first seen since a timestamp, and status set to closed returns postings that have ended, so the same endpoint serves a live search box and a nightly pipeline.

You can see the shape without an account. The sandbox endpoint accepts the same request body as the live one and answers with sample records in the identical schema, no key and no quota, so a consumer can build the parser and the paging loop first and switch to a live key from the dashboard afterwards.

The full treatment is on Jobs API.