Embedding Screenshots in White Label Reporting Tools

White label reporting tools live or die by polish. Agencies pay for them because they want client-ready PDFs and dashboards that look like their own product — not yours. The visual layer matters as much as the data, and that's where most reporting platforms hit a wall: rendering live web content (analytics dashboards, landing pages, competitor sites, social profiles) reliably, at scale, without maintaining a fleet of headless browsers.

A screenshot API solves that problem cleanly. Here's how to wire one into a white label reporting product without compromising on branding, performance, or cost.

Why headless browsers break reporting workflows

Most teams start by spinning up Puppeteer or Playwright on a worker. It works for the first 100 reports. Then the failures start:

• Memory leaks after a few hundred page loads, requiring constant restarts
• Inconsistent rendering for sites with lazy-loaded content, web fonts, or cookie banners
• Auth-protected dashboards (GA4, Search Console, Meta Ads) that need session handling
• Concurrency limits — a single Chromium instance eats 300–500MB of RAM
• PDF pagination that breaks when CSS print styles aren't perfect

For a reporting tool generating a few thousand client reports a month, this turns into a dedicated infrastructure problem. Offloading to a screenshot API like PxShot trades that ops burden for a predictable HTTP call.

What the integration looks like in practice

1. Map your report sections to capture types

Before writing code, audit what your reports actually contain. A typical white label SEO or marketing report has:

1. Hero screenshots — full-page captures of the client's homepage or key landing pages
2. Dashboard snapshots — embedded views of analytics, rank trackers, or ad platforms
3. Competitor visuals — side-by-side captures for benchmarking
4. SERP screenshots — proof of ranking positions at a given date
5. PDF exports — the entire report rendered as a downloadable file

Each maps to a different API call pattern. Hero shots need full-page PNG. Dashboards need authenticated viewport captures. PDF exports need print-optimized rendering.

2. Build a capture service layer

Wrap the screenshot API behind your own service so you can swap providers, cache, and add report-specific logic. A minimal Node.js wrapper:

async function captureForReport(url, options = {}) {
  const params = new URLSearchParams({
    url,
    format: options.format || 'png',
    full_page: options.fullPage ?? true,
    viewport_width: options.width || 1440,
    viewport_height: options.height || 900,
    delay: options.delay || 2000
  });

  const res = await fetch(`https://api.pxshot.dev/v1/capture?${params}`, {
    headers: { 'Authorization': `Bearer ${process.env.PXSHOT_KEY}` }
  });

  if (!res.ok) throw new Error(`Capture failed: ${res.status}`);
  return Buffer.from(await res.arrayBuffer());
}

Now every report generator calls captureForReport() instead of touching the API directly.

3. Cache aggressively

White label reports are often regenerated — clients reload the dashboard, agencies tweak date ranges, PDF exports happen on a schedule. Capturing the same URL twice in five minutes is wasted spend.

• Hash the URL plus capture parameters as a cache key
• Store the resulting image in S3 or R2 with a TTL based on content type (homepages: 24h, SERPs: 1h, dashboards: 15min)
• Serve cached versions through your CDN under your own domain — critical for white labeling

4. Rebrand the delivery layer

This is the white-label part. Never expose the screenshot provider's URL to end clients. Always:

• Proxy images through cdn.youragency-reports.com or similar
• Strip any provider metadata from PDF outputs
• Use your own watermark or logo overlay (apply it server-side after capture)

Handling the hard cases

Authenticated dashboards

If you're capturing client-side analytics dashboards, you have three options:

1. Use the platform's official API to pull raw data and render your own charts (best for GA4, Search Console)
2. Capture pre-authenticated share URLs when the platform supports them (Looker Studio, Metabase public links)
3. Pass session cookies to the screenshot API if it supports custom headers/cookies — PxShot accepts these for capturing logged-in views

Long pages and PDF reports

For multi-page PDFs, you generally don't want to capture the live web page as PDF. Instead:

1. Generate each section as a PNG via the API
2. Assemble the final PDF server-side using a library like pdfkit or pdf-lib
3. Embed captures as images, add your own typography and branded headers

This gives you pixel-perfect control over pagination, fonts, and layout — none of which is reliable when you let a browser render the whole thing.

Rate limits and bulk runs

Most reporting tools generate reports in batches — month-end, weekly digests, scheduled exports. Two patterns help:

• Queue captures with something like BullMQ. Cap concurrency to whatever your API plan allows (commonly 5–20 parallel requests)
• Pre-warm overnight. If you know 200 reports run Monday 9am, capture the static sections Sunday night and cache them

Cost modeling for reporting at scale

A rough back-of-envelope for a reporting SaaS with 500 agency customers, each generating 20 reports a month with 8 captures per report:

• 500 × 20 × 8 = 80,000 captures/month raw
• With 60% cache hit rate: 32,000 actual API calls
• At typical screenshot API pricing of $0.002–$0.005 per capture: $64–$160/month

Compare that to running your own headless infrastructure: a couple of beefy workers on Fly.io or AWS, plus engineering time to maintain it. The API route wins until you're well into the millions of captures.

What to evaluate before committing

When picking a screenshot API for a white label use case specifically, check:

• Custom headers and cookies for authenticated captures
• Format support — PNG for embedding, JPEG for size, WebP for modern clients, PDF when you need it natively
• Viewport and device emulation for mobile report variants
• Wait conditions (wait for selector, wait for network idle) — essential for SPAs
• Predictable pricing without per-feature gating
• Response latency under 5 seconds for synchronous report generation

PxShot covers these primitives directly via query parameters, which keeps the integration simple — you don't need a dedicated SDK to ship the first version of your reporting pipeline.

If you're building or extending a white label reporting tool, you can start testing capture flows on the PxShot free tier before wiring it into production. Plenty of headroom to prototype a full report pipeline end to end.