Every client website handoff eventually reaches the same awkward question: “Which version did we approve?” A Slack message saying “looks good” may not identify what the site looked like at the time, and after a later edit the old approval can be hard to verify.
I built Capture Signoff to make that handoff more checkable. You submit public URLs; it captures desktop and mobile evidence, creates a proof pack with a capture manifest, and can issue a no-login review link for per-page approval or change requests. The review page is printable from the browser. It is not a legal signature service, and it does not generate or store a PDF receipt.
The system shape
One Cloudflare Worker serves the static site and JSON API. D1 stores workflow state and references to evidence; R2 stores the signed capture manifests and screenshot artifacts. Queue consumers handle capture work away from the request path, while scheduled recovery checks for stalled jobs.
The public workflow only accepts pages an anonymous visitor can reach. Before rendering, the server validates the target and follows redirects while rejecting private or non-public destinations. It does not log into sites or bypass a target page’s CAPTCHA.
Capturing a page
For each page, the Browser Rendering binding produces a full-page desktop snapshot with HTML content, a desktop viewport screenshot, and a full-page mobile screenshot. The rendered HTML is hashed and represented in the manifest alongside the final URL, redirect chain, timestamp, and technical observations.
The separate viewport and mobile captures are deliberate. A single full-page screenshot is useful evidence, but it does not tell you how the same page appeared in a normal desktop viewport or on a narrow device. Browser time is read from the rendering responses and counted toward the beta budget rather than estimated from wall-clock time.
Why serialize the browser work?
My first version tried to run all captures in parallel. That made the flow harder to reason about when the browser service returned transient failures. The queue consumer now runs one capture job at a time, retries a bounded number of times, and attaches failed jobs to a dead-letter queue. A scheduled sweep recovers stalled work.
That is a latency trade-off. For a small beta with strict daily capacity limits, predictable cost matters more than peak throughput. The current public proof flow is protected by Turnstile, a per-address rate limit, three proof runs per visitor per UTC day, and shared caps of 20 pages and eight browser-minutes per day. Those limits are real product constraints, not performance claims.
A narrow tamper-evident record
The manifest artifact lives in R2; D1 holds related hashes and workflow records. The current audit-event hash chain is intentionally narrower than a full event ledger: it covers review decisions (and initial beta-access creation), not every capture, artifact write, or receipt lifecycle event. A review decision is tied to that page’s manifest hash and linked to the preceding decision for the same subject.
That does not make the output a blockchain, electronic signature, or independently verified legal record. It is a limited tamper-evident aid for checking a decision against the captured evidence. The free workspace has a seven-day retention period, so this is a handoff workflow, not archival storage.
Re-approve only what changed
When a project is captured again, the page evidence is compared with the prior version. Unchanged pages can carry their approval forward; changed pages return to review. A price page can be re-approved without asking the client to review an unchanged About page again.
You can inspect a three-page sample to see the changed-page flow. The developer documentation describes the API contract and examples. API-key access is currently a pilot request rather than open self-serve access.
I’m interested in feedback from people who build screenshot pipelines or hand off client websites: where would serial capture become a bottleneck, and what evidence do you actually need before you consider a page approved?
Top comments (0)