How to capture a page that requires login with ApiFlash

To capture a page that requires login with ApiFlash, first identify how the target authenticates. Pass a token in request headers, pass an already valid session cookie in the cookies parameter, or automate the login with injected JavaScript if the page’s flow supports it. If you control the target site, a deliberately designed secure capture bypass may also work. ApiFlash’s own guidance says the right approach depends on the authentication mechanism. [ApiFlash FAQ]

ApiFlash’s key authenticates your request to ApiFlash; it is separate from the credentials or session data that authenticate the browser to the target site. The examples below use placeholder secrets. Keep real credentials on a server you control.

1. Choose the authentication method

Target authentication	ApiFlash approach	What you need
Bearer token or another request header	headers	A valid token and the exact header format expected by the site
Session login	cookies	A valid session cookie obtained after signing in normally
Interactive login form that can be automated	Injected JavaScript	Page-specific login automation and a way to provide credentials securely
Site you operate	A purpose-built secure bypass, if appropriate	A secret or signed mechanism with limited scope and lifetime

Do not assume one method works for every site. Multi-factor prompts, single sign-on redirects, bot checks, rotating sessions, or client-side application state can make a login flow unsuitable for simple automation.

2. Capture with a session cookie

For a cookie-authenticated page, sign in through the normal route first and obtain the cookie values the target needs. ApiFlash documents cookies as semicolon-separated name-value pairs. URL-encode the value when placing it in a GET query string. A session cookie is a bearer credential: anyone who obtains it may be able to use the session until it expires or is revoked.

Replace the placeholders below. The target URL must include https:// or http://.

cURL

curl -G 'https://api.apiflash.com/v1/urltoimage' \
  --data-urlencode 'access_key=YOUR_APIFLASH_ACCESS_KEY' \
  --data-urlencode 'url=https://example.com/account' \
  --data-urlencode 'cookies=session=YOUR_SESSION_VALUE' \
  --data-urlencode 'format=png' \
  --output account.png

Python

import requests

response = requests.get(
    "https://api.apiflash.com/v1/urltoimage",
    params={
        "access_key": "YOUR_APIFLASH_ACCESS_KEY",
        "url": "https://example.com/account",
        "cookies": "session=YOUR_SESSION_VALUE",
        "format": "png",
    },
    timeout=90,
)
response.raise_for_status()
with open("account.png", "wb") as image:
    image.write(response.content)

Node.js

const params = new URLSearchParams({
  access_key: process.env.APIFLASH_ACCESS_KEY,
  url: 'https://example.com/account',
  cookies: `session=${process.env.TARGET_SESSION}`,
  format: 'png',
});

const response = await fetch(
  `https://api.apiflash.com/v1/urltoimage?${params}`,
  { signal: AbortSignal.timeout(90_000) }
);
if (!response.ok) {
  throw new Error(`ApiFlash returned HTTP ${response.status}: ${await response.text()}`);
}
const bytes = new Uint8Array(await response.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('account.png', bytes));

ApiFlash also accepts POST form data, which can be preferable when parameters are long. Follow its current API documentation for the exact request encoding and available capture options: ApiFlash API documentation.

3. Capture with an authentication header

If the site accepts a bearer token or another request header, use ApiFlash’s headers parameter. The documented format is semicolon-separated header/value pairs. Encode the parameter correctly for GET requests. For example:

curl -G 'https://api.apiflash.com/v1/urltoimage' \
  --data-urlencode 'access_key=YOUR_APIFLASH_ACCESS_KEY' \
  --data-urlencode 'url=https://example.com/private/report' \
  --data-urlencode 'headers=Authorization: Bearer YOUR_TARGET_TOKEN' \
  --data-urlencode 'format=png' \
  --output report.png

Some targets require a different authorization scheme or additional headers. Use the exact header expected by the target API or website. ApiFlash’s FAQ says custom headers may be applied to all requests, which can interfere with external resources such as fonts. Inspect the result; if headers break subresources, consider the cookie route or self-hosting those resources when you control the site. [ApiFlash FAQ]

4. Automate a login flow or use a site-owner bypass

ApiFlash lists injected JavaScript as another login option. The JavaScript must match the target page’s actual form fields, submit behavior, redirects, and post-login state. There is no universal script: selectors and waiting conditions vary by site, and MFA, CAPTCHA, SSO, or anti-bot protections may prevent automation. ApiFlash’s documentation describes JavaScript injection and wait controls; check its current parameter syntax before building a request. [ApiFlash API documentation]

If you own the site, ApiFlash’s FAQ suggests a secret-key URL as one possible bypass. Design such a route specifically for capture: use a high-entropy secret or signed, expiring token, limit what it can access, avoid putting it in public links, and revoke it when no longer needed. Do not weaken access control on a third-party site or bypass authorization you do not control.

5. Wait for the authenticated page to render

A successful authentication response does not guarantee that the screenshot contains the finished page. The page may redirect, hydrate data asynchronously, lazy-load content, or render fonts and images after initial navigation. ApiFlash documents wait_for and wait_until controls. Choose a wait condition based on the page, and allow enough time for its authenticated content to appear. Avoid relying on a fixed delay alone when a reliable selector or load condition is available. [ApiFlash API documentation]

Check that the captured URL, account identity, and expected private content are visible. A screenshot of the login page can look like a successful image response while still indicating that authentication failed.

6. Protect keys, cookies, and tokens

• Keep the ApiFlash access key and target credentials in server-side environment variables or a secrets manager.
• Do not put private capture URLs in public HTML, client-side JavaScript, analytics events, or shared logs. Query strings can be retained in request histories and monitoring systems.
• Use a narrowly scoped account or token where the target permits it, and rotate or revoke session credentials when no longer needed.
• Restrict who can trigger captures and where resulting screenshots are stored. A screenshot may contain the same private data as the page.
• Redact query strings and authorization values from application and proxy logs.

These are security precautions based on the documented use of access keys, cookies, and headers as authentication inputs; do not treat a screenshot API request URL as safe to publish merely because it returns an image. [ApiFlash API documentation]

7. Cache, rate limits, and request options

ApiFlash documents caching for identical parameters, a default cache duration of 86,400 seconds, and a ttl parameter to control cache duration. Set fresh=true when you need a fresh capture rather than a cached result. This matters when the page changes or a session’s view is personalized. [ApiFlash FAQ] [ApiFlash API documentation]

The documentation lists a rate of 20 requests per second with a burst size of 400. Requests beyond the rate may be delayed; requests exceeding the burst may receive HTTP 429. Queue large batches, handle 429 responses with backoff, and avoid repeatedly capturing an unchanged page when cached output is acceptable. These are documented service limits, not an independent performance benchmark. [ApiFlash API documentation]

ApiFlash’s screenshot endpoint is https://api.apiflash.com/v1/urltoimage. It requires an ApiFlash access key; GET query parameters and POST form data are documented. Other documented controls include output format and size-related capture parameters, waiting options, cache controls, headers, and cookies. Check the official documentation for supported parameters and plan availability before relying on an option.

8. Troubleshooting

Symptom or status	Likely cause	What to check
Screenshot shows a login page	Cookie expired, wrong cookie scope, missing header, or login redirect	Sign in again, verify the required cookie/header, and inspect the final page state
HTTP 400	Invalid parameter, malformed encoding, or uncapturable URL	Include the URL scheme, encode query values, and remove unsupported parameters
HTTP 401	Invalid or revoked ApiFlash access key	Check the ApiFlash key independently from the target-site credentials
HTTP 402	ApiFlash quota exhausted	Check account quota and usage before retrying
HTTP 403	Requested feature is unavailable on the current plan	Confirm feature and plan support in ApiFlash documentation
HTTP 429	Rate limit or burst limit exceeded	Reduce concurrency and retry with backoff; respect the documented 20 requests/second and 400 burst
Fonts or external assets disappear	A custom header is affecting subresource requests	Try cookie authentication, or self-host fonts if you control the site
Page is partly blank or stale	Capture occurred before rendering completed, or a cached image was returned	Use an appropriate wait control and fresh=true when freshness matters
Injected login script fails	Selectors, redirect flow, MFA, or bot defenses differ from assumptions	Validate the flow manually and use a supported credential/session route where possible

ApiFlash documents these response codes and capture controls in its API documentation. Avoid retrying authentication failures with an expired credential indefinitely; refresh or revoke the credential through the target’s normal account process.

9. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. It can accept cookies and authorization data for authenticated captures. Its single GET endpoint returns an image or PDF, and the parameter names used by other screenshot APIs also work, making migration easier. See the ScreenshotNeo API documentation.

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

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

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

For an authenticated target, provide the target’s appropriate cookie or authorization header using the documented request options, and keep those credentials server-side. ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed; an MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month, with no card.

FAQ

Does the ApiFlash access key log me into the target website?

No. It authenticates the caller to ApiFlash. The target site needs its own valid cookie, header credential, or login flow.

Can I reuse a session cookie indefinitely?

No. Session cookies may expire, rotate, or be revoked. Refresh them through the site’s normal sign-in process and avoid sharing them.

Will every protected page work with JavaScript login automation?

No. The flow is target-specific, and MFA, CAPTCHA, SSO, or other protections can prevent automation.

How do I force a new screenshot?

ApiFlash documents fresh=true to request a fresh capture; otherwise identical requests may use cached output.