AUTHORIZED CAPTURE

Design a safe screenshot workflow for protected website content

Snapshot Site does not document arbitrary cookie or authorization-header injection on screenshot requests. Use an approved short-lived preview URL for content your service is allowed to expose, or keep interactive login capture in Playwright, Puppeteer, or a remote browser.

No key in URL
API auth stays in header
Short-lived access
Preview route pattern
Explicit boundary
No interactive login claim
Install:curl -X POST https://api.prod.ss.snapshot-site.com/api/v1/screenshot
Auth:SNAPSHOT_SITE_API_KEY
Get started for free
Authenticated Website Screenshot workflow
Snapshot Site themed illustration for authenticated website screenshot
Good fits
Internal applications that can issue signed preview URLs
Report pages designed for server-to-server rendering
Authorized staging environments with temporary access links
Teams separating interactive login from output capture

Private capture starts with an authorization design

The screenshot is sensitive data. The access mechanism, target validation, output storage, expiry, and audit trail matter as much as the rendering call.

1

Prefer purpose-built previews

Expose only the document required for capture, not a reusable authenticated application session.

2

Keep access short-lived

Use signed, scoped, expiring URLs when the application architecture supports them.

3

Protect the API key

Snapshot Site credentials stay in the outbound request header and never appear in browser code or target URLs.

4

Use automation when needed

Interactive MFA, login forms, session navigation, and role switching require a browser automation environment.

Implementation workflow

Build a reliable authenticated website screenshot job

1

Confirm authorization to capture and retain the content

2

Create a scoped expiring preview URL when supported

3

Send that URL from a trusted backend

4

Store the artifact with restricted access and retention

Authenticated Website Screenshot example

Example

Start a authenticated website screenshot request

Keep credentials server-side, check the response, and persist the returned asset only after validation.

const previewUrl = await createSignedPreviewUrl({
  reportId: "report_123",
  expiresInSeconds: 120,
  audience: "snapshot-render",
});

const response = await fetch(
  "https://api.prod.ss.snapshot-site.com/api/v1/screenshot",
  {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "x-snapshotsiteapi-key": process.env.SNAPSHOT_SITE_API_KEY,
    },
    body: JSON.stringify({
      url: previewUrl,
      format: "pdf",
      width: 1440,
      hideCookie: true,
    }),
  },
);

Authenticated Website Screenshot: define the result before the browser

Authenticated website screenshot and screenshot behind login describe a security problem before they describe a rendering problem. A screenshot service needs a reachable page state, while the application must prevent that access path from becoming a reusable link to private data.

Snapshot Site does not document general cookie injection, arbitrary target Authorization headers, or an interactive login sequence. An architecture should not invent those capabilities. Two honest patterns remain: issue a purpose-built short-lived preview URL, or use a programmable browser inside an authorized environment.

A preview route is appropriate when the application controls the content and can render one scoped document from a signed token. Browser automation is appropriate when the state can only be reached through login, MFA, role selection, or several interactive steps.

A production workflow

The screenshot is sensitive data. The access mechanism, target validation, output storage, expiry, and audit trail matter as much as the rendering call. A useful implementation separates request creation, browser work, result validation, storage, and downstream review. That separation makes failures observable and prevents a rendering option from becoming undocumented business logic.

  1. Confirm authorization to capture and retain the content.
  2. Create a scoped expiring preview URL when supported.
  3. Send that URL from a trusted backend.
  4. Store the artifact with restricted access and retention.

For private-page evidence, store the application record, access method, token expiry, viewport, capture settings, and timestamp without persisting reusable credentials. Reviewers need provenance, not a copied authentication secret.

Controls that determine the output

Scope

A preview token should authorize one document or narrow resource set, not the entire account area.

Expiry and replay

Keep lifetime short, record issuance and use, and decide whether a token may be used more than once.

Output sensitivity

Generated screenshots and PDFs inherit the sensitivity of the source page. Restrict storage, sharing, logs, and retention accordingly.

Auditability

Record who requested the capture, which source was authorized, when it ran, and where the result was stored.

Security and product boundary

Do not bypass access controls, CAPTCHA, MFA, robots policy, or contractual restrictions. Capture only content your organization is authorized to process, and use a browser automation environment when the page cannot be exposed safely by URL.

Authorize the capture before minting a preview, limit the signed state to one purpose and short lifetime, and redact it from shared diagnostics. Restrict the generated screenshot at least as tightly as the account page or report it represents.

Production checklist

  • Document the legal and product authorization.
  • Use a scoped expiring preview where possible.
  • Keep both API and preview secrets out of logs.
  • Restrict generated asset access.
  • Delete temporary previews and artifacts on schedule.

Review screenshot API authentication for the service boundary, the Playwright guide for interactive login, and pricing after defining the authorized capture volume.

Authenticated Website Screenshot FAQ

Can Snapshot Site submit my login form?

No interactive login workflow is documented. Use browser automation for form submission, MFA, redirects, and session navigation.

Can I send cookies or Authorization headers for the target page?

The public screenshot request documentation does not expose arbitrary target cookie or header injection. Do not assume unsupported authentication behavior.

What is a signed preview URL?

It is an application-owned, scoped, expiring URL that renders only the approved document. Its authorization rules must be implemented and audited by your application.

Is it safe to place the Snapshot Site API key in the preview URL?

No. The API key belongs only in the x-snapshotsiteapi-key request header sent from a trusted backend.

What is a Authenticated Website Screenshot?

Capture authorized private content through secure preview URLs and controlled browser workflows. Understand when Snapshot Site fits and when interactive login automation is required.

Which Snapshot Site endpoint should I use for authenticated website screenshot?

Use /api/v1/screenshot for basic capture, /api/v2/screenshot for advanced preparation, /api/v3/analyze for rendered-page analysis, or /api/v3/compare for before-and-after visual comparison.

Does authenticated website screenshot work with dynamic pages?

A managed browser renders JavaScript. Use the smallest reliable delay or documented DOM readiness controls when meaningful content appears after initial navigation.

How should I protect the Snapshot Site API key?

Keep it in server-side environment or secret management and send it only through the x-snapshotsiteapi-key header. Never expose it in public client code.

Related resources

Snapshot Site HomeWebsite Screenshot APIScreenshot Behind Login TutorialBrowser Automation APIScreenshot API AuthenticationTypeScript SDKAPI DocumentationPricing

Test one authenticated website screenshot workflow

Start with a representative authorized URL, preserve the request settings, and review the output before expanding volume.

Get started for freeRead the API docs