How to Add a Delay Before an Abstract Screenshot API Capture

To add a fixed wait before an Abstract Website Screenshot API capture, include the optional delay query parameter in milliseconds. For example, delay=1000 represents a 1,000 millisecond (one second) wait. Abstract advertises capture delays and custom timing; the exact parameter name, unit, and example are documented in a generated API reference. The available sources do not establish a supported range, default, or guarantee that a delay waits for a particular script or page state.

What the delay does

Abstract’s Website Screenshot API is a REST service that turns a URL into an image. Its product page describes capture delays and custom timing. The parameter reference describes delay as the number of milliseconds to wait before taking the screenshot and gives 1000 as an example. See the Abstract Website Screenshot API and the generated API reference maintained by APIs.io.

A fixed delay adds time before capture. It does not, based on the documentation reviewed, mean “wait until this selector appears,” “wait until network traffic stops,” or “wait until my application says it is ready.” A page may still be incomplete after the chosen interval, and a page that is already ready will simply wait longer.

Build the request

1. Get an Abstract API key and identify the URL to capture.
2. Add the documented delay parameter with an integer number of milliseconds, such as 1000 for one second.
3. Send the request using Abstract’s current endpoint and required parameters from its documentation. The complete official request syntax and the interaction between delay and navigation events were not confirmed in the sources reviewed.
4. Inspect the returned image to see whether the chosen wait captures the content you need.

Parameter fragment, based on the generated reference (illustrative, not a tested complete request):

&delay=1000

Do not copy that fragment as a full URL by itself. Add it to the request URL and parameters required by Abstract’s current API documentation. This guide does not assume an endpoint path, key parameter name, or response format beyond what the reviewed sources confirm.

Choose a delay

There is no documented universal value that works for every page. Start with the shortest wait that consistently includes the content you need, then check captures of the slowest relevant pages and conditions. The reference’s 1000 example is a syntax example, not a performance recommendation or readiness guarantee.

Situation	How to think about the wait
Static page	A delay may be unnecessary if the page is ready when the capture service reaches it.
Content appears shortly after initial rendering	Try a modest fixed wait and inspect the output. Increase it only if the content is still missing in repeat captures.
Third-party or unpredictable loading	A longer fixed wait can still be unreliable: the resource may be delayed beyond it or fail entirely. The reviewed Abstract sources do not confirm a selector-based wait or another readiness condition.
Time-sensitive page	Remember that the captured page may change during the wait. Validate that the resulting image reflects the state your workflow expects.

Because the available reference does not state accepted bounds or a default, do not assume that zero, negative values, very large values, or omitted delay have any particular behavior. Check Abstract’s current API documentation for validation rules before relying on those cases.

Common problems and fixes

Symptom	Likely cause	What to do
The screenshot still misses dynamic content	The fixed wait ended before that content appeared, or the resource failed.	Compare captures at a few reasonable waits and inspect the target page’s loading behavior. A delay alone cannot prove that an element is ready.
The screenshot is slower than expected	The configured wait adds time before the capture.	Reduce the delay to the smallest value that works for the pages you capture, or omit it where it is not needed.
The request rejects the parameter	The parameter may be malformed, placed incorrectly, or subject to validation not described in the sources reviewed.	Confirm the spelling delay, encode the request parameters correctly, and check Abstract’s current reference for accepted values.
The result is unchanged after adding delay	The page may already have been ready, or the missing element may not load successfully.	Check the target page independently and verify the request actually includes the parameter.
The captured content varies between requests	Page rendering and external resources can vary; a fixed interval does not synchronize with application readiness.	Use a consistent target and repeat observations. If exact state control is essential, verify whether the current API offers a suitable readiness mechanism before designing around one.

Performance, reliability, and cost

A configured wait adds at least that waiting interval to the capture workflow, so a longer delay can reduce throughput or increase end-to-end time when requests are sequential. The available sources do not establish Abstract’s concurrency behavior, pricing impact, or whether delay affects billing; check the current plan and API terms for those details.

For reliability, select a value using the slowest pages that matter to your use case, then monitor for missing content. A fixed delay is simple and predictable as a timer, but it is not a guarantee of page readiness. Avoid setting an unnecessarily long delay globally when only some pages need extra time.

Or skip the browser setup

ScreenshotNeo offers a one-call screenshot API and an MCP server for AI agents. Its capture flow accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and responses identify page verdict and billing status in headers. The MCP tools include take_screenshot, get_page_info, and capture_pdf.

See the ScreenshotNeo website and API documentation. Example request:

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

Python:

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)

Node.js:

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 image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed; an MCP server lets AI agents take screenshots; and 1,000 screenshots a month are free with no card, with paid plans starting at $5 for 3,000. Sign up free for ScreenshotNeo.

FAQ

How many milliseconds should I set?

There is no universal value in the reviewed documentation. The reference uses 1,000 milliseconds as an example; choose and verify a value against the pages and content you need.

Does delay=1000 mean the page is fully loaded?

No such guarantee is documented. It specifies a fixed wait before capture, not completion of every script, image, or asynchronous request.

What is the maximum delay?

The available sources do not confirm a maximum or other accepted range. Consult Abstract’s current API reference before relying on a particular bound.

Is the delay required?

No. The parameter is described as optional. Add it when a fixed additional wait helps your capture workflow.