Can Microlink Capture Screenshots of Pages Behind a Login?

Yes. Microlink can capture a page behind a login when you send the target site’s session cookie or authorization token as a forwarded HTTP header. The documented workflow uses Microlink’s Pro endpoint at pro.microlink.io and an API key in the x-api-key header. Header forwarding requires a Pro plan; the documented free endpoint does not provide this workflow. Keep the authenticated call on your backend so session secrets do not reach a browser or appear in a URL. Microlink’s official guide documents the header names and options.

How header forwarding works

Microlink accepts headers whose names start with x-api-header-, removes that prefix, and forwards the remaining header to the target page. For example, x-api-header-cookie becomes the target site’s ordinary cookie header. The API key authenticates your request to Microlink; the forwarded cookie or token authenticates the browser session to your application.

Purpose	Microlink request header	Header received by target
Session cookie	x-api-header-cookie: session=…	cookie: session=…
Bearer token	x-api-header-authorization: Bearer …	authorization: Bearer …

Use the authentication mechanism your target site expects. A cookie-based web session usually needs the cookie name and value; an API-backed application may accept a bearer token. Forwarding a credential does not log in through a form: it lets the capture request present an existing session to the target.

Capture a signed-in page with Node.js

The following server-side example uses Microlink’s Node client. Set MICROLINK_API_KEY and SESSION_COOKIE in your server environment. Replace the example URL, cookie name, and selector with values for an application and session you are authorized to access.

import createClient from 'microlink.io'

const microlink = createClient({
  apiKey: process.env.MICROLINK_API_KEY
})

const { url } = await microlink.screenshot('https://app.example.com/dashboard', {
  headers: {
    'x-api-header-cookie': `session=${process.env.SESSION_COOKIE}`
  },
  waitForSelector: '[data-page="dashboard"]'
})

console.log(url)

The selector wait is useful when the signed-in page renders asynchronously. Choose an element that exists in the authenticated view and does not also appear on the login screen. The returned url is the screenshot result URL from the client response.

Use a bearer token instead

If the target site accepts a bearer token, forward its authorization header. Keep the value in server-side configuration:

const { url } = await microlink.screenshot('https://app.example.com/dashboard', {
  headers: {
    'x-api-header-authorization': `Bearer ${process.env.APP_ACCESS_TOKEN}`
  },
  waitForSelector: '[data-page="dashboard"]'
})

console.log(url)

Make the request with cURL

Send Microlink the API key and forwarded cookie as HTTP headers. The screenshot options, including the target URL, are request parameters. This example keeps credentials out of the URL; populate the environment variables in a protected shell or secret manager.

curl --get 'https://pro.microlink.io' \
  --header "x-api-key: $MICROLINK_API_KEY" \
  --header "x-api-header-cookie: session=$SESSION_COOKIE" \
  --data-urlencode 'url=https://app.example.com/dashboard' \
  --data-urlencode 'waitForSelector=[data-page="dashboard"]'

For token authentication, replace the cookie header with --header "x-api-header-authorization: Bearer $APP_ACCESS_TOKEN". Do not put a real cookie or token in a query parameter, shell history, source control, or logs.

Use Python

Python’s requests package can make the same backend request. Install it with python -m pip install requests, then set the environment variables before running:

import os
import requests

response = requests.get(
    "https://pro.microlink.io",
    headers={
        "x-api-key": os.environ["MICROLINK_API_KEY"],
        "x-api-header-cookie": f"session={os.environ['SESSION_COOKIE']}",
    },
    params={
        "url": "https://app.example.com/dashboard",
        "waitForSelector": '[data-page="dashboard"]',
    },
    timeout=90,
)
response.raise_for_status()
print(response.url)
print(response.headers.get("content-type"))

For an authorization token, use "x-api-header-authorization": f"Bearer {os.environ['APP_ACCESS_TOKEN']}" in the headers dictionary instead of the cookie header. Handle and store the response according to the response format configured for your Microlink request.

Configuration and session details

Use the correct endpoint and key

Authenticated captures that forward custom headers use pro.microlink.io. Send your Microlink API key in x-api-key. Microlink’s API overview also describes custom headers as a Pro capability. See the official API overview and behind-login guide for the documented plan and request workflow.

Forward the right cookie

Copy the relevant session cookie name and value from an authorized session. A site may set several cookies, and the session cookie can be scoped by domain or path or expire. Forward the exact cookie the target needs. Do not forward unrelated browser cookies or a credential belonging to another user.

Wait for the signed-in page

Use waitForSelector to wait for a stable marker in the private view, such as a dashboard container. This helps when authentication succeeds but client-side rendering takes time. If the selector never appears, investigate whether the page stayed logged out, the selector changed, or the application failed to finish rendering.

Separate captures by user

Microlink’s guide says each capture runs in its own isolated browser. If different users capture the same URL, use a user-specific cacheKey so one user’s cached result is not reused for another user’s view. Treat cache keys as part of your per-user data separation design.

Keep credentials private

• Make authenticated capture requests from a server you control.
• Keep API keys, cookies, and access tokens in environment configuration or a secret manager.
• Do not place secrets in the public headers query parameter; Microlink reserves that parameter for non-sensitive values.
• Redact authentication headers and request parameters from application logs and error reports.
• Only capture pages and forward sessions you are authorized to access and store.

Troubleshooting

Symptom	Likely cause	What to check
The screenshot shows the login form	The cookie or token was not accepted, or the request did not use the authenticated workflow.	Confirm the Pro endpoint and API key, the forwarded header spelling, cookie name and value, cookie domain and expiration, and whether the target accepts that token.
Custom header forwarding is unavailable	The request uses the free endpoint or an account without the required plan capability.	Use pro.microlink.io and confirm the Pro requirement in Microlink’s current documentation.
The page is captured before the dashboard appears	The authenticated UI renders after the initial document load.	Wait for a selector unique to the signed-in view with waitForSelector; verify that the selector still exists in the application.
A capture for one user appears to show another user’s state	Cache entries for the same URL may not be separated by user.	Set a distinct user-specific cacheKey for each user’s capture.
The request returns an API error	The API key may be missing or invalid, the endpoint may be wrong, or the request parameters may be malformed.	Check the x-api-key header, endpoint, URL encoding, and response status and error body. Keep secrets redacted while debugging.
The target still rejects the session	The site may require a different cookie, a fresh login, additional application state, or a token in a different header.	Confirm the target’s own authentication behavior and use a currently valid session issued for the target domain. Do not assume a cookie from another domain will work.

Performance, reliability, and cost

A capture depends on the target site being reachable and on its authenticated UI rendering in time. Waiting for a specific selector makes the capture condition more meaningful than relying only on an arbitrary delay, but a changed selector or a page that never reaches the expected state can still prevent a useful result. Reuse a stable selector and handle request failures in your calling service.

Microlink’s documented login workflow requires Pro for forwarded headers. The sources for this guide do not establish a specific price, latency, uptime, or capture success rate, so check Microlink’s current plan information for commercial terms. If you capture private pages for multiple users, separate cache entries and credentials by user and apply your own retention and access controls.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. It accepts one GET request with a URL and returns a PNG, JPEG, WebP, or PDF. See the ScreenshotNeo documentation for its API options. For example:

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

ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before the shot; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and the response identifies the page verdict and billing status in headers. Its MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots.

Sign up for ScreenshotNeo’s free plan and get 1,000 screenshots a month with no card.

FAQ

Can I screenshot a page behind a login on the free plan?

Microlink’s documented header-forwarding workflow requires Pro. The free endpoint is not sufficient for sending the session cookie or authorization header this way.

Why does my screenshot still show the login form?

Most often, the target did not accept the forwarded session. Check the endpoint and key, then verify the cookie or token, its validity and scope, and that the page’s authenticated selector appears.

Can I forward credentials in a URL?

Do not put session secrets in a URL. Send them as x-api-header-* HTTP headers from your backend.