Gertner Data · tools for automation
Websites and PDFs into data.With a source and a history.
An automated workflow needs records it can pass to a spreadsheet, catalogue, search index or its next step. We built the Gertner Data family to read sitemaps, PDF tables and job boards, keep their sources and distinguish genuine changes from failed reads.
Published · products available in Apify Store; public listings checked on 19 October 2026
Product workflow diagram
Source · coverage · changes · errors
- JSON / CSVstructured records for the next step
- 2 checkssuccessful observations without a vacancy before a closure eventa timeout is not confirmation
- SourcesPDF records retain their page and table
- APItools connect to an external workflow
A workflow needs records it can act on
A sitemap lists page addresses. A PDF spreads a price list across pages. Each recruitment platform uses its own field names. Passing these through unchanged leaves the next step to handle every source differently.
We built focused tools with defined output fields, read status and enough state to continue the process. On the next run, the monitoring tools accept a saved snapshot and return the changes against it.
- Sitemap Diff
What changed on a website
New URLs can enter a crawl queue. Removed URLs and changed metadata receive their own events. The comparison covers sitemap membership and metadata.
- PDF Tables
A table with its evidence
Rows export to JSON and CSV with a page, table and document identifier.
- Job Feed Delta
How a job board changes
New roles, field updates and confirmed absences across Greenhouse, Lever and Ashby use a shared schema.
A timeout must not become a closed vacancy
Suppose an employer’s website stops responding. A basic monitor treats the empty result as a closed job board. When the website recovers, it announces the same vacancies as new. The recipient gets noise instead of useful events.
Our tool retains the previous board state when a read fails. The first successful check without a role marks it as missing. A second successful observation triggers the closure event. That still means absence from the source: it does not claim someone has been hired.
A separate guard stops mass removals when most roles suddenly disappear from a sufficiently large board. The source needs checking before that change is accepted.
Product workflow diagram
- Snapshot savedVacancy present in sourceBaseline
- Source timed outPrevious snapshot retainedNo closures
- Successful readFirst confirmed absenceAwait confirmation
- Successful read againVacancy still absentCLOSED event
An incomplete crawl is not treated as page removal
A nested sitemap may be temporarily unavailable, or a crawl may reach its limit before the last file. Neither proves that pages have been removed.
Sitemap Diff permits removal events only when both snapshots are complete and cover the same root sitemaps and filters. Errors, conflicting duplicates and crawl limits appear in the summary. The next process can check coverage before changing its catalogue.
Changed sitemap metadata does not prove that page text has changed. Page content needs a separate crawl.
Every row leads back to its PDF
When a table enters an accounting system or catalogue, the reader needs to know where each value came from. Records retain the document, page, table and row position. A content-based document identifier gives identical files the same identifier.
Values that look numeric remain strings. An item code keeps its leading zero, and local punctuation does not silently change an amount. CSV exports escape values that a spreadsheet might interpret as formulas.
The extractor reads the PDF text layer. A scan without text receives an explicit status; image recognition is outside this product’s scope.
Failures stay visible and limits are set in advance
A successful response is only part of an integration. The caller also needs to distinguish an unavailable source, an unsupported document and a reached limit. Tools return these states separately so the workflow can stop or retry the relevant step.
Network access has boundaries: public addresses, bounded responses and timeouts. The calling workflow owns its snapshots and decides when to check again and which version to use as its baseline.
What supports this case
- Sitemap Diff, PDF Tables to Records and Job Feed Delta have public listings in Apify Store.
- Retaining a snapshot during a timeout and closing after a repeated observation were reproduced locally using the product function.
- Diagrams explain the mechanism. This case makes no claims about customer revenue or measured time savings.
How it was built
From a one-off scrape to a repeatable process
We separated source reading, normalisation and state comparison. Network failures therefore stay distinct from business events, and the caller receives a snapshot for its next run.
- CollectRead an authorised source within defined limits.
- CheckRetain provenance, coverage and read errors.
- ConnectPass records and a snapshot to the next workflow step.
For technical readers
For technical readers
- Runtime
- Python and Node.js, with separate product contexts on Apify.
- State
- Explicit snapshots. Job-board comparison is a separate function with no network requests.
- Provenance
- PDF content hash, page, table and row; snapshots and observation times for changes.
- Boundaries
- Public HTTP(S) sources, address validation, read limits and structured errors.
Where the numbers come from
Sources
- Product source code and the deployed-source manifest exported on 20–22 September 2026.
- Public Gertner Data listings in Apify Store, checked on 19 October 2026.
- A local state-comparison example with a synthetic vacancy.
Next system
AI sales operator →