How to Automate Website Screenshots for an Indian Government Portal with CaptureKit

Automate portal screenshots by running a server-side job that calls CaptureKit’s GET /v1/capture endpoint with the target URL and an x-api-key header. Choose the viewport, output format, and render wait that match the state you need to document. Store the API key on the server, record capture settings and outcomes, and confirm the portal owner’s access rules before scheduling requests. A screenshot records visible appearance; it does not establish GIGW conformance.

This guide covers a repeatable CaptureKit workflow, configuration choices, failure handling, and what screenshots can and cannot show about an Indian government website. The title does not specify a portal, so its access policy, authentication requirements, sensitivity, and acceptable request frequency must be confirmed with that portal’s owner.

1. Confirm permission and define what the screenshot should show

Before automating captures, check the specific portal’s published terms, access controls, and any owner approval or operational limits. Official guidance does not grant blanket permission to automate access to every government portal. Avoid assuming that a public page may be polled at any frequency.

Write down the purpose of the capture and the state it needs to document. For example, a desktop page at a particular viewport and a mobile-emulated view answer different questions. A screenshot can preserve a visible state for comparison, but it cannot reveal semantic markup, accessible names, screen-reader behavior, or every manual evaluation checkpoint.

The Government of India’s Guidelines for Indian Government Websites and apps (GIGW) apply to government websites and apps at central, state, and local levels. The official scope page says the guidelines aim to support “usability, user-centricity and universal accessibility.” GIGW also addresses security and consistent presentation. Treat screenshots as visual records that can support review, alongside the accessibility, security, and manual evaluation methods required for a fuller assessment. See the official GIGW site, including its guidelines and resources.

2. Create a CaptureKit key and keep it server-side

Create a CaptureKit account and generate an API key using its quick start.
Save the key in an environment variable or your server’s secret store. CaptureKit says the key is shown once, so save it securely when it is created.
Do not place the key in browser JavaScript, a mobile app, a public repository, or client-visible configuration. A client can expose a key through its network traffic. Route requests through a backend job you control.
Choose where results will be stored. Restrict access to screenshots and logs according to their contents and your organization’s handling rules.

The examples below use an environment variable called CAPTUREKIT_API_KEY. Set it in the job runner’s secret configuration rather than hard-coding a real key in source code.

3. Make a first capture with cURL

Replace the example URL with a page you are authorized to capture. This request asks for a PNG at a 1440 by 1000 viewport and waits for the page load event:

export CAPTUREKIT_API_KEY='YOUR_API_KEY'
curl --fail-with-body --get 'https://api.capturekit.dev/v1/capture' \
  --header "x-api-key: ${CAPTUREKIT_API_KEY}" \
  --data-urlencode 'url=https://example.gov.in/' \
  --data-urlencode 'format=png' \
  --data-urlencode 'width=1440' \
  --data-urlencode 'height=1000' \
  --data-urlencode 'wait_until=load' \
  --output portal.png

CaptureKit documents GET /v1/capture and the x-api-key header. Check its capture endpoint reference for current parameter spellings, response behavior, and optional storage controls before deploying. Endpoint details can change.

4. Runnable Python example

This script reads the secret from the environment, requests a capture, checks for an HTTP error, and writes the response bytes to a file. Install the dependency with python -m pip install requests.

import os
import sys
from pathlib import Path

import requests

api_key = os.environ.get("CAPTUREKIT_API_KEY")
if not api_key:
    sys.exit("Set CAPTUREKIT_API_KEY in the job environment")

params = {
    "url": "https://example.gov.in/",
    "format": "png",
    "width": 1440,
    "height": 1000,
    "wait_until": "load",
}

try:
    response = requests.get(
        "https://api.capturekit.dev/v1/capture",
        headers={"x-api-key": api_key},
        params=params,
        timeout=90,
    )
    response.raise_for_status()
except requests.RequestException as exc:
    sys.exit(f"Capture request failed: {exc}")

Path("portal.png").write_bytes(response.content)
print("Saved portal.png")

Use a timeout appropriate for your job runner and the target page. A client timeout means your process stopped waiting; it does not prove what happened on the remote service. Log the outcome and consult the API logs when diagnosing a request.

5. Runnable Node.js example

This example uses the built-in fetch available in modern Node.js and writes the image response to disk.

import { writeFile } from 'node:fs/promises';

const apiKey = process.env.CAPTUREKIT_API_KEY;
if (!apiKey) throw new Error('Set CAPTUREKIT_API_KEY in the job environment');

const query = new URLSearchParams({
  url: 'https://example.gov.in/',
  format: 'png',
  width: '1440',
  height: '1000',
  wait_until: 'load',
});

const response = await fetch(
  `https://api.capturekit.dev/v1/capture?${query}`,
  { headers: { 'x-api-key': apiKey }, signal: AbortSignal.timeout(90_000) },
);

if (!response.ok) {
  const detail = await response.text();
  throw new Error(`Capture failed (${response.status}): ${detail}`);
}

const image = Buffer.from(await response.arrayBuffer());
await writeFile('portal.png', image);
console.log('Saved portal.png');

Keep this code in a server-side process. Do not ship the API key with a web page or mobile application.

6. Choose format, viewport, and render timing

CaptureKit documents image and PDF formats, viewport and device controls, selector capture, render waits, delays, resource and URL blocking, caching, and optional S3-compatible storage. Use the endpoint reference for the exact parameter names and allowed values.

Choice	When it helps	What to check
PNG	When you want a lossless raster record of text and interface details.	File size and consistent viewport across runs.
JPEG or WebP	When a smaller image is more useful for storage or transfer.	Whether compression or format changes affect the comparison workflow.
PDF	When a document-like output is needed for review or printing.	Page breaks and print layout; a screenshot API’s PDF is not itself a compliance result.
Viewport or device dimensions	When documenting a specific desktop or mobile-sized view.	Record the dimensions or device setting with each capture; the same site can reflow at different widths.
Full-page capture	When the record should include content below the initial viewport.	Long pages may take longer and lazy-loaded content may need time or scrolling behavior supported by the service.
Selector capture	When only one page element is relevant.	The selector must match the intended element on the rendered page.
`wait_until`	When page readiness should follow a browser lifecycle event.	CaptureKit documents `domcontentloaded`, `load`, `networkidle0`, and `networkidle2`. Test which reflects the target page.
Delay or `wait_for_selector`	When content appears after initial navigation or a known element signals readiness.	Use a specific, observable condition; a fixed delay can waste time or still be too short.
Resource or URL blocking	When limiting particular requests is part of a controlled capture.	Blocking scripts, styles, fonts, images, or network requests can change the rendered appearance. Compare against an unblocked capture first.
Cache	When repeat captures can reuse a cached result under the configured rules.	Choose cache settings deliberately; a cached image may represent an earlier page state.
S3-compatible storage	When the workflow needs results placed in supported object storage.	Validate access controls, retention, and sensitivity handling with the storage owner.

Vary one setting at a time when establishing a workflow: desktop versus mobile dimensions, full viewport versus selector, image versus PDF, immediate versus lifecycle or selector wait, and unrestricted versus blocked resources. The dossier describes these as available configuration choices; it does not establish a best setting for any particular portal.

7. Turn the request into a scheduled workflow

Use a controlled backend runner. Run the capture in a scheduled job or service with access to the secret, rather than from a visitor’s browser.
Set a measured schedule. Ask the portal owner about acceptable frequency and avoid unnecessary repeated requests. No frequency can be recommended without portal-specific rules.
Record the capture context. Save the target URL, timestamp, viewport or device, format, wait setting, selector or delay if used, and outcome beside the output.
Handle failure explicitly. Distinguish a successful image from an HTTP error, timeout, invalid configuration, or unexpected response. Do not treat a missing file as a valid screenshot.
Protect artifacts. Apply appropriate access restrictions and retention to screenshots and logs, since their content may be sensitive even when the page is public.
Review service logs and usage. CaptureKit’s quick start describes API logs with status, duration, and credit cost. Use them to reconcile job outcomes and investigate errors.

CaptureKit documents one credit per successful capture call. Its overview says successful responses consume credits and errors do not; pricing and account behavior can change, so confirm current terms in the provider’s documentation before estimating recurring cost. Include retries in your cost estimate because each successful retry is another successful capture call.

8. Interpret screenshots correctly for GIGW work

GIGW includes checks that cannot be established from pixels alone. Its guidance includes manual evaluation; it also addresses accessibility, including meaningful explanatory text for images and other non-text content. A screenshot cannot show whether an image has appropriate alternative text, whether controls expose accessible names, or whether a screen reader can use the page.

The guidance also includes a checkpoint that a page prints correctly on A4 and says an evaluator shall test it manually. A screen capture can help preserve a visible layout for review, but it does not prove correct print behavior. Use separate accessibility, security, and manual evaluation methods for conformance work, and document the method and scope of each result.

9. Troubleshooting

Symptom	Likely cause	What to do
Unauthorized response	The key is missing, invalid, or sent under the wrong header.	Confirm the server-side secret is present and send it as `x-api-key`. Do not paste it into client code.
Bad request or validation error	A required parameter is absent, a format or wait value is unsupported, or the URL is malformed.	Check the current endpoint reference, URL-encode query values through your HTTP client, and retry with the smallest valid parameter set.
Capture is blank or incomplete	The page may not have rendered by the chosen lifecycle event, or a needed resource was blocked.	Try a documented later wait condition, a suitable delay, or a selector wait. Temporarily remove resource blocking to compare.
Dynamic content is missing	Content may render after navigation or depend on an element becoming available.	Wait for the relevant selector if supported, or use a delay based on observed page behavior; check the selector actually matches.
Capture takes too long or times out	The page may have slow or long-lived network activity, or the selected wait condition may never settle promptly.	Test a different documented wait mode and set a bounded client timeout. Investigate with the provider logs rather than retrying indefinitely.
Layout differs between runs	Viewport, device emulation, page content, timing, cache, or resource availability may differ.	Record settings, keep them fixed for comparisons, and check whether caching or a dynamic page state explains the change.
Element capture fails or returns the wrong region	The selector may be absent, ambiguous, or attached to a different element at render time.	Inspect the page structure, choose a more specific selector, and wait for it to appear before capture.
Image looks broken after enabling blocking	A blocked stylesheet, font, image, script, or request may be required for the intended appearance.	Remove blocking rules one at a time and compare with a baseline capture.
Job reports failure but an artifact exists	The client may have timed out after the service completed, or the job may have failed while saving the response.	Check the API logs and storage, use deterministic filenames or job identifiers, and avoid blindly issuing duplicate captures.

10. Performance, reliability, and cost considerations

Wait only as long as the page requires. Longer waits can increase job duration. Select a lifecycle condition or selector based on the page’s behavior and validate it on the target.
Keep schedules proportionate. Capture frequency affects request volume and successful-call credit use. Confirm an acceptable schedule with the portal owner.
Use bounded retries. Retry transient failures with a limit and a delay; do not create an unbounded loop. A successful retry is another successful call under CaptureKit’s one-credit-per-success description.
Preserve provenance. A timestamp and the capture configuration help explain why two images differ. They do not prove the website showed the same state to every user.
Plan storage and retention. Image and PDF sizes, retention, access control, and optional S3-compatible storage affect operational cost and risk. The cited documentation does not establish government data-handling approval.
Recheck provider terms. Credit rules and account details can change. Confirm current pricing and limits before budgeting a production schedule.

11. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. It can return an image or PDF from one GET request. Cookie and consent banners are accepted and removed before capture, along with 60+ known consent platforms, newsletter popups, and chat widgets. Bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed; responses identify page verdict and billing status in headers. Its MCP server gives Claude, Cursor, and other MCP clients screenshot tools.

For example, this cURL request saves a WebP screenshot. See the ScreenshotNeo API documentation for options and setup:

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

The same endpoint can be called from Python:

import requests

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

Or from Node.js:

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.gov.in/',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`ScreenshotNeo request failed: ${res.status}`);
await Bun.write('portal.webp', res);

ScreenshotNeo includes 1,000 screenshots per month free with no card; paid plans start at $5 for 3,000. Sign up for free and capture up to 1,000 screenshots a month with no card.

12. FAQ

Can automated screenshots demonstrate that a government portal conforms to GIGW?

No. They can document visible states, but GIGW includes accessibility and manual evaluation requirements that screenshots cannot establish.

Can I use this workflow for any Indian government portal?

The endpoint workflow is general, but permission, authentication, request frequency, and data handling are portal-specific. Confirm them with the portal owner.

Does a successful screenshot mean the page was accessible?

No. A rendered image does not test semantic structure, accessible names, keyboard behavior, or screen-reader support.

Should I capture a full page or just the viewport?

Choose based on the evidence you need. Keep the choice and dimensions consistent across repeated comparisons.