Move the screenshot call. Keep the browser work.

Start with the boundary

Separate screenshot transport from browser automation.

Browserless exposes a browser platform. Latchshot exposes a guarded render endpoint. The contracts overlap for a direct public-URL screenshot, but not for arbitrary browser execution. Inventory the current request body before changing providers.

Move the token out of the endpoint URL.

Browserless commonly authenticates its REST endpoint with a query token. Latchshot requires the key in an HTTPS Bearer header. Keep both credentials server-side and never place either one in browser code, logs, a target URL, or a public issue.

Before: Browserless Screenshot API

curl -fSL \
  "https://production-sfo.browserless.io/screenshot?token=$BROWSERLESS_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://example.com",
    "options": {
      "type": "jpeg",
      "quality": 80,
      "fullPage": true
    },
    "viewport": { "width": 1440, "height": 900 },
    "gotoOptions": { "waitUntil": "networkidle0", "timeout": 15000 },
    "waitForTimeout": 1000
  }' \
  -o before.jpg

After: Latchshot render endpoint

curl -fSL \
  'https://latchshot.fly.dev/v1/render' \
  -H "Authorization: Bearer $LATCHSHOT_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://example.com",
    "kind": "screenshot",
    "format": "jpeg",
    "quality": 80,
    "width": 1440,
    "height": 900,
    "fullPage": true,
    "scrollPage": true,
    "waitUntil": "networkidle",
    "timeout": 15000,
    "delay": 1000
  }' \
  -o after.jpg

Both examples return the image directly. If the surrounding code converts the Browserless response to a buffer, base64 string, object-store upload, or application artifact, keep that ownership step unchanged.

Map the intersection, not the whole browser API.

Start with the smallest known-good screenshot request. Add only the controls your output requires, then compare representative pages at identical viewport and output settings.

On a narrow screen, scroll the option table horizontally.

Stop when the request needs a browser primitive.

Latchshot has no equivalent for these Browserless capabilities. Removing one can change the image, expose data, or break the surrounding workflow.

• Alternate input: inline html, local files, data URLs, or application content that is not already available as a permitted public URL.
• Browser sessions: CDP, Puppeteer, Playwright, reconnectable sessions, BrowserQL, or custom function execution.
• Page state: cookies, arbitrary headers, login state, authenticated pages, request interception, or application secrets supplied to the target.
• Page actions: injected JavaScript or CSS, clicks, typing, custom, element-directed, or multi-step scrolling, selectors, element screenshots, or clip coordinates.
• Network placement: private hosts, non-standard target ports, proxy selection, region-specific browser endpoints, or geolocation.
• Browserless workflows: downloads, content extraction, performance APIs, provider-side caching, and non-screenshot REST endpoints.

Keep Browserless for those jobs. Route only the proven public-URL screenshot subset to Latchshot; a split-provider architecture is safer than silently degrading the output.

Cut over by capability, then by traffic.

1. Log the option names—not secret values—present in current Browserless screenshot calls. Keep every request that hits the stop list on Browserless.
2. Create a representative public-page sample: ordinary, slow, font-heavy, animated, consent-overlay, tall, persistent-connection, and known-failure targets.
3. Render both providers at the same viewport, format, quality, lifecycle wait, and delay. Compare dimensions, visible content, fonts, lazy content, bytes, and latency.
4. Keep application-owned base64 conversion, storage, CDN, or downstream attachment logic unchanged. Store Latchshot's render, navigation, scroll, font, script, and quota headers with job diagnostics.
5. Route a bounded percentage of eligible jobs to Latchshot. Exercise rollback before removing the Browserless credential or code path.

Retry only 429, 502, 503, and 504, with a strict attempt cap inside the caller's deadline. Treat 400, 401, 403, and target-policy failures as permanent until the request changes.

Compare the eligible slice, not platform headline prices.

Latchshot counts successful direct renders. Failed direct renders do not consume monthly quota, and automatic overages are disabled during the beta. The current plans are Free at 100 successful renders each UTC month, Launch at $19 for 2,500, Build at $49 for 12,000, and Scale at $149 for 50,000.

Those prices do not prove a saving. Include Browserless jobs that cannot migrate, regional or concurrency needs, storage and transfer, retry volume, integration work, and the value of browser primitives on the stop list.

Model only the eligible slice. Use your successful monthly volume, avoidable provider spend, and supported-workload share in the browser-local cost and migration fit calculator. Inputs and results stay in your browser; the output is an estimate, not a quote or savings guarantee.

Create one Free-plan key, save it when it is returned, and spend the 100 monthly successful renders on a representative comparison set.