How to Fix an Expired Screenshot API URL in a Make Workflow

If a screenshot URL fails in a Make workflow, first identify which service issued that URL and inspect the value returned by the screenshot step. There is no universal expiry period or fix: the URL might be temporary, deleted, restricted by the provider account, mapped from an older run, or failing for an unrelated HTTP reason. If you need the image to remain available independently of the screenshot provider, download it during the workflow and save the file to storage you control.

1. Identify which URL is failing

A screenshot workflow can contain two different URLs:

Source page URL: the web page sent to the screenshot service to be captured.
Output image URL: the location returned by the service for the generated screenshot.

Check the failed module’s input and determine which one it received. A downstream module that expects an image may have been mapped to the original page URL, an output URL from an earlier execution, or the wrong field altogether.

Then inspect the output URL’s host. The service that issued it controls its retention, deletion, account, and access rules. Check that provider’s current documentation before assuming the link expires after a particular time.

2. Inspect the Make execution

Open the scenario’s execution history and select the run that failed.
Open the screenshot API or app module. Confirm it completed successfully and inspect its output bundle.
Record the returned image URL and, if present, the image identifier. Verify that the downstream module maps the output from this execution.
Open the next module’s input bundle and inspect the actual URL or file data it received. Check for an old saved value, a missing mapping, or a source page URL in place of the generated image URL.
Inspect the HTTP status and response body from the failed request. This helps distinguish a provider response such as 404 or 403 from a successful image download followed by an error in a later module.

Make’s HTTP app supports API requests, file downloads, and URL resolution. HTTP v4 requires HTTPS and can be set to return an error when a request receives a 4xx or 5xx status. Its settings differ from the legacy HTTP app, which Make identifies as version 3. If you use HTTP v4, check that the module is configured for the intended request or file-download action and that the URL uses HTTPS. Make HTTP documentation.

3. Check the provider’s retention and access rules

Do not infer a link’s lifetime from its appearance or from another screenshot service’s behavior. Check the documentation for the host in the output URL, and look for:

How long generated images are retained.
Whether images depend on an active account or subscription.
Whether a user or workflow can delete the image.
Whether the link needs authentication or has access restrictions.
Whether the response is a direct image URL or a page that redirects to a file.

For HTML/CSS to Image (HCTI) specifically, its FAQ says a generated image URL remains accessible as long as the HCTI account is active. HCTI also documents that deleting an image removes it from its servers and CDN cache. Those rules apply to HCTI; do not assume another provider uses the same retention policy. See the HCTI FAQ and HCTI API documentation.

4. Fix the Make mapping or regenerate the screenshot

Once you know what failed, take the matching action:

The mapped URL is stale or from a prior run: remap the downstream module to the image URL returned by the screenshot step in the current execution.
The mapped field is the source page URL: select the screenshot step’s output image URL or image identifier, according to what the next module accepts.
The provider reports that the image is missing or was deleted: run the screenshot step again and pass its newly returned image URL downstream.
The provider requires an active account: check the account status and access permissions with that provider.
The next module needs file data rather than a URL: download the returned image and map the downloaded file data forward.

Make lists HTML/CSS to Image actions for creating a screenshot of a URL and getting an image. The exact available fields depend on the module and its output. Check the execution bundle rather than guessing the field name. Make’s HTML/CSS to Image integration listing.

5. Download and store the image for longer-lived access

If a later step needs a durable copy, use Make’s HTTP file-download action on the current image URL and send the returned file data to a storage service connected to your scenario. This adds a workflow step, but makes the image available under the destination’s retention rules rather than depending only on the screenshot provider’s hosted URL.

After the screenshot step, add an HTTP file-download module.
Map the screenshot step’s newly returned image URL into the download URL field.
Check the download result for file data and a successful HTTP response.
Map that file data into the upload or storage module you use.
If later modules require a URL, use the URL returned by your storage destination.

Choose between keeping the provider-hosted URL and saving a separate file based on the provider’s retention and account rules, how long you need the image, and whether downstream modules accept URLs or file data. Make documents that its HTTP file-download module downloads a file from a URL and exposes file data to other modules. Storage choice and retention depend on the service you connect. Make HTTP documentation.

6. Common errors and fixes

Symptom	Likely cause	What to check or do
404 or an image-not-found response	The image was deleted, the URL is incorrect, or the provider no longer has that image.	Verify the exact URL and image ID from the screenshot step. Check provider deletion and retention rules; regenerate the screenshot if needed.
403 or an authorization response	The URL or account may be access-restricted, or the provider may require authentication.	Check the provider’s current access requirements and account status. Keep API credentials in Make’s credential storage, not in a public URL or an ordinary mapped field.
The screenshot step succeeds, but a later module fails	The later module may receive an old output, the source URL, or a field of the wrong type.	Inspect that module’s input bundle and remap it to the current image URL or file data it expects.
HTTP module reports a 4xx or 5xx error	The provider returned an HTTP error, or the request is configured to stop on such responses.	Inspect the status and response body. Confirm the URL, access requirements, and request method; in HTTP v4, check the “Return error if HTTP request fails” setting.
Redirect handling does not produce the expected image	The supplied URL may redirect, or the downstream service may not accept the resolved destination.	Inspect the response and use Make’s URL-resolution capability only when you need to examine a redirect. Resolving a URL does not extend the provider’s image retention.
The image works once, then is unavailable later	The workflow relies on provider hosting, which may depend on provider-specific retention, account, or deletion rules.	Check the provider’s documentation. Download the image during the same run and save it elsewhere if you need a separate copy.

7. Performance, reliability, and cost considerations

Keep related steps in the same run: capture the page, use the returned output, and download it before passing it to storage. This avoids accidentally reusing a URL saved by an earlier run.
Use file data for file destinations: if the destination accepts an uploaded file, passing the downloaded file data avoids making later steps depend on a provider-hosted image URL.
Handle failures at the step that can explain them: inspect the screenshot response separately from the image-download response. A successful capture does not prove a later download or upload succeeded.
Keep credentials private: use Make’s credential storage for API authentication rather than putting secrets in a URL or ordinary mapped field.
Account for extra workflow work: downloading and storing an image adds modules and uses the connected services’ storage and execution resources. The cited documentation does not establish a universal cost or timing; check the current terms for your Make plan, screenshot provider, and storage destination.

8. Or skip the browser setup

If you want a direct screenshot API call instead of configuring a browser, ScreenshotNeo returns an image or PDF from one GET request. See the ScreenshotNeo API documentation for 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}`);

Cookie banners are accepted and removed before the shot, along with known newsletter popups and chat widgets.
Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed; response headers identify the page verdict and billing status.
An MCP server lets AI agents use the take_screenshot, get_page_info, and capture_pdf tools.
The Free plan includes 1,000 screenshots per month without a card; paid plans start at $5 for 3,000 screenshots.

FAQ

Does Make itself decide when a screenshot URL expires?

The URL’s retention is controlled by the service that issued it. Make passes the mapped value to a module; inspect the provider’s rules and the value in the execution bundle.

Will Make’s Resolve URL module extend an image’s lifetime?

No. URL resolution can help inspect a redirect, but it does not change the issuing provider’s retention or deletion policy.

Should I retry the failed request?

A retry can help with a transient request failure, but it cannot restore a deleted image or correct a stale mapping. First inspect the response and URL, then retry or regenerate as indicated by the provider’s rules.

How do I avoid relying on the hosted URL later?

Download the image during the scenario and save the file in a storage service whose retention suits your needs.