Archiving Job Postings for Pay Transparency Compliance

Pay transparency laws have been spreading across states and countries for a few years now, and they share a common thread: employers need to be able to show what a job posting actually said, including salary ranges, at the time it was live. HR and legal teams increasingly get asked to produce that evidence months after a posting was taken down — and by then, the live page is gone, and the applicant tracking system export rarely captures exactly how the posting rendered publicly.

A dated screenshot, taken automatically the moment a posting goes live, solves that gap cleanly.

Why This Needs to Be Automatic

• Postings get edited and removed. A role gets filled, a listing gets pulled, and the "as published" version is no longer reachable.
• ATS exports do not always match the public rendering. What candidates actually saw on the careers page can differ from the internal data record, especially with custom page templates or third-party job boards.
• Compliance requests arrive late. A pay-equity audit or a candidate dispute can surface long after a posting is gone, when memory and manual re-creation are the only fallback.

Capturing a Posting the Moment It Publishes

curl --request POST \
  --url https://api.prod.ss.snapshot-site.com/api/v1/screenshot \
  --header 'Content-Type: application/json' \
  --header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
  --data '{
    "url": "https://careers.example.com/jobs/senior-backend-engineer",
    "format": "png",
    "width": 1440,
    "fullSize": true,
    "hideCookie": true
  }'

fullSize: true matters here — the salary range disclosure is often further down the posting, alongside the full job description, and a partial capture is not useful as evidence if it cuts off before that section.

Wiring It Into the Publishing Workflow

The most reliable trigger is the publish event itself: when a job goes live on the careers site or ATS, fire the screenshot call as part of that same workflow, rather than relying on someone to remember. If postings publish through a CMS or ATS webhook, that webhook is the natural hook point — feed the new posting URL straight into the capture call above.

Store the resulting image with the posting's requisition ID, the publish date, and the URL. That triplet is what turns a folder of images into a searchable archive rather than a pile of files nobody can match back to a specific role.

Capturing Edits, Not Just the Original

If a posting's salary range or requirements change after publication — which itself can be legally significant in some jurisdictions — re-run the capture on every edit, not just on the initial publish. A version history of screenshots for a single posting is a much stronger record than a single snapshot, especially if a dispute hinges on when a change happened.

What Legal Teams Actually Ask For

When this comes up in practice, it is rarely "show me the job description." It is closer to "show me exactly what was disclosed, dated, for this specific posting, as the public would have seen it." A scheduled or event-triggered screenshot archive answers that question directly, without anyone needing to manually reconstruct a page that no longer exists.

Setting this up once as part of the publishing pipeline means every future posting gets an automatic, dated record — and Snapshot Site handles that capture the same way whether it runs on one posting a month or hundreds.