Can PagePeeker Capture Websites Behind a Login or Basic Authentication?
PagePeeker’s public API docs do not describe target-site authentication. Learn what that means for Basic Auth and login pages, and how to choose a documented alternative.
Short answer: PagePeeker’s public V2 API documentation does not describe an option for authenticating to a target website. It lists a target URL and thumbnail options, but no HTTP Basic Auth credentials, cookies, or browser login actions. That documentation gap does not prove PagePeeker cannot support authenticated capture in a custom arrangement, so confirm with PagePeeker before relying on it.
This distinction matters because an HTTP Basic Auth challenge and a website login form are different mechanisms. A tool that supports one may not support the other.
1. What PagePeeker’s public API documents
The PagePeeker API reference describes a URL and thumbnail-generation parameters, including thumbnail size, an optional account code, refresh, and wait. The reviewed reference does not document a target-site Basic Auth parameter, a session-cookie parameter, or actions for completing a login form. See the PagePeeker Website Thumbnails API documentation.
Therefore, the defensible conclusion is: authenticated capture is not established by the public documentation reviewed. Do not assume a protected URL will produce its private content. Depending on the target and capture behavior, the result could instead be a login page, an authorization error, or an incomplete capture; those are possibilities, not documented or tested PagePeeker outcomes.
If this capability is a requirement, ask PagePeeker whether it supports your exact authentication method and endpoint. Ask whether the support is public API functionality or a customer-specific arrangement, and how credentials are transmitted and handled.
2. Basic Auth versus a website login
| Mechanism | What happens | Capture capability to look for |
|---|---|---|
| HTTP Basic Authentication | The server challenges the request for credentials before serving the protected resource. | An explicitly documented Basic Auth option or supported Authorization header sent to the target origin. |
| Website or application login | A browser submits a form or follows an identity flow, then the site usually retains session state in cookies. | Support for session cookies or a stateful browser that can perform the required login steps and retain the resulting session. |
Sending credentials is not the same as completing a browser login. A regular login may involve redirects, CSRF tokens, JavaScript, multifactor authentication, or several pages of interaction. A single screenshot request that accepts a URL may not have a way to perform those steps.
Other providers illustrate the distinction in their documentation: Cloudflare Browser Run documents cookies and an HTTP Basic Auth parameter for its screenshot endpoint, while Capture documents Basic Auth and points to Browser Sessions for workflows requiring login state and multiple steps. These examples show what to check for; they are not endorsements. See Cloudflare Browser Run’s screenshot endpoint, Capture’s authentication documentation, and Capture’s API overview.
3. How to evaluate an authenticated screenshot API
- Identify the target’s protection. Check whether opening the URL prompts for a browser-level Basic Auth challenge or shows an application login page. If you are unsure, ask the site administrator.
- Find the exact endpoint’s authentication documentation. Look for target-origin Basic Auth support for a challenge, or cookies/session support and browser actions for a login flow. A generic statement that a product supports headers does not by itself establish how credentials are applied.
- Check session behavior. For form-based login, determine whether the service can execute the flow, retain cookies across navigation, and capture only after the authenticated page is ready.
- Test with a non-sensitive staging page. Use a disposable account and non-production content. Verify the returned image shows the protected page, not a login screen or error, before depending on the integration.
- Confirm credential handling. Review how secrets are sent, stored, logged, and scoped. Avoid putting passwords or session cookies in public URLs, source control, or client-side code.
When comparing services, compare these separately: Basic Auth to the target origin, supplying or retaining session cookies, multi-step browser login, and whether authenticated capture is explicitly documented for the endpoint you will call.
4. PagePeeker-specific considerations
PagePeeker’s robot information says it attempts to fetch a site only once every 5–7 days and explains how site owners can disallow its crawler in robots.txt. That statement describes its crawler behavior; it does not establish how an API screenshot request handles login-protected pages. See PagePeeker’s robot information.
Its pricing page lists Basic at $5.99 per month for 100,000 API calls and Advanced at $39.99 per month for 1,000,000 API calls. Prices and quotas can change, so verify the current PagePeeker pricing before choosing a plan. The listed call quota does not answer whether authenticated captures are supported.
5. Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. For a protected target, first confirm the required authentication method is supported by the endpoint; do not send credentials unless that support is documented. For a public page, or a URL accessible to the API without a login, a basic screenshot request looks like this. See the ScreenshotNeo API documentation.
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}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));
ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers say the page verdict and billing status. Its MCP server offers take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.
Sign up for ScreenshotNeo’s free plan to try 1,000 screenshots a month with no card.
6. Troubleshooting authenticated captures
| Symptom | Likely cause | What to check |
|---|---|---|
| The screenshot shows a login page | The capture request reached the application without an authenticated session, or the login flow was not completed. | Confirm the endpoint supports session cookies or browser login actions. Check redirects and whether the session persists through navigation. |
| The response is unauthorized or forbidden | Credentials are missing, incorrect, expired, or sent using the wrong mechanism; the account may lack permission. | Distinguish a Basic Auth challenge from an application login. Verify the documented credential format, target host, and account access. |
| Basic Auth works in a browser but not in capture | The browser may have cached credentials, while the capture request does not send them. | Use a service that explicitly documents target-site Basic Auth for the endpoint. Do not infer support from URL access alone. |
| The first page is authenticated but later content is not | The session cookie may not be retained across redirects or subsequent navigation, or the site uses additional authentication steps. | Check cookie scope, domain, expiry, and the browser workflow supported by the provider. |
| The page is partly loaded or missing content | Authentication may be followed by delayed client-side rendering or additional requests. | Use a capture tool with documented wait conditions or browser actions, and wait for a page-specific element before capture where supported. |
| Credentials appear in logs or a shared link | Secrets were placed in a URL or exposed in client-side code or request logging. | Use the provider’s documented secure credential mechanism, restrict access, and rotate exposed credentials. |
7. Reliability, performance, and cost
- Reliability: Treat authentication support as an endpoint-specific capability. Test the full flow, including redirects, session expiry, and the final rendered page. A successful HTTP response alone does not prove the image contains authenticated content.
- Performance: Basic Auth is usually a single request challenge-response, while form-based login can require multiple navigations and browser actions. More steps and page readiness waits can increase capture time. The sources reviewed provide no comparative timing benchmarks.
- Cost: Check whether authentication workflows consume one capture or multiple browser actions, and whether retries count toward your quota. Recheck current vendor pricing and limits before production use.
- Security: Use a dedicated low-privilege account where possible, avoid production credentials in experiments, and keep secrets out of URLs that may be stored in logs or history.
8. Frequently asked questions
Does PagePeeker definitely fail on protected pages?
The reviewed public API documentation does not establish the result for protected URLs. A login page or authorization error is possible, but that is an inference, not a tested PagePeeker result. Ask PagePeeker about the exact case.
Can I put a username and password into the target URL?
Do not assume that URL-embedded credentials are supported or safe. Use only an authentication mechanism explicitly documented by the screenshot provider, and avoid exposing secrets in URLs.
Will a PagePeeker account code authenticate me to the target website?
The API reference lists an optional account code, but does not document it as target-site authentication. Confirm its purpose with PagePeeker rather than treating it as Basic Auth or a session credential.
What should I ask PagePeeker?
Ask whether the specific API endpoint supports HTTP Basic Auth, cookies, or an interactive login flow; how credentials are supplied and protected; and whether the resulting capture includes the authenticated page after redirects.


