DEV Community: Ohad Badihi

Automate weekly pricing-page PDFs with Zapier + Rendershot

Ohad Badihi — Wed, 20 May 2026 11:04:03 +0000

Pricing pages change constantly and nobody notices. If you run a startup that competes on price, or a product team that needs a historical record for exec reviews, a weekly PDF archive of every page that matters is the kind of chore you definitely won't keep up manually.

This post walks through a Zap that does it for you: every Monday at 9am, render your competitor's pricing page as a PDF and email it to the team. Takes ten minutes end-to-end. Zero ongoing maintenance.

The two pieces:

Schedule by Zapier — built-in trigger that fires on a cron.
Rendershot — captures the URL, exposes the file to downstream steps via a presigned URL.

What you'll need

A Rendershot account (free plan works — 200 renders/month).
A Zapier account.
The URL of the pricing page you want to archive. For this tutorial I'll use https://competitor.example.com/pricing.

Note: The Rendershot Zapier app is in public beta. Until it graduates to the directory, install it via the public invite link in Step 1 below — works identically to a directory install, including for existing Zaps.

Step 1 — Add the Rendershot app to your Zapier account

Click this invite link while signed in to Zapier:

Add Rendershot to Zapier →

Zapier adds the app to your account and the three building blocks — Capture Screenshot, Capture PDF, and the New Render trigger — show up in the Zap editor.

Step 2 — Create a Rendershot API key

Open rendershot.io/dashboard/keys and click Generate key. Copy the value — it starts with sk_live_….

Note: Your API key is the only secret you need for this Zap. Treat it like a password.

Step 3 — Build the Zap

In the Zapier editor:

Trigger: Schedule by Zapier

App: Schedule by Zapier
Event: Every Week
Day of week: Monday
Time: 09:00

Test the trigger — Zapier produces a sample "pretty_date" value.

Action 1: Rendershot — Capture PDF

App: Rendershot
Event: Capture PDF

When asked to connect, paste your sk_live_… key. Zapier verifies it against GET /v1/ping (free — no credits consumed).

Configure:

URL: https://competitor.example.com/pricing
Paper size: A4
Orientation: Portrait
Print background graphics: on
Wait for: Network idle (lazy-loaded content, slower) — pricing pages often lazy-load A/B test variants, Network idle gives the page time to settle.

Test the step. You'll get back a job_id, status: queued, and a result_url.

Action 2: Rendershot — New Render (wait step)

Here's the clever bit: Rendershot actions return a job ID immediately, not the finished PDF. We need to wait until the render completes to attach the actual file to an email.

The new_render trigger fires when any async render in your account finishes. You can either:

Add a second Zap with new_render as the trigger and Gmail as the action (decoupled; recommended).
Use the Rendershot new_render step with a job ID filter inside this Zap.

For simplicity, use approach 1 — it scales better and keeps each Zap doing one thing.

Action 3: Gmail — Send Email (in the second Zap)

Create a second Zap with:

Trigger: Rendershot → New Render
Action: Gmail → Send Email

In the Gmail step:

To: team@example.com
Subject: Competitor pricing snapshot — {{New Render Completed At}}
Body: A short note plus the {{File URL}} field.
Attachments: map to {{File URL (no auth required, 24h)}} — the 24-hour presigned URL Rendershot ships in every webhook payload.

Heads up: Do not map Attachments to {{Result URL}}. That URL requires an X-API-Key header, which Gmail can't inject when fetching the file. You'll get a silent 401 and no attachment. Always use File URL for downstream no-code steps.

Step 4 — Publish both Zaps

Turn them on. The first Zap fires every Monday at 9am, queues a render. A few seconds later Rendershot delivers a job.completed webhook to Zapier, which fires the second Zap, which emails the team the PDF.

Cost per week: 1 Rendershot credit + 1 Zapier task per step. On the free Rendershot plan that's 0.5% of your monthly budget.

Going further

Once the two Zaps are running, the pattern generalises:

Archive multiple competitors. Put URLs in a Google Sheet, change the first Zap's trigger to Sheets → New Row, and the single Zap captures all of them as they're added.
Post to Slack instead of Gmail. Swap the second Zap's action to Slack → Upload File. Same File URL field, same auth-less fetch.
Upload to Dropbox / Google Drive. For long-term archiving. Both apps have "Upload File from URL" actions that work with the File URL.
Diff against last week's PDF. Pipe both weeks through a diff tool — out of scope for this post but a natural next step.

Why this works

The reason this Zap is reliable (vs. something you wire with a headless browser script on a cron) is the three pieces that Rendershot ships out of the box for no-code pipelines:

Async rendering — long pages don't time out mid-Zap.
Webhook trigger — Zapier doesn't need to poll; it reacts to the completed event.
Presigned File URL — downstream steps can fetch the file without injecting an API key, which Zapier can't do when attaching files to emails or uploading to cloud storage.

That last point is the most common foot-gun with screenshot/PDF APIs in no-code land. Rendershot's new_render trigger hands you a 24-hour presigned URL on every completed render so attachments just work.

Want to try? The free Rendershot plan includes 200 renders / month — enough to run this Zap for ~4 years without paying. Grab an API key, then add Rendershot to Zapier. More on the integration in the Zapier setup guide.

Rendershot vs Urlbox: choosing a screenshot API in 2026

Ohad Badihi — Mon, 04 May 2026 09:41:05 +0000

Picking a screenshot API feels binary until you start integrating, then the edges show: one service has a Python SDK but no async queue, another has webhooks but charges extra for authenticated pages, a third makes you wire up an S3 bucket yourself. This post walks through how Rendershot and Urlbox compare across the dimensions that actually hurt to change later.

Upfront: I build Rendershot, so treat this as a structured comparison with obvious bias, not an impartial review. I've tried to keep every claim about Urlbox pinned to their public docs and pricing page. If anything here drifts out of date, their docs are the source of truth.

The short version

Pick Urlbox if you want an older, battle-tested product with a big feature surface and you're willing to pay a premium for polish. They've been shipping since ~2014.
Pick Rendershot if you want transparent pay-as-you-go pricing, no-code distribution (Zapier, MCP), and AI-based cookie-banner cleanup baked in rather than sold as an add-on.

Both can render screenshots and PDFs, expose a REST API, and return files via URL or inline bytes. Below is where they diverge.

Pricing model

Urlbox prices on renders per month with tiered plans. Overages push you into the next tier. The starter plan (at time of writing) sits in the low double digits; teams with bursty traffic end up paying for headroom they rarely use.

Rendershot prices on credits — one credit per render, buy what you use. Unused credits roll forward. The free tier includes 200 renders per month with no card required, which is enough to prototype an entire Zap end-to-end before committing.

Rough mental model: if your traffic is predictable and high volume, Urlbox tiers work out fine. If your traffic is spiky or you're still figuring out product-market fit, pay-as-you-go avoids the "we hit the limit on a Tuesday" failure mode.

Getting to the first screenshot

Urlbox's signup → API key → first request flow takes a few minutes, plus you authenticate requests by signing URLs with HMAC on your side (their templates help, but it's still code to write).

Rendershot hands you an sk_live_… key and this curl:

curl -X POST https://api.rendershot.io/v1/screenshot \
  -H "X-API-Key: sk_live_..." \
  -d '{"url":"https://example.com","async":true}'

No URL signing, no HMAC — just a header. If you're prototyping, this is a few hundred ms faster per round-trip in "does it work" land. For production, URL signing has security benefits; both approaches are fine, just different.

SDK coverage

Both offer Python and Node.js SDKs. Rendershot additionally has:

MCP server (@rendershot/mcp-server) for Claude, Cursor, Windsurf, and other MCP-compatible AI agents. You can ask an agent to "screenshot this URL" and it'll route through Rendershot.
Zapier app (public beta), with a capture_screenshot action, a capture_pdf action, and a new_render trigger that fires when an async render finishes — with a 24-hour presigned file URL attached, so downstream Gmail / Dropbox / Slack steps can fetch the file without an API key.

Urlbox has a Zapier integration too — worth comparing the action list to see which fits your workflow better.

Authenticated pages

Screenshotting pages behind a login is the feature that most often determines which API sticks. Both services support it.

Urlbox supports cookie / header injection and has a "sessions" concept to reuse authentication across calls.
Rendershot supports authenticated pages via per-request auth params (cookies, headers, storage state), with no separate session storage to manage.

If you need to re-use the same authenticated browser context across many calls in a short window, Urlbox's sessions are easier. If you'd rather send auth context per-request and keep your API stateless, Rendershot matches that shape directly.

AI cleanup

Cookie banners and newsletter popups wreck screenshots taken for marketing/reporting purposes. Both services offer ways to block them — Urlbox has selector-based hiding, Rendershot has an ai_cleanup flag (fast / thorough) that removes them semantically without you writing selectors.

The AI approach is the real differentiator here: it handles sites you haven't seen before, GDPR-compliant sites in different jurisdictions, and redesigns that would break your hard-coded selectors.

Async / queue model

Urlbox returns screenshots synchronously by default and supports polling for large renders.
Rendershot supports both modes: set async: true to get back a job ID immediately, poll /v1/jobs/<id> for status, or subscribe a webhook to be notified when the render finishes. The webhook payload includes a 24-hour presigned file URL — crucial for no-code pipelines where downstream steps can't authenticate.

If your workload is mostly fast single renders, sync is simpler. If you render long-animated pages or bulk-render thousands of URLs, async + webhooks will save you retries and timeouts.

Output storage

Urlbox can return the file directly or upload to your S3 bucket — you bring the storage. Rendershot stores rendered files for 24 hours on Hetzner Object Storage and returns a presigned URL; after 24 hours the file is deleted. You don't need to configure anything.

If compliance requires files stored in your own buckets, Urlbox's BYO-S3 model wins. If you want zero storage configuration and 24h retention is fine, Rendershot's model wins.

When to pick which

Pick Urlbox if:

You want a long-lived product with a broad feature surface.
You need browser-session reuse for authenticated multi-page flows.
You need renders stored in your own S3 bucket for compliance.

Pick Rendershot if:

You value transparent pricing and a generous free tier.
You want a Zapier / MCP / webhook-native integration story.
You want AI-based cookie-banner cleanup rather than selector lists.
You'd rather start with curl in 60 seconds and pay for what you use.

Try Rendershot for free: create an API key at rendershot.io/register. 200 renders / month on the free plan, no card required. If you ship something with it, I'd love to see it — support@rendershot.io.

Headless Chromium at scale: four fixes for a fleet that kept eating RAM

Ohad Badihi — Thu, 30 Apr 2026 07:05:34 +0000

The first time a worker died with an OOM kill in the middle of a render, I assumed it was a bad page — some site with an infinite-scroll loop or a 200MB hero video. The second time it happened, on a different worker rendering a different URL, I started paying attention. The third time, a Tuesday morning, every worker in the fleet went down inside a five-minute window.

Headless Chromium leaks memory. Not in a "oh that's a bug, file an issue" way — in a "this is the operating reality of a 30-million-line C++ browser, and you have to plan around it" way. If you run Playwright or Puppeteer in production for more than a few minutes per request, you will eventually meet this reality. This post is the four things I changed in Rendershot — a screenshot and PDF API I run — that took us from "workers crashing twice a day" to "workers running for weeks without intervention."

None of these are clever. They're the boring discipline of treating a browser like a long-lived process, not a function call.

Setup, in one paragraph

Each Rendershot worker is a Docker container running an ARQ (Redis-backed) job queue. Jobs come off the queue, get rendered with Playwright, and the resulting bytes are uploaded and the file path written back to Postgres. Concurrency is bounded; the worker fleet scales horizontally — no shared state between workers, just one Chromium process each.

That last part was the first fix.

Fix 1 — One browser per worker, not per request

The naive way to run Playwright is the way the docs suggest:

async with async_playwright() as p:
    browser = await p.chromium.launch()
    page = await browser.new_page()
    await page.goto(url)
    await page.screenshot(path="out.png")
    await browser.close()

This is fine for a script. It is catastrophic for a server. Launching Chromium takes 300–600ms on a modern Linux box, allocates ~150MB of resident memory before you've even pointed it at a URL, and forks a small army of helper processes (renderer, GPU, network, utility). Tearing it down repeats most of that work.

If your worker handles 10 renders per second, you are spending more time launching and killing browsers than you are rendering anything. And every leaked file descriptor, zombie subprocess, or partially-released shared memory segment compounds.

The fix is to launch the browser once per worker, on startup, and reuse it for every request:

class WorkerSettings:
    on_startup = startup
    on_shutdown = shutdown
    max_jobs = config.settings.browser_max_pages

async def startup(ctx):
    pool = BrowserPool()
    await pool.start()  # launches one Chromium
    ctx['pool'] = pool

async def shutdown(ctx):
    await ctx['pool'].stop()

Each render now creates a page (cheap, ~5ms), uses it, and closes it. The browser stays alive for the lifetime of the worker. Crash isolation is per-container — if a worker's browser dies, we lose that worker, not the fleet.

Fix 2 — Cap concurrent pages with a semaphore (and match it to your job queue)

A persistent browser will happily let you open 50 tabs. It will also happily eat 8GB of RAM doing it.

You need a hard cap on how many pages render concurrently inside one browser. We use an asyncio.Semaphore:

@dataclasses.dataclass
class BrowserPool:
    max_pages: int = 4
    _semaphore: asyncio.Semaphore | None = None

    async def start(self):
        self._semaphore = asyncio.Semaphore(self.max_pages)
        self._browser = await self._playwright.chromium.launch(args=_CHROMIUM_ARGS)

    async def render_screenshot(self, params):
        async with self._semaphore:
            context, page = await self._new_page(params)
            try:
                await self._navigate(page, params)
                return await page.screenshot(...)
            finally:
                await page.close()
                await context.close()

The non-obvious part: the semaphore alone isn't enough. Your job queue needs to match it. ARQ has a max_jobs setting that controls how many tasks the worker pulls off Redis simultaneously. If max_jobs > max_pages, jobs get pulled, hit the semaphore, and wait — eating queue slots that another worker could be servicing.

class WorkerSettings:
    max_jobs = config.settings.browser_max_pages  # match the semaphore

Both numbers tied to the same setting. No oversubscription. The "right" number for both is a function of how much RAM your container has and how heavy your renders are; we tune ours per environment.

Fix 3 — Restart the browser on a schedule, not on failure

This is the one that took us longest to accept.

Chromium's memory growth is not linear. Most pages cause a small bump that gets mostly reclaimed when the page closes. Some pages — a video, a leaky JavaScript framework, a page with a couple thousand DOM nodes — cause a bump that never gets reclaimed. Over hours and tens of thousands of renders, the resident set creeps. By hour 8 you're at 1.5GB. By hour 24 you're getting OOM-killed.

You can chase the leaks. Profile, diff snapshots, file Chromium bugs. Some of these are real bugs that get fixed. Others are by design — V8's garbage collector is not optimised for long-running, multi-tenant browser fleets.

Or you can preempt: every hour, kill the browser and start a fresh one.

async def maybe_restart(self):
    elapsed = time.monotonic() - self._last_restart
    if elapsed < self.restart_interval:
        return
    async with self._lock:
        if time.monotonic() - self._last_restart < self.restart_interval:
            return
        if self._browser:
            await self._browser.close()
        await self._launch_browser()

We call this from an hourly ARQ cron. The lock prevents two coroutines racing into a restart; the double-check inside the lock handles the case where one already won. A restart costs us about 800ms of latency on whichever request is unlucky enough to land during the swap — we accept it as the price of not paging an engineer.

If you can stomach a slightly more aggressive cadence (every 30 min, every 1000 renders), you can probably get away with a smaller container. We tuned to one hour because it's the sweet spot for our workload.

Fix 4 — A fresh `BrowserContext` per render, and close everything in `finally`

You are not just running renders. You are running other people's renders. Different tenants. Different cookies, different basic auth, different custom headers.

A BrowserContext is Playwright's isolation unit — its own cookies, storage, cache. If two tenants share a context, tenant A's session cookie can leak into tenant B's render. This is bad. You make a fresh context per render and you close it after:

async def _new_page(self, params):
    context_kwargs = {
        'viewport': params.get('viewport') or {'width': 1280, 'height': 720},
    }
    if params.get('headers'):
        context_kwargs['extra_http_headers'] = params['headers']
    if params.get('basic_auth'):
        context_kwargs['http_credentials'] = params['basic_auth']

    context = await self._browser.new_context(**context_kwargs)

    if params.get('cookies'):
        await context.add_cookies(params['cookies'])

    page = await context.new_page()
    return context, page

And on the consumer side — always in a finally block:

context, page = await self._new_page(params)
try:
    await self._navigate(page, params)
    return await asyncio.wait_for(
        page.screenshot(...),
        timeout=self.timeout_seconds,
    )
finally:
    await page.close()
    await context.close()

The asyncio.wait_for is a hard cap on render time — without it, a page can hang on networkidle indefinitely and tie up a semaphore slot. With it, we always close. Without it, a single slow page becomes a fleet outage.

Bonus: Chromium launch flags that actually matter

Most "performance flag" lists you'll find online are cargo-culted. Here's the short list that's been load-bearing for us:

_CHROMIUM_ARGS = [
    '--no-sandbox',
    '--disable-setuid-sandbox',
    '--disable-dev-shm-usage',  # use /tmp instead of /dev/shm
    '--disable-gpu',
    '--disable-extensions',
    '--disable-background-networking',
    '--mute-audio',
    '--hide-scrollbars',
]

The most important one is --disable-dev-shm-usage. By default Chromium uses /dev/shm for shared memory between processes; in a container, /dev/shm is typically tiny (64MB), and a busy renderer will OOM the moment it tries to allocate a large pixmap. Routing it to /tmp (which is just regular disk-backed memory) trades a small amount of latency for not crashing.

--no-sandbox and --disable-setuid-sandbox are required if you're running as a non-root user in Docker without the right capabilities. They're a downgrade in defense-in-depth — if you're rendering URLs supplied by your own tenants you should weigh whether to instead grant the container the right caps. For our threat model (tenants render their own URLs, not ours), the tradeoff is acceptable.

What I'd do differently

If I were starting again:

Cap viewport size aggressively at the schema layer, not in the renderer. We started lenient ("let people render at 4K!") and walked it back when one tenant's 8K full-page screenshot used 2GB of RSS for one render.
Track per-render memory, not just per-worker. A page that allocates 800MB before crashing should be killed and the tenant should see a clear error, not a generic 504. We added this later; should have been from day one.
Treat browser restarts as a SLO, not a coincidence. Once we started measuring "% of requests that landed during a restart," we could tune the cadence with data instead of hunches.

Closing

There's nothing magical here. One browser per worker, semaphore-capped concurrency, scheduled restarts, fresh contexts. The discipline is in actually doing all four; skipping any one of them eventually crashes a worker.

If you're running a screenshot API, a PDF generator, an HTML-to-image pipeline, or any other long-running headless-browser workload, the same pattern applies. If you'd rather not run any of this yourself, Rendershot is the API that comes out of the patterns above — free tier of 200 renders/month, no card required.

If you're sizing up screenshot/PDF APIs, I also wrote a structured comparison: Rendershot vs Urlbox: choosing a screenshot API in 2026