What Latchshot processes—and what it keeps.

The renderer needs a public URL, Free-plan access needs an email, and owner-reviewed service requests need limited public scope details. This page maps those inputs to the service's current processing, storage, logging, and retention behavior.

Current private-beta behavior · Updated July 21, 2026

A render is transient by default.

Each job starts an isolated Chromium browser and context, processes one public target, returns the artifact, and closes that browser. Latchshot does not provide artifact storage or a page archive.

Input or outputCurrent handlingPersistent service record
Target URL and render optionsHeld in application memory for validation, navigation, and capture.The full URL is not written to the customer database. A failed render can log the target hostname, error code/name, and URL-stripped error text.
Page content and subresourcesLoaded inside the isolated browser through public-network guards.No page content, cookies, or browser profile is intentionally retained after the job closes.
PNG, JPEG, or PDF artifactHeld in memory and streamed in the HTTPS response.The artifact is not written to Latchshot storage. The customer's monthly record keeps aggregate output bytes and render time.
Bearer API keyAuthenticated before a metered render or usage request.Only a SHA-256 hash and short identifying prefix are stored. The plaintext key is returned once and is not forwarded to the target page.
Public pages only.

Do not put passwords, API keys, session tokens, customer data, or signed private-resource credentials in a target URL. Latchshot rejects URL-embedded credentials but cannot decide whether other path or query data is sensitive.

The managed visual-monitoring pilot is a separate owner-confirmed service boundary. Sending its fit request captures no page. Before an accepted pilot starts, the owner and requester agree the exact public pages, private delivery location, access method, and rolling 30-day artifact retention; ordinary API renders remain transient.

Access records operate keys and owner replies.

An email is required to enforce one Free-plan key per address and attach the recurring allowance. Implementation-pilot and screenshot-safety-review requests separately require an email and explicit reply consent because the owner must review their public scope.

  • The access record stores the email, submitted workflow context, expected-volume band, contact-permission choice, status, and timestamps.
  • The key record stores the email, plan, key hash and prefix, quota and rate limits, enabled state, creation/last-use/activation timestamps, and monthly success/failure/byte/time aggregates.
  • Unchecked product-fit permission means the email is not an invitation for product-guidance outreach. A later paid-plan request requires a new explicit contact-consent checkbox.
  • A pilot request stores the email, exact public GitHub repository, reply consent, acknowledgment timestamp, review status, and record timestamps. Optional call-site, provider, language, request/output behavior, required behavior, expected-volume, and public acceptance-sample fields store either the submitted non-secret detail or a conservative “not provided”/“not sure” placeholder.
  • The no-account pilot form requires repository authority, public-request safety, and owner-confirmed payment/start acknowledgments. It does not collect repository credentials, take payment, issue a key, reserve work, or authorize a code change.
  • A screenshot-safety-review request stores the email, exact public GitHub repository, one route path, language, runtime, primary concern, submitted current controls, test evidence, desired outcome, reply consent, acknowledgment timestamp, review status, and record timestamps.
  • The no-account safety-review form requires repository authority, public-request safety, and owner-confirmed payment/start acknowledgments. It does not collect private source or repository credentials, take payment, reserve work, grant access, or authorize a code change.
  • A visual-monitoring fit request stores the email, one exact public page URL without credentials, query data, or a fragment, the page-count band, monitoring goal, optional weekly-note context or a conservative “not provided” placeholder, reply consent, acknowledgment timestamp, review status, and record timestamps.
  • The monitoring request requires public-page authority, public-request safety, and owner-confirmed payment/start acknowledgments. It does not collect private-page access, take payment, create a subscription, reserve capacity, or begin a capture schedule.
  • An upgrade request stores the requested plan, optional note, status, timestamps, and associated key ID. Latchshot does not collect a card number, bank account, wallet key, or payment credential.

Measurement stays aggregate.

First-party acquisition measurement stores one daily count per fixed event and coarse source. It does not build visitor profiles.

  • Stored page and funnel data is limited to the UTC day, fixed event name, coarse source category, count, and last-update timestamp.
  • The source classifier may read a request's user agent and referrer, then reduces them to categories such as direct, search, community, referral, bot, or automated. The raw values are not written to the analytics table.
  • Analytics does not store IP addresses, target URLs, cookies, client IDs, individual navigation histories, or render artifacts.
  • The screenshot endpoint safety check evaluates its seven answers and builds its plain-text handoff entirely in the browser. It sends and stores none of those answers or the generated result; loading the page still contributes only the aggregate page-view record described above.
  • The screenshot API cost calculator evaluates monthly volume, avoidable cost, supported share, plan fit, and the generated estimate entirely in the browser. It sends and stores none of those inputs or results; loading the page still contributes only the aggregate page-view record described above.
  • Client IP addresses are used in process memory for fixed-window demo, Free-key, and API rate limits. Expired limiter identities are pruned during later limiter activity and are never written to the customer database.

The target site still receives browser traffic.

A screenshot is a real browser visit. The target and its public subresources receive requests from the Latchshot rendering environment and may apply their own logs, cookies, analytics, terms, or retention. Latchshot blocks service workers and media requests, disables downloads, and does not add a customer API key to browser traffic.

The public website is hosted on Fly.io and loads the Anybody and Chivo web fonts from Google Fonts. The API itself does not require those browser-facing font requests. GitHub hosts the public contract, issue tracker, and private security-report route.

Private-beta account records do not auto-expire.

Access, pilot-request, safety-review-request, monitoring-request, key, usage, and upgrade records currently remain on the encrypted production volume for account continuity, owner review, quota accounting, abuse control, and an auditable owner workflow. An active monitoring pilot retains its capture artifacts for the agreed rolling 30 days in the separately agreed private delivery location. Revocation disables a key but preserves its record; there is no automatic customer-record deletion schedule for the other private-beta records.

If that retention boundary does not fit the workflow, use the no-signup live demo for evaluation and do not request a key. Store returned artifacts in a system whose retention and deletion controls meet the workflow's requirements.

Report a contract mismatch without exposing data.

Use the public contract issue tracker for a non-sensitive behavior or documentation problem. Use GitHub's private security report for a vulnerability. Never include an API key, private or signed URL, authorization header, customer data, or captured private artifact.

This page documents the implementation currently running in private beta. A material behavior change must update this page and its date before it is represented as current.

Check the exact API boundary.

Review supported targets, response diagnostics, quotas, and the public OpenAPI contract before integrating.

Read the API reference