How to Capture a Webpage Screenshot with a Delayed Render in Make

To capture a webpage after its content finishes rendering in Make, add the GetScreenshot app’s Take Screenshot module, connect it with your GetScreenshot API key, then set Additional Wait Time in advanced settings. For slow pages, try a stricter Wait Until condition and start with 3,000–5,000 ms of extra wait. If images or sections appear only after scrolling, enable Scroll Page First. Increase the wait gradually and account for the vendor’s documented 30-second endpoint timeout.

1. Set up the Make scenario

1. Add the GetScreenshot app to a scenario and choose Take Screenshot. The app also lists Take Element Screenshot for a CSS-selected element, plus email-delivery and usage actions.
2. Create a GetScreenshot account and API key, then create a connection in Make with that key. The integration guide says Make access requires a Hamilton plan or higher; check your account for current plan requirements because vendor plans can change.
3. Map the webpage URL into the module. Choose full-page capture or a viewport size appropriate for the page and downstream use.
4. Open advanced settings and configure the render wait as described below.
5. Connect the resulting screenshot to the next module, such as cloud storage, email, or a team-sharing destination. Save the file somewhere durable if it must be retained.

For a single element, use the element screenshot action and provide its CSS selector. For a full page, use the regular screenshot action and enable the full-page option if needed. The exact fields shown can depend on the app version; use the current module labels in your Make account.

2. Tune delayed rendering

Choose a navigation wait condition

Wait Until controls which navigation or network condition the capture waits for. Rasterwise’s API reference lists load, domcontentloaded, networkidle0, and networkidle2; it documents networkidle2 as the default. A stricter network-idle condition may allow content that arrives after the DOM is ready to appear. However, analytics, polling, or other persistent requests can prevent strict network idle from occurring promptly. If the page keeps making requests, use a less strict condition and a measured fixed wait.

Condition or setting	Use it when	Tradeoff
domcontentloaded	The page’s initial HTML is enough to begin rendering.	Late scripts, images, and data may still be missing.
load	You want the browser load event, including ordinary dependent resources.	Client-rendered or delayed content may still arrive later.
networkidle2	The page settles while allowing a small number of active requests.	May take longer than DOM readiness.
networkidle0	The page becomes fully quiet and the target page does not keep requests open.	Persistent network activity can make the wait slow or cause a timeout.
Additional Wait Time	Known scripts, widgets, or data need a little longer after the navigation condition.	Every extra second adds latency and increases timeout risk.

Set the extra delay

Use the smallest fixed delay that reliably includes the content you need. Rasterwise’s Make guide suggests about 3,000–5,000 ms as a starting point for slow pages. Its API reference describes timewait as extra milliseconds after the service’s render flow, gives a 2,000 ms default, and suggests starting at 5,000 ms and increasing in 1,000 ms steps. These are vendor recommendations, not guarantees for every site.

1. Start with the default behavior and inspect whether the missing content is actually late-rendered.
2. Select an appropriate Wait Until condition. If the page continues loading asynchronous content, try network idle; if requests never settle, choose a less strict condition.
3. Add 3,000–5,000 ms and capture again.
4. If content is still missing, increase by 1,000 ms per attempt and stop once the target content appears consistently.
5. Keep the complete capture under the documented 30-second endpoint timeout. A longer wait is not a fix if the page itself is blocked or never renders.

3. Account for lazy-loaded content

Lazy-loaded images and sections may not be requested until they approach the viewport. A longer wait alone will not trigger them. Enable Scroll Page First so the capture flow scrolls and gives those elements a chance to load before the screenshot. Then check the bottom and intermediate sections of a full-page image; a page can have a complete document height while some lazy images remain unloaded.

For pages that load content only after a particular interaction, a scroll may not be sufficient. Check whether the site requires a click, consent action, login, or other user event. Do not assume a screenshot service can access a protected page simply by waiting.

4. Route and retain the image

Use the screenshot module’s output in a subsequent Make module. Common flows save the file to cloud storage, attach it to an email, or share it with a team. Confirm the destination receives the image as a file or binary payload, rather than a temporary URL that the next module cannot fetch.

Rasterwise’s API overview says its screenshot files are available for 30 days before deletion. If the Make workflow needs longer retention, copy the file to durable storage as part of the scenario rather than relying on the provider’s temporary copy.

5. Use Make HTTP for direct API control

A custom HTTP route can be useful when you need parameters not exposed by the dedicated app module or want to handle an API response yourself. Make’s HTTP app supports HTTPS requests, credentials, and a configurable request timeout from 1 to 300 seconds. It also offers a Download a file module for retrieving an image URL returned by an API. Use Make’s credential fields for secrets when the API’s authentication method supports them, rather than placing a key in an ordinary header or query field.

Rasterwise documents a GET screenshot endpoint and the timewait and waituntil parameters. Map the request URL and parameters in Make HTTP, then map the response or returned image URL into the appropriate download or storage step. Make’s HTTP timeout setting does not change the screenshot provider’s own endpoint timeout, which Rasterwise documents as 30 seconds.

The dedicated GetScreenshot app is the simpler starting point for a typical scenario because it provides built-in screenshot actions. HTTP is a more configurable route, but requires you to map request parameters, response handling, and error paths yourself.

6. Troubleshooting

Symptom	Likely cause	What to change
Late text or widgets are missing	The capture begins before client-side rendering or third-party content finishes.	Try a stricter Wait Until condition, add 3,000–5,000 ms, then increase in 1,000 ms steps if needed.
Lazy images or lower sections are absent	The page loads them only after scrolling.	Enable Scroll Page First. Check whether the content requires an interaction beyond scrolling.
Screenshot is blank	The page may rely on JavaScript, be blocked, or need more render time.	Try a longer wait and another Wait Until condition. Confirm the URL is publicly reachable and inspect whether the target renders in a normal browser.
Capture times out	The page is complex, the selected wait never resolves, or the added delay consumes too much of the endpoint window.	Reduce the wait, use a less strict condition if requests remain active, or simplify the target capture. For longer-running workflows, Rasterwise documents webhook delivery for its Make integration.
Image does not reach the next module	The next step expects a file but receives a URL or unmapped response.	Inspect the screenshot module output and map the binary/file field, or download the returned file URL before storage.
Connection or authentication fails	The API key or Make connection is missing, invalid, or the account lacks integration access.	Recheck the connection and current plan requirements in the provider account; recreate the connection if the key was rotated.
Login-protected page cannot be captured	The service cannot reach authenticated content with the current request.	Rasterwise documents experimental login automation but does not guarantee it. Avoid passing a normal personal password to a third party; use a restricted credential only if necessary.

7. Performance, reliability, and cost

Wait settings trade completeness for elapsed time. Rasterwise publishes average response times of 8,000–12,000 ms for simple websites and 15,000–22,000 ms for complex websites, along with a 30,000 ms endpoint timeout. These are vendor-published operating figures, not independent benchmarks, and a particular site can take longer or fail. Keep waits targeted, avoid network-idle conditions on pages with persistent connections, and route failures so one slow page does not silently derail an entire scenario.

For repeated captures, tune against representative URLs and record which pages need extra waits or scrolling. If a capture must run longer, the vendor’s Make guide describes webhook delivery as an option. Preserve the generated file in storage you control when it must outlive the provider’s 30-day availability window. Check the provider’s current plan, Make operation consumption, and storage costs for your own workload; pricing and plan details may change.

8. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request captures a URL as PNG, JPEG, WebP, or PDF. Its clean-shot 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 cleanup step can be turned off. Only clean shots are billed: bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, with the outcome reported in X-Page-Verdict and X-Billed headers. Its MCP server lets Claude, Cursor, and other MCP clients use take_screenshot, get_page_info, and capture_pdf.

Use the [ScreenshotNeo API documentation](https://screenshotneo.com/docs/) for request options and response details. This cURL request captures a page directly; change the URL and output extension to match the format you need.

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

The equivalent Python request:

import requests

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

And Node.js using built-in fetch:

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

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed. The 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. Sign up for free and get 1,000 screenshots a month with no card.

FAQ

Should I always use a longer delay?

No. Start with the shortest wait that includes the content you need. Excessive delays increase scenario duration and timeout risk.

Does waiting load content that appears only on scroll?

No. Use Scroll Page First for lazy-loaded content; time alone does not trigger scrolling behavior.

Can Make’s HTTP timeout override the screenshot API timeout?

No. Make can wait longer for a response, but it cannot extend the provider’s own endpoint limit.

What if one scenario captures many different sites?

Expect different render behavior per site. Use representative test URLs and tune the wait and scroll settings for the slow or lazy-loading pages in the workflow.