Can Screenshotlayer Capture Pages Behind a Login? Setup Options and Limits

Can Screenshotlayer capture pages behind a login? The public Screenshotlayer documentation reviewed for this guide does not confirm that you can provide target-site cookies, a session token, or an Authorization header. Its access key authenticates your request to Screenshotlayer; it does not log the screenshot service into the website you want to capture.

Screenshotlayer does document URL-based captures and controls such as viewport size, full-page output, format, User-Agent, Accept-Language, capture delay, and cache TTL. Those controls can affect rendering, but they do not establish an authenticated session. If your workflow depends on a login, ask Screenshotlayer support whether cookie or session injection is currently supported and how credentials are handled before building around it. Screenshotlayer is a remote capture API in the reviewed public material, not a documented browser automation workflow. Its FAQ confirms User-Agent and Accept-Language customization; it does not document target-site cookies or arbitrary Authorization headers.

What “behind a login” means for a screenshot API

A page that is publicly accessible can usually be requested by URL. A page behind a login typically requires browser state such as a session cookie, a bearer token, or an interactive login flow. The capture service needs access to that state in the browser or request it uses to load the page.

Keep these two credentials separate:

• Screenshotlayer access key: identifies and authorizes your caller with Screenshotlayer.
• Target-site session: proves to the website that the capture request belongs to an authenticated user.

Providing a custom User-Agent or language header does not create the target-site session. Do not put passwords, cookies, or live session tokens in a URL. URLs can be retained in logs, browser history, proxy records, or analytics systems.

What Screenshotlayer’s public documentation confirms

Capability	What the reviewed public material says	Relevance to login capture
Target URL and access key	The request uses an access key and target URL.	The access key is for Screenshotlayer, not the target website.
User-Agent and Accept-Language	The FAQ confirms custom values for both.	These can influence content selection, but do not authenticate a user.
Cookies, session tokens, Authorization	The reviewed FAQ does not document supplying these.	Support is unresolved; do not assume it works.
Capture delay	A configurable delay is documented.	May allow a public page more time to render; it cannot replace login state.
Cache TTL	The stated default is 2,592,000 seconds (30 days); custom TTL values below that default are documented.	For changing or private content, understand cache behavior before relying on a capture as current.
Output and page controls	The FAQ describes PNG, JPEG, and GIF; the product page describes viewport and full-page controls.	These affect the output, not whether a login succeeds.

Screenshotlayer’s homepage also describes options such as custom CSS, URL encryption, forced refresh, thumbnails, and export to AWS S3 or FTP. Confirm exact parameter names and current behavior in its interactive documentation before using those options. None of these published controls, by itself, establishes that an authenticated target session can be supplied. Check the current documentation and contact support for the unresolved session question. Check live pricing before purchase; allowances and prices can change.

How to evaluate a logged-in capture workflow

1. Identify the authentication mechanism. Is access based on a browser cookie, an Authorization header, a one-time code, an interactive SSO flow, or a client certificate? Document only what your site actually uses.
2. Ask Screenshotlayer support directly. Ask whether the current service accepts the required cookie or credential mechanism, whether it follows redirects after authentication, and how credentials are protected, retained, and excluded from logs.
3. Request a safe test procedure. Use a non-production account and a page with no sensitive data. Ask how to verify that the returned image is the authenticated page rather than a login screen.
4. Check cache semantics. Screenshotlayer’s FAQ states that the default cache TTL is 2,592,000 seconds (30 days), and says a custom TTL can be set lower than that. Ask how cache keys and refresh behavior work for authenticated content before capturing it.
5. Compare the workflow against your requirements. Confirm session support, permitted headers or browser state, redirects, rendering delay, cache behavior, output controls, concurrency, volume, export needs, and commercial terms.

Do not send a production session token to a service until you have a clear answer about transport security, storage, logging, cache isolation, expiration, and revocation. A successful capture of a public URL is not evidence that a private page can be captured safely.

DIY option: use a browser session you control

If the provider does not support the required session mechanism, a browser automation workflow gives your code control over the login and capture steps. Keep it inside an environment you control, store credentials in a secret manager, and follow the target site’s access rules. The example below uses Playwright for Node.js. It assumes you already have an authorized way to authenticate; the selectors and login steps must be adapted to your site.

npm install playwright
npx playwright install chromium

// capture.mjs
import { chromium } from 'playwright';

const browser = await chromium.launch({ headless: true });
const context = await browser.newContext({
  // Prefer a secret manager or environment variables for credentials.
  // Set storageState to a protected, previously authenticated state file
  // only if your organization permits storing and reusing that session.
});
const page = await context.newPage();

try {
  await page.goto('https://example.com/login', {
    waitUntil: 'domcontentloaded',
    timeout: 30_000,
  });

  // Replace these steps with the site's approved authentication flow.
  // Never hard-code a real password or session token in source control.
  await page.locator('input[name="username"]').fill(process.env.SITE_USER ?? '');
  await page.locator('input[name="password"]').fill(process.env.SITE_PASSWORD ?? '');
  await page.locator('button[type="submit"]').click();

  // Wait for a stable, authenticated page-specific element.
  await page.locator('[data-testid="account-home"]').waitFor({ timeout: 20_000 });
  await page.goto('https://example.com/account/report', {
    waitUntil: 'domcontentloaded',
    timeout: 30_000,
  });
  await page.locator('main').waitFor({ timeout: 20_000 });
  await page.screenshot({ path: 'account-report.png', fullPage: true });
} finally {
  await context.close();
  await browser.close();
}

Run it with credentials supplied by your environment or secret manager, for example SITE_USER and SITE_PASSWORD. The placeholder selectors are site-specific. Some identity providers prohibit scripted login or require MFA; in that case, use an approved service account, supported SSO flow, or a pre-authenticated browser state managed securely. Do not bypass access controls.

Use a saved browser state when the site permits it

Playwright can save and reuse authenticated browser state. Treat that state file like a password: it may contain cookies and tokens that grant account access. Keep it out of source control, restrict file permissions, encrypt it at rest, rotate it when access changes, and never share it between unrelated users or tenants.

// After completing an approved login flow:
await context.storageState({ path: 'private/auth-state.json' });

// Later, create a context with that state:
const authenticatedContext = await browser.newContext({
  storageState: 'private/auth-state.json',
});

Or skip the browser setup

For pages your chosen capture approach can access, ScreenshotNeo offers a one-request screenshot API and an MCP server for AI agents. Its clean-shot flow accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response identifies the page verdict and billing status in headers. The MCP server includes take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. For a login-gated page, confirm the needed access method against the ScreenshotNeo API documentation before sending private credentials.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo’s free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. See ScreenshotNeo and sign up for 1,000 free screenshots a month, no card required.

Troubleshooting

Symptom	Likely cause	What to do
The screenshot shows a login page	The target request did not have a valid authenticated session, or the session expired.	Confirm session injection is supported. If using your own browser automation, verify login completion before navigating to the protected page.
A custom User-Agent changes the page, but access is still denied	User-Agent affects how a site serves content; it does not authenticate the request.	Use a supported session mechanism or an authorized browser flow. Ask the API provider about cookie/header support.
The page is blank or incomplete	The page may render asynchronously, require a client-side route, or depend on a login redirect.	For documented delay controls, tune the delay for public pages. In browser automation, wait for a page-specific selector instead of a fixed sleep.
A screenshot looks stale	A cached capture may be returned. Screenshotlayer’s FAQ states a default TTL of 30 days.	Confirm current cache controls, use an allowed shorter TTL or refresh option if available, and verify how authenticated content is isolated in cache.
Automation times out waiting for an account selector	Login failed, MFA is pending, the selector changed, or the page has not completed its transition.	Inspect the page in a controlled environment, verify the selector, and use an approved MFA or service-account workflow.
Saved state works locally but fails in deployment	Cookies may expire, be bound to an IP/device, or be absent from the deployed state file.	Regenerate state using the approved process, secure it as a secret, and check whether the identity provider permits reuse in that environment.
Credentials appear in logs or request history	Secrets were placed in a URL, command history, or verbose logs.	Revoke exposed credentials, remove them from logs where possible, and pass secrets through protected environment/configuration channels.

Performance, reliability, and cost considerations

• Wait for the right condition. A long fixed delay increases capture time and still may miss content. Prefer a page-specific readiness condition in browser automation. Use the API’s documented delay only when it fits the page behavior.
• Account for cache age. The documented 30-day default TTL can be unsuitable for rapidly changing account data. Confirm refresh and TTL behavior and whether authenticated responses are isolated per user.
• Plan for session expiration. Sessions may expire or be revoked, and MFA or SSO policies may change. Treat reauthentication as a normal failure path and alert on login-page captures.
• Protect data and access. Screenshots of account pages can contain personal or business data. Limit retention, restrict access, and ensure the account used for capture has only the permissions it needs.
• Estimate total operating cost. For an API, compare monthly snapshot limits, concurrency, export needs, and current plan terms. For a self-managed browser, account for compute, browser updates, retries, storage, and maintenance. Check live pricing rather than relying on a cached plan table.

FAQ

Does a Screenshotlayer API key log into my website?

No. The access key authenticates your caller to Screenshotlayer. The target site requires its own authenticated session.

Can I pass cookies or an Authorization header to Screenshotlayer?

The public documentation reviewed here does not confirm either capability. Ask Screenshotlayer support for current, explicit confirmation before relying on it.

Will User-Agent or Accept-Language make a private page accessible?

No. Those values can affect content negotiation or rendering, but they do not prove your identity to the target site.

Can I use a screenshot API for confidential account pages?

Only after confirming session support, credential handling, cache isolation, retention, and your organization’s policies with the provider.

Does a longer delay fix a login problem?

No. A delay can give a page more time to render; it cannot supply missing credentials or satisfy an interactive authentication requirement.