How to Take a Screenshot of a Website That Requires Login with ScreenshotAPI.net

To take a screenshot of a website that requires login with ScreenshotAPI.net, the capture browser must receive authentication the target site accepts. The practical options are to pass a valid browser session in the cookies parameter or supply custom headers if the site supports header-based authentication. There is no universal login method: a username and password in a screenshot request are not guaranteed to sign in to a site.

Use this only for accounts and pages you are authorized to access. Before capturing, identify how the target site authenticates you, then check that the returned image shows the protected page rather than a login screen.

1. Identify how the target site authenticates you

Sign in to the target site in a browser and determine whether it maintains your session with cookies or expects an authorization header. A protected-page screenshot works only when the capture request supplies state the site accepts.

• Cookie-based session: after sign-in, the browser sends one or more session cookies with requests to the site. Reuse the current cookies if the capture service accepts them.
• Header-based authentication: an API or application may accept a token such as Authorization: Bearer …. Use a custom header only when the target site’s documented flow accepts it.
• Interactive or changing login: a site may require a challenge, a changing token, or an interaction that cannot be represented by a reusable cookie or header. Support depends on the target’s implementation; do not assume the screenshot service can complete every login flow.

ScreenshotAPI.net’s help material cautions that authentication varies by site. Its documented approaches include cookies and custom headers, but those mechanisms do not establish universal compatibility. See the [ScreenshotAPI.net help page](https://www.screenshotapi.net/help) and [browser emulation documentation](https://screenshotapi.net/docs/renderScreenshot/emulation).

2. Capture with session cookies

For a site that uses a browser session, the usual workflow is to sign in with an account you are allowed to use, export the active cookies, and pass them to ScreenshotAPI.net with the screenshot request. Its feature page also describes saving cookies as a named Cookie Template and referring to it with template_id.

1. Sign in to the target site in your browser.
2. Export the cookies for the target site, making sure the export format is supported by the current ScreenshotAPI.net API documentation.
3. Pass those cookies in the request’s cookies parameter, or save them in a Cookie Template and use its template_id.
4. Open the resulting screenshot and confirm it shows the authenticated page.

Cookie exports are sensitive credentials. Keep them out of source control, public URLs, browser-visible code, and logs. Store reusable values in an appropriate secret store and replace them when the session expires. The exact cookie object format and parameter encoding can change, so follow the current [ScreenshotAPI.net cookie and template documentation](https://www.screenshotapi.net/features) rather than relying on an old copied payload.

3. Use custom headers when the target accepts them

If the target’s documented authentication flow accepts an authorization token in a request header, configure ScreenshotAPI.net’s custom headers for the capture. Its emulation documentation gives Authorization: Bearer TOKEN as an example of a custom header. This method applies to services that actually accept that header; adding one does not turn a normal interactive website into an authenticated session.

Compare the two methods against the target’s requirements:

Method	Use it when	What to maintain
Session cookies	The browser remains signed in through cookies.	Correct domain and cookie format; refresh cookies after expiry or sign-out. A saved template can avoid repeating setup for reusable sessions.
Custom headers	The target accepts a token or other authentication header.	A valid token and the exact header expected by the target; rotate or refresh it according to the target’s rules.

The vendor documentation describes both mechanisms; it does not establish that one is universally more secure or reliable. Choose based on the target site’s documented authentication design.

4. Wait for the authenticated page to finish rendering

Authentication and rendering readiness are separate. If the capture shows the correct page but content is missing, the page may still be loading client-side data or waiting on an asynchronous request. ScreenshotAPI.net documents a fixed delay, a wait_for_selector, and wait_for_event=networkidle as readiness controls. Use the narrowest condition that matches the page:

• Wait for a selector that appears only after the protected content is ready.
• Use a short delay for a known animation or delayed update.
• Use network idle when the page makes a finite set of asynchronous requests; persistent polling can make network-idle unsuitable.

If the screenshot is still a login page or blank shell, first verify that the authentication state was accepted. A longer wait cannot repair invalid or missing credentials.

5. Troubleshoot common results

Result	Likely cause	What to check
Screenshot shows the login page	The session was not accepted, or the required authentication mechanism was not supplied.	Confirm the cookies belong to the target domain, are current, and include all cookies required by that session. If the site expects a header, use its documented header flow instead.
Cookie parameter is rejected or ignored	The exported data may not match the service’s accepted structure or encoding.	Check the current ScreenshotAPI.net parameter documentation. Some browser exports are already structured; manually copied cookie values may need conversion.
It worked earlier, then returned to login	Session cookies or tokens can expire or be revoked.	Refresh the authorized session and update the request or Cookie Template. Do not treat a saved template as a permanent login.
Protected page is present but incomplete	Client-side rendering or asynchronous content was not ready at capture time.	Wait for a meaningful content selector, use a suitable delay, or try network idle where the page’s request behavior permits it.
Challenge, changing token, or extra interactive step appears	The target’s authentication flow requires site-specific interaction beyond the documented cookie or header setup.	Check the target’s permitted integration options and ScreenshotAPI.net’s current documentation. The cited material does not promise universal support for these flows.
Page content differs by region	Routing or site behavior may vary by region; possessing valid credentials is a separate issue.	Review the service’s documented proxy and emulation options. Regional routing does not replace a valid session or token.

These checks follow from the documented cookie and header methods. They are troubleshooting guidance, not a compatibility guarantee for every website.

6. Keep capture requests reliable and controlled

• Limit session exposure: send only the cookies or headers the capture needs. Treat them like passwords and avoid putting secrets in a URL that may be logged or copied.
• Plan for expiry: authenticated sessions are not necessarily permanent. A reusable Cookie Template reduces repeated setup, but the underlying session may still need renewal.
• Make readiness explicit: a selector tied to the actual protected content is easier to reason about than an arbitrary long delay. Allow for pages whose requests never become idle.
• Check the output: verify the image after changing credentials, templates, or timing settings. A successful capture request alone does not prove the target accepted authentication.
• Estimate service cost from current terms: the cited ScreenshotAPI.net research does not establish current prices, billing behavior, or a cost comparison. Check its current plan and billing documentation before estimating production usage.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Its clean-shot flow accepts cookie and consent banners as a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and responses identify the page verdict and billing status in headers. AI agents can use its MCP server tools: take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 shots a month with no card; paid plans start at $5 for 3,000 shots, and every feature is available on every plan. See the [ScreenshotNeo API documentation](https://screenshotneo.com/docs/).

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}`);

These examples capture a public URL. For an authenticated target, configure the cookies or headers supported by the chosen service and verify the resulting page. ScreenshotNeo documents its full options in the [API docs](https://screenshotneo.com/docs/). [Create a free ScreenshotNeo account](https://screenshotneo.com/account/sign-up/) for 1,000 screenshots a month with no card.

FAQ

Can I just send the site’s username and password?

The cited ScreenshotAPI.net material focuses on reusing authenticated cookies or supplying custom headers. It does not establish a general username-and-password login parameter.

Can every login-protected website be captured?

No universal compatibility is documented. The target must accept the supplied session or header, and some flows require site-specific interactive steps.

Should I save cookies in a template?

A Cookie Template can make repeated requests easier to configure. It does not prevent the underlying session from expiring, and its cookie data should be handled as a secret.

Does waiting longer fix a failed login?

No. Timing controls help when authenticated content is still rendering. They do not make invalid or missing authentication state valid.

Sources

• ScreenshotAPI.net features: cookie injection, Cookie Templates, and parameter documentation links.
• ScreenshotAPI.net help: authenticated-page questions and site-specific authentication caveat.
• ScreenshotAPI.net guide to pages behind a login: cookie export and template workflow.
• ScreenshotAPI.net browser emulation docs: custom headers and related emulation options.
• ScreenshotAPI.net homepage: Chromium rendering and readiness controls.