Automated Screenshot Evidence for Affiliate and Partner Compliance Monitoring

Brands with affiliate networks or reseller partners rarely control what those partners actually publish. A partner's landing page might use an outdated logo, an expired promo, an unapproved claim, or pricing that no longer matches the brand's own site — and unless someone happens to click through, nobody notices until a customer complains or legal gets involved.

Manual spot-checking a partner list does not scale past a handful of partners, and it produces no record of what a page looked like on a given date if a dispute comes up later. Scheduled screenshots fix both problems at once.

What Compliance Teams Actually Need

• Evidence, not just awareness. A dated screenshot is something you can point to in a dispute. A vague memory of "I think that logo was wrong" is not.
• Regular cadence, not one-off checks. Partner pages change without notice — a weekly or daily capture catches drift close to when it happened.
• A way to flag change, not just archive it. Storing screenshots is only half the job; knowing when a monitored page actually changed is what turns an archive into a monitoring system.

The Basic Setup

Capture each monitored partner URL on a schedule:

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://partner-site.example.com/promo",
    "format": "png",
    "width": 1440,
    "fullSize": true,
    "hideCookie": true
  }'

Store the resulting image alongside the partner name, the capture date, and the URL — that is the dated record a compliance team can reference later.

Turning Captures Into Alerts

A stored archive answers "what did this look like on this date." To catch changes as they happen, run each new capture against the last stored image with v3/compare:

curl --request POST \
  --url https://api.prod.ss.snapshot-site.com/api/v3/compare \
  --header 'Content-Type: application/json' \
  --header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
  --data '{
    "before": {"imageUrl": "https://cdn.example.com/archive/partner-site-2026-06-20.png"},
    "after": {"url": "https://partner-site.example.com/promo", "width": 1440, "fullSize": true, "hideCookie": true},
    "threshold": 0.15
  }'

A mismatchPercentage above your threshold means the partner page changed since the last capture — worth a human look before it turns into a bigger issue. A wider threshold than a typical release-review diff makes sense here, since partner pages are outside your control and small unrelated content shifts (rotating testimonials, a changed hero image) are common and not usually the thing compliance cares about.

Building the Partner List Into the Workflow

The practical version of this is a spreadsheet or database of partner URLs, a scheduled job (cron, a scheduled GitHub Actions workflow, or an n8n workflow) that loops over the list, and a place to land both the archived image and any alert when the diff crosses your threshold. Slack is a natural destination for the alert; a simple date-stamped folder or bucket is enough for the archive itself.

What This Does Not Replace

This is a monitoring layer, not a legal opinion — it tells a compliance team when to look, not whether what they are looking at actually violates an agreement. That judgment still belongs to the humans reviewing the flagged pages. What automation removes is the far more tedious part: remembering to check, and having proof of what was found.

Once the monitoring list and cadence are set up, adding a new partner is one row in a spreadsheet, not a new manual process — and Snapshot Site is priced to run comfortably across a partner list of any size.