How to Capture Mobile-Width Website Screenshots with ScreenshotAPI for Indian Storefronts

To capture a website at mobile width with ScreenshotAPI, send a GET request to https://api.screenshotapi.com/take with the storefront URL and explicit viewportWidth and viewportHeight values. For example, use 390 by 844 pixels for a repeatable narrow viewport. This renders the page in a browser viewport; it does not require a physical phone or camera.

A mobile-sized render does not establish that the request came from India or that the page shows the same localized prices, stock, delivery options, taxes, or content as a shopper in India. The reviewed ScreenshotAPI documentation supports changing browser language, but does not establish India-origin network rendering. Confirm network location and any required cookies, headers, or account state with the provider before using a screenshot as evidence of regional experience.

1. Identify the correct ScreenshotAPI service

This guide uses the ScreenshotAPI service documented at screenshotapi.com, with the endpoint https://api.screenshotapi.com/take. Several services have similar names. Do not transfer parameter names or capabilities from screenshotapi.net, screenshot-api.org, or another provider to this endpoint without verifying them in the correct provider’s current documentation.

The request needs a destination URL and viewport dimensions. The documented defaults are 1280 by 720 pixels, so omitting dimensions will not produce a mobile-width capture. The endpoint accepts a URL; its reference says an https:// prefix is optional, but using a full URL makes the target explicit.

2. Choose and record a mobile viewport

Set both viewportWidth and viewportHeight in pixels. A value such as 390 by 844 is one practical example, not a universal phone size or a claim about all Indian devices. For comparisons, keep the same dimensions across runs and record them with the saved image.

You can use a documented named viewportDevice preset instead of custom dimensions when your workflow calls for a particular emulated device. Record the preset name too. The API reference also documents deviceScaleFactor, from 1 to 5, as a device-pixel-ratio control. Keep it distinct from viewport size: width and height determine the page’s layout space; scale factor affects rendering density. Increasing the scale factor is not a substitute for setting the intended mobile width.

Setting	What it controls	Practical guidance
`viewportWidth`, `viewportHeight`	Layout viewport dimensions in pixels	Set both explicitly for mobile captures.
`viewportDevice`	A named device viewport preset	Use a documented preset and record its name for repeatability.
`deviceScaleFactor`	Device pixel ratio / render density	Choose separately from layout dimensions; documented range is 1–5.
`fullPage`	Whether to capture the entire scrollable page	Use for long-page audits; leave off when measuring only the first screen.

3. Make a direct request

The following request shape uses the documented endpoint and query parameters. The example requests a direct image response. URL-encode the target storefront URL so query parameters in the target do not become parameters of the screenshot request.

GET https://api.screenshotapi.com/take?url=https%3A%2F%2Fshop.example.in%2Fproducts%2Fitem&viewportWidth=390&viewportHeight=844&responseType=redirect

Replace the example domain and path with the actual storefront page. Consult the current ScreenshotAPI API reference for its current authentication and URL-encoding requirements; this research dossier does not specify an authentication parameter, so do not assume one.

cURL

This saves a direct image response to a file. The target URL is encoded as a query value by --data-urlencode.

curl -G "https://api.screenshotapi.com/take" \
  --data-urlencode "url=https://shop.example.in/products/item" \
  --data-urlencode "viewportWidth=390" \
  --data-urlencode "viewportHeight=844" \
  --data-urlencode "responseType=redirect" \
  -o storefront-mobile.png

Python

This runnable example uses the requests package and writes the response body. Install it with python -m pip install requests if it is not already available. Use the output extension that matches the actual returned image format; verify the response type before treating the file as PNG.

import requests

endpoint = "https://api.screenshotapi.com/take"
params = {
    "url": "https://shop.example.in/products/item",
    "viewportWidth": 390,
    "viewportHeight": 844,
    "responseType": "redirect",
}

response = requests.get(endpoint, params=params, timeout=90)
response.raise_for_status()

content_type = response.headers.get("content-type", "")
if not content_type.startswith("image/"):
    raise RuntimeError(f"Expected an image response, got {content_type!r}")

with open("storefront-mobile", "wb") as image_file:
    image_file.write(response.content)

print("Saved image response", content_type, "to storefront-mobile")

Node.js

This uses the built-in fetch available in current Node.js releases. It checks the HTTP status and content type before saving the response bytes.

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

const endpoint = new URL("https://api.screenshotapi.com/take");
endpoint.search = new URLSearchParams({
  url: "https://shop.example.in/products/item",
  viewportWidth: "390",
  viewportHeight: "844",
  responseType: "redirect",
}).toString();

const response = await fetch(endpoint);
if (!response.ok) {
  throw new Error(`Screenshot request failed: ${response.status} ${response.statusText}`);
}

const contentType = response.headers.get("content-type") ?? "";
if (!contentType.startsWith("image/")) {
  throw new Error(`Expected an image response, got ${contentType || "no content type"}`);
}

await writeFile("storefront-mobile", Buffer.from(await response.arrayBuffer()));
console.log(`Saved ${contentType} response to storefront-mobile`);

4. Set a useful wait condition

Storefront pages often render content after the initial document loads. ScreenshotAPI’s reference documents waitUntil values of load, domcontentloaded, networkidle0, and networkidle2; load is the documented default. Select a condition that matches the page rather than always choosing the slowest option.

load: wait for the page load event; this is the documented default.
domcontentloaded: proceed after the initial document has been parsed, which may be too early for client-rendered product content.
networkidle0 and networkidle2: wait for network activity to settle according to the browser’s network-idle condition. Analytics and chat scripts can keep a page active, so test whether this is suitable for the target.
waitForSelector: wait for a known page element when its presence is a better signal than general navigation completion.
delay: add a fixed delay from 0 to 20,000 milliseconds when the page needs additional time after navigation or another wait condition.

For example, add parameters to the request after checking the exact selector and supported syntax in the current reference:

waitUntil=networkidle2&waitForSelector=%23product-title&delay=1000

Do not add every wait mechanism by default. Longer waits increase capture time and can cause a run to hit time limits. Prefer a stable selector for content that matters; use a bounded delay only when the page’s rendering behavior requires it.

5. Handle long pages and lazy-loaded content

A viewport capture shows the visible screen at the specified dimensions. For a whole product or category page, the reference documents fullPage to capture the entire scrollable page. The doScroll option scrolls before capture to trigger lazy-loaded content. These options address different needs: full-page capture expands the capture area, while pre-capture scrolling can prompt deferred content to load.

Use a viewport-only capture for first-screen layout checks. For a page audit, enable full-page capture and consider scrolling when product images or sections load only as the visitor scrolls. Inspect the output for gaps or missing media; an option being accepted does not prove that every site’s lazy-loading implementation completed successfully.

6. Choose the response form and preserve context

The reference documents two response forms:

responseType=redirect returns the image directly, which is convenient for saving a file or passing bytes into an image workflow.
responseType=json returns metadata plus a base64 image, which can be useful when the integration expects a JSON response. Decode the base64 payload before saving it as an image.

Store the capture with its source URL, viewport or device preset, scale factor, wait settings, full-page/scroll settings, response form, and capture time. Without that metadata, later comparisons can confuse a changed layout with a changed capture configuration.

7. What a mobile screenshot can establish about an Indian storefront

A screenshot at a narrow viewport can help assess responsive layout, visible product information, navigation, image loading, and the content rendered under the browser settings used for that request. ScreenshotAPI’s pricing page says mobile-view screenshots are supported and browser resolution and settings can be changed. It also says browser language can be changed before capture.

Those facts do not establish that the browser request originates from India. A viewport size is not a network location, and a browser language setting is not proof of Indian localization. If the question is what a shopper in a particular Indian city sees, verify that the capture service supports the required India-based network location and determine how to supply the shopper’s relevant cookies, headers, login state, or address. The reviewed documentation does not establish India-origin rendering, proxy support for India, or guaranteed localized storefront behavior.

For a regional audit, define what must match before you capture: network location, browser language, consent state, signed-in state, delivery postal code, currency, and any relevant cookies. Record which of these were actually controlled. If India-origin rendering is essential and cannot be confirmed for this endpoint, treat the screenshot as a viewport render only and validate the regional experience through a separately verified setup.

8. Troubleshooting

Symptom	Likely cause	What to do
Screenshot looks like desktop	Viewport parameters were omitted, misspelled, or not accepted; documented defaults are 1280 by 720.	Set explicit `viewportWidth` and `viewportHeight`, and confirm the request uses the `screenshotapi.com` endpoint.
Content is missing or blank	Capture occurred before client-rendered content appeared, or the page failed to load.	Try an appropriate `waitUntil`, a stable `waitForSelector`, or a bounded delay; inspect the returned image rather than trusting request success alone.
Images lower on the page are absent	Assets may be lazy-loaded only after scrolling.	Consider `doScroll` and `fullPage`, then inspect the captured output.
Request hangs or takes too long	Network-idle waits can be prolonged by continuing network requests; extra delays also add time.	Use the least expensive wait condition that reliably exposes the needed content; prefer a selector where possible and keep delays bounded.
Saved file is not a viewable image	The response may be JSON metadata, an error body, or a redirect response not handled as expected.	Check status and content type. Use `responseType=redirect` for direct image bytes, or parse the JSON response and decode its base64 image.
Prices or delivery details differ from India	Viewport and language do not prove India-origin networking or the shopper’s account, location, and cookie state.	Confirm the provider supports the needed network location and state controls. Do not label the result India-localized until those conditions are verified.
Parameters seem ignored	Options may belong to a similarly named service, parameter encoding may be wrong, or the API may have changed.	Verify the hostname and parameter spelling against the current `screenshotapi.com` reference; do not borrow options from another ScreenshotAPI domain.

9. Performance, reliability, and cost

Capture time depends on page behavior and the wait strategy. A network-idle condition, long fixed delay, full-page capture, and pre-capture scrolling can all increase work compared with a viewport capture using a suitable navigation wait. Keep the settings consistent when comparing runs, and choose the shortest wait that reliably includes the content under review.

For repeatability, save the full request configuration with each image and inspect the result for challenges, blank pages, consent overlays, missing images, and stale content. A successful API response alone does not prove that every personalization, inventory, login, or consent flow worked as intended.

The ScreenshotAPI pricing page reviewed for this guide displayed 100 free shots on signup followed by $0.001 per shot, and advertised PNG, JPG, and GIF output. These are vendor-published figures observed on 2026-10-03, not independent pricing data; quotas and prices can change, so check the live pricing page before estimating a project’s cost.

10. Or skip the browser setup

ScreenshotNeo can capture a URL with one GET request, return an image or PDF, and offers options including mobile viewport dimensions and device presets. See the ScreenshotNeo website and API documentation for request details.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://shop.example.in/products/item \
  --data-urlencode viewport_width=390 \
  --data-urlencode viewport_height=844 \
  -o shot.webp

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots, and 1,000 screenshots per month are free with no card; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month with no card.

11. FAQ

Does a 390-pixel screenshot represent every Indian phone?

No. It is one chosen viewport for a reproducible render. Select dimensions or a documented device preset that fits the device or layout you want to inspect.

Should I make the viewport wider to get a sharper image?

No. Viewport dimensions control layout space. Use the separate documented deviceScaleFactor setting when you need to control rendering density.

Can I claim that the result is exactly what a customer in India sees?

Not from viewport and language settings alone. The reviewed material does not establish India-origin network rendering or guarantee regional pricing, inventory, tax, delivery, or account-specific content.

Do I need a physical smartphone?

No. The documented API renders a URL using browser viewport or device-emulation settings.