A provider of a job postings API that promises daily updates is making a claim about lag, and lag can be measured. This post separates the three delays the word daily covers, names the date fields that measure each one, and sets out a test you can run for a week on a sample of boards, with a worked example. It also sets down what Coresignal, TheirStack, Lightcast and LinkUp document about update frequency and date fields, and how the Fokals postings feed returns only what changed since your last call.
What a job postings API provider with daily updates must show
A provider of a job postings API with daily updates must show four things: how often it reads each board, a first-seen time on every posting beside the employer's own posting date, a close date for each posting that leaves its board, and a way to request only the postings opened or closed since your last call.
Daily can describe three different things.
| What daily can describe | What it tells you | What it leaves open |
|---|---|---|
| The delivery | A file or a response is produced every day | How old the records in it are |
| The read | Each board is visited at least once a day | Whether a posting seen today reaches you today |
| The record | A posting is in the API within a day of appearing on its board, and closed within a day of leaving it | This is the claim a hiring signal depends on, and the one to test |
Three delays behind one word
- Appearance lag. The time from a posting's publication on the employer's board to the provider's first observation of it. It is a subtraction on one record: the first-seen time minus the employer's posting date.
- Closing lag. The time from a posting's removal to its close date. A provider that confirms an absence before it closes a posting dates the close after the removal, by design. TheirStack's page on job data freshness says this of its own close date: it marks when the removal was confirmed, and the company may have taken the posting down earlier.
- Delivery lag. The time from the provider's observation to your own load. It depends on how the API lets you ask for changes and on how often you call it.
All three decide how fresh the data is when you use it, which is what data freshness measures. A stated refresh cadence describes the provider's schedule, and the fields below let you measure what the schedule produced.
The date fields that prove a daily update
Lag is a subtraction, so it needs two dated ends: what the board says and what the provider observed.
What the board itself publishes
An employer publishes its roles through an applicant tracking system or on its own careers page, and both can carry dates.
- Job markup on a careers page. The schema.org type JobPosting has a property for the publication date of the listing and one for the date after which it is no longer valid. Google's guide to job posting structured data lists the first among its required properties and the second among its recommended ones, with a note that it is required for a posting that has an expiration date. For a posting that is no longer available it gives three options: an expiry date in the past, a page that answers 404 or 410, or the removal of the markup.
- Greenhouse. Its Job Board API states that board data is publicly available and that no GET endpoint requires authentication. In its example responses each job in a board's list carries an updated time, and a single job carries a first-published time as well.
- Ashby. Its public job posting API returns a published time on each job, defined as when the job was last published.
A board's date is the employer's statement: it can be a day with no time, or the time of the latest publication. Your own read of the board, with its time, therefore belongs in the test.
What the provider must add
| Field | What it records | What it lets you measure |
|---|---|---|
| The posting date | The date the employer's board gives | The employer's end of the appearance lag |
| The first-seen time | The provider's first observation of the posting | The appearance lag |
| The last-seen time | The latest observation that found the posting | That the board is still being read |
| The close date | When the provider recorded that the posting had left its board | The closing lag and the life of a posting |
| A baseline flag | That the posting was already on its board at the provider's first read | Which first-seen times are not opening dates |
The fifth matters whenever coverage grows: on the day a provider first reads a board, every posting on it is seen for the first time. The flag keeps those postings out of the count of new roles.
What each provider's documentation says about update frequency and date fields
The statements below come from each provider's own documentation, read on 7 October 2026, in alphabetical order with Fokals last.
| Provider | Update frequency, as documented | Dates and status, as documented |
|---|---|---|
| Coresignal Base Jobs | Every live posting is checked again each day | The job ad's publish date, the time a record was first scraped, the time it was updated, an active flag, a deleted flag and the time and kind of the latest status change |
| Lightcast | Postings are updated daily | A date filter in its US job postings API that takes active postings or a start and an end date |
| LinkUp RAW | The companies it calls Tier 1 are refreshed every 24 hours for new, removed and changed postings | The first time a job was observed, the latest time it was observed, the latest time a change was observed and the latest time it was not found, with the posted date and the close date shown on the listing among its structured fields |
| TheirStack | Sources are scraped every 10 minutes, every hour or daily, by the kind of source | A posting date that is a day counted in UTC, a discovery time and a close date, with request filters on all three |
| Fokals Hiring | Refreshed daily; the methodology states the read cadence for each group of companies | The posting date as the board gives it, the first-seen and last-seen times, the close date and a baseline flag |
The field names behind those descriptions, as each document writes them:
Coresignal Base Jobs date_posted, created_at, updated_at, application_active, deleted, status_changed_at
LinkUp RAW created, last_checked, last_updated, delete_date; structured fields posted_date, close_date
TheirStack date_posted, discovered_at; filters posted_at_gte, discovered_at_gte, closed_at_gte
Greenhouse Job Board updated_at on a listed job; first_published and updated_at on a single job
Ashby posting API publishedAt
Fokals Job Postings posted_at, first_seen_at, last_seen_at, closed_at, found_on_first_readCoresignal defines its fields in the dictionary of its Base Jobs data and documents search and collect endpoints in its Base Jobs API. Lightcast describes two ways a posting expires, a revisit that finds the advertisement no longer active and an age limit, for the active postings of its Analyst and Developer products, and documents its date filter in the reference for its US job postings API. LinkUp defines these dates in the data dictionary of its RAW feeds, and its product page lists delivery through cloud data platforms and by FTP.
How to read only what changed since your last call
An API can let you ask for changes in three ways, and the way decides your delivery lag and your cost in calls.
- A change feed with a cursor. Rows are events, an opening or a closing, ordered oldest first from a time you set. With cursor pagination you store the last cursor and resume from it, so each run continues where the last one stopped.
- Date filters. You ask for the postings discovered on or after a time, and separately for those closed on or after it. TheirStack's job search reference documents filters of this kind on the posting date, the discovery time and the close date. Overlap each window with the one before and deduplicate on the posting's id, because a filter by day returns the boundary day again.
- A snapshot. You download every open posting and compare it with the day before. It works with any source, takes the most calls, and gives you the day of a change in place of its time.
The Fokals API follows the first pattern. One endpoint returns every job posting opened or closed from a time you set, across companies, oldest first, and a second returns the same for one company.
GET /api/v1/postings?since=2026-09-28T06:00:00Z&limit=200
Authorization: Bearer fk_live_...
GET /api/v1/postings?since=2026-09-28T06:00:00Z&limit=200&cursor=eyJ1IjoiMjAyNi0...Each row is an event, opened or closed, with its time: the first-seen time for an opening and the close time for a closing. A posting is in the feed once for each over its life, and the row carries the posting date, the first-seen time, the close date and the baseline flag. Times are ISO 8601 in UTC.
A page holds 1 to 200 rows, 100 by default. While a response carries a next cursor, you send it back with the same parameters, and on the last page it is null. A cursor is tied to the query that made it and can be kept and resumed later, so the cursor stored yesterday is today's starting point. That is incremental sync on one stored value, worked through in the guide to keeping a warehouse in step.
Postings found on a board's first read are left out of the feed by default, and a parameter includes them. The API reference lists every parameter, among them filters by event, job function, seniority and country.
A seven-day test on a sample of boards
The test compares two records of the same boards over the same week: yours and the provider's.
- Choose the boards. Take 20 to 50 companies from the list you track, spread over the board systems they use and over heavy and occasional hirers.
- Take a first read. Read each board once and store the address of every posting on it, with the time of your read. These postings were open before the test, so they stay out of the appearance lag.
- Read every day. For seven days, at a fixed hour in UTC, read each board again through the public feed its system documents. Store the addresses found, any publication time the board gives and the time of your read.
- Pull the changes. After each read, ask the provider for the postings opened or closed since your last call. Store each first-seen time and close date as returned.
- Match on the posting's address. Normalise it first: host in lower case, tracking parameters removed.
- Compute the appearance lag for each posting that appeared after your first read: the provider's first-seen time minus the board's publication time. Where the board gives a day with no time, or no date, your own reads are the bounds.
- Compute the closing lag for each posting that left a board, twice: from your last read that found it, and from your first read that did not. The true lag lies between the two.
- Count the misses. A posting on a board that never reached the API is a gap in coverage. A posting closed in the API and still on its board is a false close.
Report four numbers for openings and the same four for closings: the share within 24 hours, the median, the 90th percentile and the maximum. Read the tail before the median, because a signal acts on the slowest postings as well as the typical one.
A worked example: one week on the board of Acme Robotics
Acme Robotics is an invented company, and every figure below is illustrative.
Assumptions:
- Acme Robotics publishes its roles on one board, which gives a publication time for each posting.
- You read the board once a day at 06:00 UTC: on day 0 for the first read, then on days 1 to 7.
- After each read you pull the provider's changes since your last call.
- Ten postings appear on the board after the first read, and all ten reach the API.
| Posting | Published on the board | First seen by the provider | Lag in hours |
|---|---|---|---|
| 1 | Day 1, 09:00 | Day 1, 21:00 | 12 |
| 2 | Day 1, 14:00 | Day 2, 08:00 | 18 |
| 3 | Day 2, 10:00 | Day 2, 16:00 | 6 |
| 4 | Day 2, 15:00 | Day 3, 13:00 | 22 |
| 5 | Day 3, 08:00 | Day 3, 18:00 | 10 |
| 6 | Day 3, 11:00 | Day 4, 03:00 | 16 |
| 7 | Day 4, 09:00 | Day 4, 17:00 | 8 |
| 8 | Day 4, 16:00 | Day 6, 07:00 | 39 |
| 9 | Day 5, 10:00 | Day 6, 00:00 | 14 |
| 10 | Day 5, 13:00 | Day 6, 09:00 | 20 |
In order, the lags are 6, 8, 10, 12, 14, 16, 18, 20, 22 and 39 hours. They sum to 165, so the mean is 16.5 hours. The median is the midpoint of the fifth and sixth values, 14 and 16, which is 15 hours. Nine of the ten are under 24 hours, so 90% of the new postings were in the API within a day, and the maximum is 39 hours.
Delivery lag comes on top. Posting 1 was first seen at 21:00 on day 1 and your next call ran at 06:00 on day 2, so it reached your warehouse 21 hours after publication: 12 plus 9. Posting 8 was first seen at 07:00 on day 6, an hour after that morning's call, so you received it at 06:00 on day 7, 62 hours after publication: 39 plus 23.
One posting closed during the week. Your read at 06:00 on day 3 found it, your read at 06:00 on day 4 did not, and the provider's close date is 19:00 on day 4. The board gives no time for a removal, so your reads bound the closing lag: at least 13 hours, counted from the read that missed it, and at most 37 hours, counted from the read that last found it. Reading the board every six hours would narrow that range from 24 hours to six.
One board shows the method. The whole sample gives the 90th percentile and the maximum enough rows to put to a provider.
How the Fokals record answers the test
Hiring is refreshed daily, and Job Postings is collected from companies' own careers pages, so the board you read in the test is the place the record was observed. Our note on reading job postings at the source covers duplicates and attribution.
Each record of Job Postings carries the dates the test needs: the posting date as the board gives it, the first-seen and last-seen times and the close date, with a baseline flag on a posting that was already on its board at the first read. The methodology sets out the rule by which a posting is closed, and the data dictionary defines every field.
Beside the postings, Hiring Activity counts the open, new and closed postings of each company for each closed UTC day. It is written once, after the day closes, and never revised, and a baseline posting is never counted as new. The daily counts you derive from your own reads can be set against it. Sample data on the companies you name is sent on request, with the data dictionary and the methodology.
Frequently asked questions
Which job data API providers publish daily updates to job postings?
Four providers whose documentation was read on 7 October 2026 describe a daily or shorter cycle. Coresignal states that every live posting is checked again each day. TheirStack states that it scrapes sources every 10 minutes, every hour or daily, by the kind of source. Lightcast states that postings are updated daily. LinkUp states that the companies it calls Tier 1 are refreshed every 24 hours, and delivers its feed through cloud data platforms and FTP. Fokals refreshes its Hiring product daily and returns the postings opened or closed since a time you set through a REST API.
What does daily updates mean for a job postings API?
It can mean three things: a delivery is produced every day, each board is read at least once a day, or a posting is in the API within a day of appearing on its board and closed within a day of leaving it. Only the third describes the record. Ask a provider which one it means, and ask for the first-seen time and the close date on every posting, which are the two fields that let you measure it.
How do I measure how fresh job postings data is?
Subtract two dates on the same posting. Appearance lag is the provider's first-seen time minus the publication time the employer's board gives. Closing lag is the provider's close date minus the time the posting left the board, which you bound with your own daily reads. Run both for a week on 20 to 50 boards, then report the share within 24 hours, the median, the 90th percentile and the maximum.
How do I get only new and closed job postings since my last API call?
Use a change feed where the API offers one: rows ordered oldest first from a time you set, each marked as an opening or a closing, with a cursor you store and resume from. Where the API offers date filters, ask for the postings discovered since your last call and, separately, for those closed since then, overlap the windows and deduplicate on the posting's id. The Fokals postings feed works the first way.
Why is a posting's close date later than the day it left the board?
A record that confirms an absence before it writes a close dates the close after the removal. A board can be unavailable for a short time, and closing on the first miss would close roles that are still open. The close date therefore records when the removal was established. In a test, bound the true removal time with your own reads of the board and judge the closing lag against those bounds.
The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.
What this page says about the products it names was checked against their public documentation on 7 October 2026. Product and company names are trademarks of their owners. Fokals is not affiliated with them or endorsed by them.