How to Batch Capture Indian Ecommerce Product URLs with a Screenshot API

To batch capture Indian ecommerce product URLs, first normalize and validate the URLs, then submit them to an API that accepts multiple URLs or a URL list. Track the returned batch or job until each URL has a result, retry only eligible failures, and save each image with metadata that maps it back to the source product.

Batch support does not guarantee that a provider can render Amazon.in, Flipkart, Meesho, or any other Indian marketplace reliably. Validate representative URLs from your own target sites, regions, and page types before scheduling a production run.

1. Prepare and validate the URL list

Keep the source URL and a stable product identifier together. The identifier makes it possible to associate an output with a product even if query parameters or URL formats change later.

product_id,url,marketplace
sku-1042,https://www.example.com/products/item-a,example
sku-1043,https://www.example.in/item/b,example-in

The following Python preparation step reads a CSV, trims whitespace, removes blank rows and duplicate URLs, and rejects values without an HTTP or HTTPS scheme and hostname. Replace the sample capture endpoint and response handling with the current API contract of the provider you choose.

import csv
from urllib.parse import urlsplit

seen = set()
valid = []
invalid = []

with open("products.csv", newline="", encoding="utf-8") as f:
    for row in csv.DictReader(f):
        product_id = row.get("product_id", "").strip()
        raw_url = row.get("url", "").strip()
        if not raw_url:
            invalid.append((product_id, raw_url, "blank URL"))
            continue
        parts = urlsplit(raw_url)
        if parts.scheme not in {"http", "https"} or not parts.hostname:
            invalid.append((product_id, raw_url, "expected an HTTP(S) URL with a hostname"))
            continue
        canonical = raw_url
        if canonical in seen:
            continue
        seen.add(canonical)
        valid.append({"product_id": product_id, "url": canonical,
                      "marketplace": row.get("marketplace", "").strip()})

print(f"ready={len(valid)} invalid={len(invalid)}")
for item in invalid:
    print("invalid:", item)

This is basic input hygiene, not a universal marketplace-specific URL validator. Avoid stripping query parameters unless you have verified they are tracking-only; parameters can identify product variants or affect the page. Retain the original URL even if you also store a normalized form.

2. Choose a batch submission pattern

Providers use different request and result models. Some accept an array of URLs and return a batch ID; others process background jobs, accept uploaded text or CSV lists, or impose small per-request limits. Decide based on your list size, output destination, required capture controls, and how you need to handle failures.

Pattern	Useful when	Check before implementation
JSON array in one request	The provider accepts a modest list and returns a batch identifier.	Maximum URLs, request size, status endpoint, and per-URL result schema.
Queued job	Captures may outlast a normal HTTP request and need polling or callbacks.	Job states, webhook signing, retention, retry behavior, and failure details.
Uploaded URL file	A large list is easier to manage as an input file.	Accepted file format, maximum file size, output retrieval, and access controls.
Small batches	The provider enforces a low URL limit or you want bounded retry units.	Concurrency and rate limits; do not assume one vendor’s limit applies to another.

For context, the documented patterns vary: Screenshot API describes a batch endpoint that returns a batch ID and supports status tracking and server-sent events. Browshot documents a text-file batch workflow and a multi-screenshot call with up to 10 URL parameters and 10 instances. ScreenCapr documents up to 10 URLs per batch; PageShot documents up to five and per-URL option overrides. These are vendor-documented limits, not comparable performance benchmarks. Check the linked, current API references before relying on them: Screenshot API batch documentation, Browshot API documentation, ScreenCapr API documentation, and PageShot documentation.

AddScreenshots describes background bulk jobs for URL lists and domains, with cloud repository delivery; ScreenshotCenter describes list uploads, status tracking, ZIP downloads, and storage delivery. These are provider descriptions, and the AddScreenshots reference may be old, so verify current endpoints and terms: AddScreenshots documentation and ScreenshotCenter bulk screenshots.

3. Submit work and track each URL

Do not treat a successful submission response as proof that every page rendered. Persist the provider’s batch ID and input-to-output mapping. Poll the documented status route, consume its documented event stream, or receive a webhook if the provider offers one. Record per-URL states such as queued, succeeded, failed, and skipped, along with any error reason and output location.

A provider-neutral request shape looks like this; it is illustrative because vendors use different paths, authentication schemes, option names, and result formats:

curl -X POST "https://api.provider.example/v1/screenshot/batch" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"urls":["https://shop.example/item/1","https://shop.example/item/2"],"format":"png","full_page":true}'

Use the provider’s documented endpoint and schema rather than copying this placeholder. A batch API may return immediately with a job ID; the eventual result can be a list of captures, a ZIP archive, or files delivered to configured storage. Keep submission and result retrieval as separate stages in your application.

4. Set consistent capture options

Choose options to match the evidence you need and apply them consistently within a comparison set. Confirm the provider supports each option; the reviewed vendor documentation does not establish that all providers expose identical controls.

• Viewport: set width and height for a desktop or mobile layout. Use separate capture groups if both matter.
• Full page: useful for long product details, but can increase render time and output size. Confirm lazy-loaded content is included as expected.
• Format: PNG preserves crisp text and UI edges; JPEG can reduce size for photographic pages; WebP may be useful when supported by your downstream tools.
• Wait behavior: use a supported selector, fixed delay, or network-idle condition when the page needs time to render. Excessively long waits reduce throughput.
• Per-URL overrides: use only when the API supports them and record the effective options alongside each result.
• Geography and browser settings: region, user agent, cookies, or other settings can affect what appears. Do not assume a provider has the location or browser behavior your use case needs.

5. Save results with traceable names

Use a deterministic filename that includes a safe product identifier and capture time, for example sku-1042_2026-10-04T120000Z.png. Keep a metadata record with the original URL, marketplace, capture timestamp, effective options, job ID, status, output path, and error details. Avoid using the full URL as a filename: URLs can contain characters unsafe on filesystems and may include sensitive query values.

If results are delivered to cloud storage, verify the destination, retention policy, access permissions, and expected file format in the provider’s current documentation. For ZIP results, check archive entry names and make the URL-to-file mapping explicit rather than relying on entry order.

6. Retry selectively and operate safely

• Retry transient network errors, provider timeouts, and documented temporary server errors with a bounded exponential backoff and jitter.
• Do not blindly retry invalid URLs, unsupported options, access-denied responses, or pages that consistently show a challenge. Preserve these as failed outcomes for review.
• Respect documented request-per-minute, monthly usage, concurrent-job, and batch-size limits. Split large lists into chunks that fit the current API contract.
• Make webhook processing idempotent: the same event may be delivered more than once. Deduplicate by provider event or job and URL identifiers.
• Keep API credentials server-side. Do not place secrets in a public webpage, client-side bundle, or committed input file.

Quotas change and differ in what they count. For example, Screenshot API documentation accessed on 2026-10-03 listed 60 requests per minute and 500 screenshots per month for its free plan. Recheck current plan details; do not infer that another provider uses the same limits.

7. Validate marketplace coverage before scaling

Run a small representative sample from every target marketplace and page class before automating a full catalog. Include different product types, variant URLs, long pages, and the regions or device layouts that matter to you. Review the returned images for completed content, consent prompts, bot checks, blank states, and layout differences.

The available API references describe generic batch and capture workflows; they do not demonstrate reliable rendering of Amazon.in, Flipkart, Meesho, or other Indian marketplace pages. Results may vary by URL, region, session, provider, and access restrictions. Do not promise universal capture success. If you are a Flipkart seller who needs your own listing data rather than screenshots, the authenticated Seller API is a separate option; its listing search documentation says a maximum of 20 listings are returned per batch for the specified filter. That listing endpoint is not a screenshot API: Flipkart Seller API documentation.

Or skip the browser setup

ScreenshotNeo takes screenshots through one GET request and also supports bulk capture of up to 100 URLs per call. Its responses identify page verdict and billing status in headers, and its API accepts the parameter names used by other screenshot APIs, which can make switching easier. Review the ScreenshotNeo API documentation for the current request options.

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}`);
await Bun.write('shot.webp', new Uint8Array(await res.arrayBuffer()));

Change the target URL to a product URL you are authorized to capture. ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots. Create a free ScreenshotNeo account.

Troubleshooting

Symptom	Likely cause	What to do
The batch request is rejected	Wrong endpoint or schema, invalid authentication, oversized request, or batch limit exceeded.	Check the current API reference, token scope, body format, and maximum URLs. Split the list into supported chunks.
The job was accepted but some images are missing	Submission succeeded, while individual renders failed or remain in progress.	Read per-URL status, wait for terminal states, and save failed URL details for selective retry.
Images show a challenge, login, or access denied page	The target returned a restriction or session-dependent page to the capture environment.	Confirm the URL and required region/session behavior with the provider. Do not assume generic API support guarantees marketplace access.
The page is blank or incomplete	Capture happened before client-rendered content or lazy content appeared, or the page failed to load.	Try a documented wait condition or full-page option; inspect the capture status and compare a representative manual visit.
Some captures use a different layout	Viewport, user agent, geography, cookies, or per-URL overrides differ.	Set consistent supported options and store effective settings in the result manifest.
Polling or webhooks seem to miss completion	Incorrect status route, polling interval, callback configuration, or non-idempotent event handling.	Follow the provider’s job lifecycle documentation, verify callback delivery and signatures if supported, and reconcile against final job status.
Downloads cannot be matched to input rows	Archive order or provider filenames were assumed to correspond to submission order.	Use response identifiers or an explicit manifest mapping each URL/product ID to its result.
Usage is higher than expected	A vendor may count attempts, screenshots, or other units differently, and plan quotas can change.	Check current billing definitions and usage reporting before scaling; compare billed status with each result where available.

Performance, reliability, and cost

Overall completion time depends on queueing, concurrency, target response time, wait settings, image size, and provider limits. A large batch may be accepted quickly but still take time to render. Use bounded concurrency and chunk size, then measure your own representative workload; the cited vendor limits are not throughput benchmarks.

For reliability, persist input rows before submission, save the batch/job ID immediately, and write each terminal result as it arrives. This allows recovery after a client restart without submitting the entire list again. Use a bounded retry policy and retain failed outcomes so the run is auditable.

Estimate spend from the provider’s current definition of a billable capture, expected URL volume, retries, and plan allowance. Check whether failed attempts, cache hits, or asynchronous jobs affect billing. Screenshot API’s listed free quota above is a dated vendor detail, not a market-wide reference. ScreenshotNeo states that only clean shots are billed: bot checks/CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and its response includes X-Page-Verdict and X-Billed headers. Its published plans are Free: 1,000 shots/month; Starter: $5 for 3,000; Growth: $15 for 15,000; Pro: $39 for 60,000; Scale: $99 for 250,000; Business: $249 for 1,000,000. Yearly billing gives two months free. All features are on every plan; see the docs for API details.

FAQ

Does batching mean all URLs render at the same time?

No. A batch can be queued and processed in the background. Check whether the provider exposes progress, per-URL status, or completion events.

Can I use the same batch size with every provider?

No. Limits and the meaning of a request or capture vary. Use the current documentation for the selected API.

Does a screenshot API guarantee Amazon.in or Flipkart compatibility?

No. Generic API documentation does not establish marketplace-specific rendering. Validate your actual URLs and requirements.

Should I use Flipkart’s seller API to take product screenshots?

No. Its listing API provides seller catalog data. It is distinct from a browser screenshot service.