How to use Make HTTP modules to capture a website screenshot
Capture rendered website screenshots from Make with an HTTP module. Configure authentication, map the response, handle failures, and route the image to the next step.
To capture a rendered website screenshot in Make, use HTTP > Make a request to call an API that explicitly renders webpages into images. A normal HTTP request to a page URL downloads its response; it does not take a browser screenshot by itself. Configure the method, authentication, target URL, and capture options from the screenshot API’s documentation, then route its response according to whether it returns JSON, a redirect, or image bytes.
This guide covers the generic Make workflow and uses one documented API contract as an example. API field names and response formats vary by provider, so adapt the example to the service you choose.
1. Choose a screenshot API and inspect its response
First confirm that the service actually renders a page in a browser and returns a screenshot. Check its API reference for:
- HTTP method and endpoint
- Authentication format
- Required target URL field and optional capture settings
- Whether the response is JSON, a redirect to a file, or image bytes
- Supported image or document formats and viewport controls
- Timeout behavior, usage limits, pricing, and file retention
For example, the cited Screenshot API documentation describes POST /api/v1/screenshot with a JSON body containing a required url. It returns JSON by default and documents redirect=1 as an option that returns a 302 redirect to an image or PDF. This is that API’s contract, not a standard shared by screenshot providers.
Make also lists a native Create a Screenshot of a URL action in its HTML/CSS to Image integration directory, and a GetScreenshot app page lists a Take Screenshot action. Those may suit a simple scenario. Use HTTP when your chosen provider has no native Make action or when you need custom request settings. Check the current module availability and the vendor’s documentation before building around a native integration.
2. Configure Make HTTP > Make a request
- Add the HTTP > Make a request module to your scenario.
- Set the URL to the screenshot provider’s documented endpoint, beginning with
https://. - Choose the HTTP method the provider requires. For the example API, use
POST. - Set the body type to JSON if the API expects JSON. Map fields with a data structure or provide a raw JSON body. A data structure can map values and escape reserved JSON characters.
- Enter the target page URL in the provider’s required field. Map a URL from an earlier scenario module when the page changes per bundle.
- Add only capture options that the provider documents, such as format or viewport dimensions.
- Set authentication using Make’s dedicated Credentials field when supported. Make recommends this over putting credentials in ordinary headers or query parameters.
- Set a timeout suited to the render and enable handling for 4xx and 5xx responses so failed calls do not flow onward as if they were images.
Make’s HTTP app documentation describes HTTP Version 4 and the Make a request, Download a file, and Resolve URL actions. Its HTTP modules require HTTPS and reject unverified self-signed certificates.
3. Example request structure
Use the following only when the API you selected documents the same method, endpoint, authentication, and fields. The example API uses bearer authentication and a JSON request with a URL. Replace the endpoint and field names if your provider’s reference differs.
POST https://example-provider.invalid/api/v1/screenshot
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
{
"url": "https://example.com"
}In Make, map the target URL into the JSON url value. Store the key in the credential field where possible; do not place a live key in a scenario log, public URL, or shared screenshot.
4. Route the response to the next module
Run the scenario once with a page you are allowed to capture, then inspect the module output. Make can parse a response so its fields become mappable after a run. Choose the next step based on the actual response shape:
| Response | Next step | Check |
|---|---|---|
| JSON containing an image or file URL | Map that URL into HTTP > Download a file, then pass the resulting file data to the destination module. | Confirm whether the URL expires and whether it requires authentication. |
| Redirect to an image or PDF | Follow the provider’s documented redirect behavior or use its documented redirect option and then download the resulting file. | Check the final URL and content type; do not assume Make exposes the redirect as a file automatically. |
| Image bytes returned directly | Use the response as file data if the module exposes it in a format the next app accepts. | Verify the content type and that the response is not an error body. |
For the example Screenshot API, JSON is the default response, while its documented redirect=1 option redirects to the image or PDF. Follow the provider’s instructions for the exact response handling.
5. Add capture settings only when needed
Capture settings are provider-specific. The cited example documentation describes formats including PNG, JPEG, WebP, and PDF, along with optional viewport dimensions. Other providers may expose different controls. Before mapping an option into Make, confirm its exact field name, accepted values, defaults, and interactions in that provider’s reference.
Consider these questions when setting up the request:
- Image or PDF: Does the next scenario step need an image file, or a paginated document?
- Viewport: Does the screenshot need to match a particular screen size? A viewport capture and a full-page capture are different requirements.
- Dynamic content: Does the page need time to render data or load images before capture? Use a documented wait option if available.
- Per-item settings: Should the URL or capture settings be mapped from each incoming bundle, or remain fixed?
- Output handling: Does the provider return a temporary URL, bytes, or a redirect, and how long is that output available?
6. Handle errors, retries, and scenario behavior
Make provides a timeout setting from 1 to 300 seconds and an option to stop a scenario on 4xx or 5xx responses. Choose a timeout that fits the provider’s documented render time. Treat non-success responses as failures; do not map an error response into a file step.
- For a transient network or server error, use a deliberate retry or error route if appropriate for your scenario and provider limits.
- For authentication or request validation errors, correct the credential or payload before retrying.
- For a timeout, determine whether the provider timed out, Make timed out, or the target page remained slow. Raising the Make timeout alone cannot fix a provider-side limit.
- For a failed downstream download, check whether the image URL expired, needs credentials, or points to an error page.
Make requires HTTPS for HTTP requests and does not accept unverified self-signed certificates. A certificate problem needs a valid certificate at the endpoint; it is not a reason to disable TLS verification.
Common problems and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| The result is HTML or JSON, not a screenshot | The request went to the webpage itself, or the API returned its default JSON response. | Call a documented screenshot-rendering endpoint. Inspect the response and use the provider’s documented file URL or redirect flow. |
| 400 or 422 response | A required field is missing, the JSON is malformed, or a setting uses an unsupported value. | Compare the request method, content type, required fields, and option values with the provider’s API reference. Use a Make data structure if you want mapped fields escaped for JSON. |
| 401 or 403 response | The key is missing, invalid, expired, or sent in the wrong authentication format. | Check the provider’s authentication instructions and Make credential configuration. Avoid exposing the key in logs or URLs. |
| Scenario times out | The render takes longer than the configured timeout, or the provider or target page is slow. | Set a suitable Make timeout within its 1–300 second range, then check the provider’s own limits and target page behavior. |
| Download module cannot fetch the result | The response URL may be temporary, protected, malformed, or not actually a file URL. | Inspect the returned field, required headers, expiry, and content type. Follow the provider’s download instructions. |
| TLS or certificate error | The endpoint uses HTTP or an unverified self-signed certificate. | Use an HTTPS endpoint with a valid certificate. |
| Scenario continues with an error payload | The response was not checked before mapping it to a file or downstream action. | Enable the HTTP module’s stop-on-4xx/5xx behavior or route errors separately, then verify the response status and body. |
Performance, reliability, and cost
Screenshot rendering takes longer than fetching a static API response because the provider must load and render the target page. Set Make’s timeout based on the provider’s documented behavior and avoid adding unnecessary capture settings that increase work. If your scenario processes many URLs, account for the provider’s limits and Make operations when choosing the batch size and schedule.
Reliability depends on the screenshot provider, the target website, and the response handoff. A page can be unavailable or slow, and a temporary image URL can expire before a later module fetches it. Check status codes, retain enough response detail to diagnose failures, and confirm the output is a file before passing it onward.
The research sources do not establish a current comparable survey of screenshot API prices, quotas, reliability, or retention. Check the provider’s current pricing and terms for your expected capture volume. Also account for Make plan limits and the number of scenario operations involved in each run.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. Its API uses one GET request to return a screenshot or PDF. For example, this cURL request saves a WebP screenshot:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpFor Make, configure an HTTP request to the same endpoint with query parameters access_key and url; set the target URL from your scenario data and handle the returned file according to Make’s module output. See the ScreenshotNeo API documentation for request details.
ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers report the page verdict and billing status. Its MCP server lets AI agents use screenshot tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.
Sign up for ScreenshotNeo’s free plan to get 1,000 screenshots a month with no card.
FAQ
Can Make’s HTTP module take a screenshot by itself?
No. It sends an HTTP request. The endpoint must belong to a service that renders a webpage into a screenshot.
Should I use Make a request or Download a file?
Use Make a request to call the screenshot API. Use Download a file when the API gives you a file URL that must be fetched in a separate step.
Can I send an API key as a query parameter?
Only if the provider supports it. Prefer Make’s dedicated credential handling when available, and avoid putting secrets in URLs because URLs can appear in logs.
Does every screenshot API use the same JSON fields?
No. Method, authentication, field names, output type, and capture options depend on the provider. Follow the selected provider’s current API documentation.
Can I use a native screenshot integration instead?
Make’s integration directory lists a Create a Screenshot of a URL action for HTML/CSS to Image, and a GetScreenshot app page lists Take Screenshot. Check each integration’s current availability and setup instructions.
