How to Pass JavaScript Rendering Options to a Screenshot API with Make

To pass JavaScript rendering options from Make, use an HTTP request module to send the target page URL and the option in the exact request field documented by your screenshot API. The field name and request format are provider-specific. In the RenderScreenshot example below, send a JSON POST request and put injected scripts in page.scripts.

This guide uses RenderScreenshot as a worked example, not as a universal API schema. For another provider, replace its endpoint, authentication, request body, and response handling with the values in that provider’s current documentation.

1. Choose a Make module and confirm the API contract

Use a provider’s native Make app if it exposes the JavaScript option and the other controls your scenario needs. A native action can reduce setup. Make lists screenshot actions such as webpage and element captures. If the native module does not expose the required option, use Make’s HTTP app to call the provider’s API directly.

Before building the scenario, check the selected API reference for these details:

Endpoint and HTTP method.
Authentication method and where to store the credential.
Content type and body format.
The exact JavaScript injection field and accepted value types.
Whether the result is binary image/PDF data, a URL, or JSON.
Any rendering waits, execution constraints, size limits, and cache behavior.

Make constructs and maps the request; the screenshot provider defines what its options mean. Do not assume a field accepted by one API works with another.

2. Configure the HTTP request in Make

Add an HTTP > Make a request module to the scenario.
Set the method to POST and the URL to https://api.renderscreenshot.com/v1/screenshot.
Configure the authorization header as Authorization: Bearer YOUR_API_KEY. Store the real key in Make’s credential or keychain facility where available; do not place it in a shared scenario body.
Set the body content type to application/json. Make’s HTTP module can use a structured data body with key-value fields, which is useful when mapping values from earlier modules.
Include the required page url and the provider’s documented JavaScript option.

For RenderScreenshot, the JavaScript field is page.scripts. It accepts script strings or objects containing a script URL.

3. Send an injected JavaScript string

This example sets a page variable before capture. Replace the page URL and script with values suitable for your target. Only inject code into pages and workflows where you are authorized to do so.

{
  "url": "https://example.com",
  "page": {
    "scripts": [
      "window.exampleFlag = true;"
    ]
  }
}

In Make’s structured body editor, represent page as an object and scripts as an array if the interface offers those types. If you use a raw JSON body, preserve valid JSON quoting and escaping. A JavaScript string containing quotes, backslashes, or line breaks must be escaped for JSON.

4. Load an externally hosted script

RenderScreenshot also documents an object form for a script hosted elsewhere:

{
  "url": "https://example.com",
  "page": {
    "scripts": [
      { "url": "https://example.com/script.js" }
    ]
  }
}

Use the form documented by the selected provider. Confirm that the script URL is reachable by the rendering service and that the target page’s policies and application behavior allow the intended execution.

5. Map dynamic values from earlier modules

For a production scenario, map the destination URL, script value, or script URL from prior Make modules rather than hard-coding them. Keep the JSON structure fixed and map only the values that should vary. This makes it easier to inspect failed bundles and reduces malformed-body mistakes.

Validate incoming URLs before sending them to the screenshot API.
Use a controlled script value; do not concatenate untrusted input into executable JavaScript.
Keep credentials in secure connection settings or the platform’s credential store.
Run the module once with a known page and inspect the input and output bundle before connecting downstream steps.

6. Handle the screenshot response

RenderScreenshot documents a successful response as screenshot binary with an image or PDF content type, and it may include an X-Cache-URL response header. In Make, inspect the actual module output and map the binary data and a filename into the next file-handling module.

If your chosen API instead returns JSON containing a file URL, add an HTTP download step to retrieve the file before passing it to storage, email, or another downstream module. Do not assume that a header or response format from one provider applies to another.

7. Other options you may combine with JavaScript

The RenderScreenshot request reference lists options beyond script injection. Names, valid values, defaults, and limits can change, so verify them against the current reference before using them.

Need	What to check in the provider API
Style the page	Whether it accepts page styles or CSS injection, and how those fields interact with scripts.
Control dimensions	Viewport width and height, device scale, and any device presets.
Select output	Image versus PDF, supported formats, quality settings, and PDF page setup.
Interact before capture	Whether a selector can be clicked and how long the page waits afterward.
Clean up the result	Selectors to hide or remove, and options for cookie banners, ads, trackers, or chat widgets.
Control loading	Selector waits, fixed delays, network-idle waits, and behavior when a wait expires.
Reuse work	Whether caching is available and how to set its TTL.

Add only options needed for the workflow. More injected code and longer waits can increase capture time and add failure points. If scripts depend on a page element, use the provider’s documented wait controls where available rather than relying on an arbitrary short delay.

8. Troubleshoot common failures

Symptom	Likely cause	What to do
HTTP 401 or 403	Missing, malformed, or invalid credentials, or an account permission issue.	Check the provider’s required authentication scheme, confirm the key is current, and ensure the header is sent on this request.
HTTP 400 or 422	Wrong JSON shape, incorrect field name, invalid script value, or missing required URL.	Compare the request with the provider schema. For the worked example, use `page.scripts` as an array and include `url`.
Invalid JSON	Unescaped quotes, backslashes, or line breaks in a raw body, or Make mapped a value into the wrong type.	Use Make’s structured body fields where practical. Test with a minimal static body, then map fields one at a time.
Screenshot looks unchanged	The script did not load or run, it ran before the needed page state existed, or it changed something outside the captured area.	Check the script URL and page behavior. Add the provider’s supported wait or interaction option, and verify the script effect on the target page.
Blank or incomplete capture	The page was still loading, required content is below the fold, or scripts failed at runtime.	Use a supported selector or network-idle wait, check the target URL and application errors, and confirm the API’s full-page settings if needed.
Make cannot map the file downstream	The response is binary but the next module expects a URL or a file object, or the API returns a URL rather than bytes.	Inspect the run output. Map the binary data and filename for a binary response; download the returned URL first when the API responds with a link.
Request times out	The target page or script takes too long, or the scenario’s timeout is shorter than the provider’s render time.	Use a lighter page or script, remove unnecessary waits, and check the timeout limits on both the API and Make module.

9. Performance, reliability, and cost considerations

Keep scripts focused. Inject only what the capture requires. Heavy scripts can delay rendering, change page behavior, or fail when the page’s expected libraries are not available.
Wait for a condition when possible. A selector wait can be more reliable than a fixed delay when the page loads at variable speeds. Follow the provider’s documented timeout and fallback behavior.
Make the workflow observable. Keep the API response headers and status available for troubleshooting, and inspect Make’s scenario run bundle when a downstream mapping fails.
Plan retries carefully. Retry transient network or provider errors according to the provider’s guidance. Repeatedly retrying invalid requests or deterministic script errors wastes operations and may repeat billable captures.
Check caching and billing terms. Cache behavior, cache TTL, and whether cached responses are billed vary by provider. Read the selected provider’s pricing and API documentation; do not infer billing from a cache header alone.
Count scenario operations too. A workflow may use Make operations for the request, downloads, and storage even when the screenshot provider charges separately. Estimate both services’ usage for high-volume scenarios.

10. Or skip the browser setup

If the goal is a clean screenshot rather than managing a rendering browser and script timing, ScreenshotNeo offers a screenshot API and MCP server. It accepts one GET request with a URL and returns PNG, JPEG, WebP, or PDF. See the ScreenshotNeo API documentation for its request options and parameter names.

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}`);

In Make, configure an HTTP GET request to https://api.screenshotneo.com/v1/shot, pass access_key and url as query parameters, and map the returned file data according to the module output. ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before capture; bot checks, blank pages, failed loads, timeouts, and cache hits are never billed. Its response identifies the page verdict and billing status in headers. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

Create a free ScreenshotNeo account to get 1,000 screenshots a month with no card.

11. Frequently asked questions

Can I use this exact JSON with any screenshot API?

No. The endpoint, authentication, body format, field names, and response type belong to each provider. The examples using page.scripts apply to the RenderScreenshot schema described here.

Should I send JavaScript as a string or a URL?

Use whichever form the provider supports. RenderScreenshot documents both a JavaScript string and an object with a script URL in its scripts array.

How can I tell whether Make received a file or a link?

Run the HTTP module and inspect the output bundle, response content type, and headers. Then choose a downstream file mapping or a download step based on the actual response.

Can a native Make screenshot module pass injected scripts?

That depends on the specific app and action. Check its available fields; use a direct HTTP request when the option is absent and the API documents it.

References

Make HTTP app documentation for configuring requests and JSON bodies.
Make file handling guidance for passing file data and downloading files.
RenderScreenshot API documentation for its endpoint, authentication, scripts field, options, and response format.