How to Use a Screenshot API Response in a Make HTTP Module
Configure Make’s HTTP module for a screenshot API, inspect the response, and map image URLs, JSON, or file data into the next step.
To use a screenshot API response in a Make HTTP module, configure HTTP > Make a request with the provider’s documented endpoint, authentication, and request parameters. Run the module once and inspect its output bundle. Then map the response according to its actual shape: a screenshot URL, JSON containing image data, or raw file data. These forms are not interchangeable, and the provider’s documentation and a real run determine the right mapping.
This guide uses a provider-neutral setup because the API and sample response were not specified. The steps follow Make’s [HTTP documentation](https://apps.make.com/http?output=1).
1. Configure the screenshot request
- In your Make scenario, add HTTP > Make a request.
- Use the request method and endpoint required by your screenshot provider. Many APIs accept a URL as a query parameter, but follow the provider’s documentation rather than assuming its parameter names.
- Set authentication, headers, query parameters, and body as the provider requires. In Make HTTP v4, use the dedicated Credentials field for authentication details where applicable.
- Set Parse response to Yes when you expect JSON or XML fields that you will map in later modules.
- Save the module and run the scenario once. Make exposes mappable response items after the module has run.
Make HTTP v4 requires secure HTTPS connections and rejects unverified self-signed certificates. Its request settings include a timeout from 1 to 300 seconds and an option to return an error for 4xx or 5xx responses. It can follow up to 10 redirects. Choose settings that match the provider’s documented behavior and expected capture time.
2. Inspect the output bundle before mapping
Open the completed HTTP module’s run details and inspect its output bundle. Identify the response status and content type, then determine which of these shapes the provider returned:
| Response shape | What to look for | Typical next step |
|---|---|---|
| JSON containing a screenshot URL | A JSON field with a URL. Its exact name depends on the API. | Map that URL into HTTP > Download a file. |
| JSON containing image data | A JSON field containing encoded data, such as a base64 string, if the provider documents that format. | Use the provider’s encoding instructions and the destination module’s input requirements to convert or pass the data. |
| Raw image response | The response itself is image content rather than a JSON object with a URL. | Inspect how Make represents the output and check what the next module accepts. Do not map a URL or text value where file data is required. |
| Error or non-image response | An error body, unexpected content type, or status indicating failure. | Fix the request or handle the error before sending the result to a file destination. |
3. Download a screenshot when the API returns a URL
If the HTTP response is JSON with a screenshot URL, add HTTP > Download a file after the request. Map the URL field shown in the actual output bundle into the download module’s URL input. The download module retrieves the file and makes its data available to later modules.
- Run the request module once and expand its JSON output.
- Add HTTP > Download a file.
- Map the URL field from the request bundle into the download module.
- Run the scenario and inspect the download module’s output.
- Map the resulting file data to the destination module, following that module’s expected file input.
Some providers return temporary or signed URLs. Check their documentation for expiration and access requirements, and download the file while the URL remains valid. Do not assume that a URL returned in JSON is a permanent public link.
4. Handle JSON image data or a raw image response
When the API returns image bytes directly, the response may not appear as a neat JSON field. Inspect the module’s run output and determine whether Make exposes file data that the next module can accept. When JSON contains encoded image data, use the provider’s documented encoding and the receiving module’s documented input format. A URL, a base64 string, and binary file data represent different things; passing one as if it were another commonly causes mapping failures.
If the output bundle does not make the representation clear, consult the screenshot provider’s response documentation and test with a single known URL. Avoid building downstream steps around a guessed field name or an assumed binary conversion.
5. Parse response: current and legacy HTTP modules
In the current HTTP app, Parse response structures a response so fields can be mapped more easily. Run the module once before configuring mappings so Make can expose the response items. The output field names and nesting still come from the API’s response schema.
If you are using Make’s legacy HTTP app, its documentation distinguishes raw response output from parsed output. Enable parsing and manually run the module once when you need Make to recognize JSON or XML fields. See the [legacy HTTP documentation](https://apps.make.com/http-legacy?stub=1).
6. Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| No response fields appear for mapping | The module has not completed a run, parsing is disabled, or the response is not structured JSON or XML. | Run it once successfully, enable Parse response for structured output, then inspect the bundle. For raw image output, use the representation shown in the run rather than expecting JSON fields. |
| The next module rejects the mapped value | A URL, encoded string, or binary file value was mapped into an incompatible input. | Check the destination module’s input requirements. For a screenshot URL, use Download a file and pass its file data onward. |
| The download step fails | The mapped URL may be wrong, inaccessible, expired, or not a direct downloadable resource. | Inspect the actual URL in the HTTP output, check provider requirements and expiration, and confirm that the URL can be fetched by the download step. |
| The request returns an HTTP 4xx or 5xx | The endpoint, method, credentials, parameters, or request body may be wrong, or the provider returned an error. | Compare the request with the provider’s documentation and inspect the response body. Configure Make’s 4xx/5xx error behavior deliberately so failures are visible or handled in the scenario. |
| The request times out | The capture takes longer than the configured timeout, or the provider is slow or unable to finish. | Choose an appropriate timeout within Make HTTP v4’s 1–300 second range, and check whether the provider offers an asynchronous capture workflow. |
| Make refuses the connection | The target connection may not use HTTPS or may present an unverified self-signed certificate. | Use a valid HTTPS endpoint with a verifiable certificate; Make HTTP v4 rejects unverified self-signed certificates. |
| The result is an error page or not an image | The screenshot provider may have returned an error response, or the request may not have produced a capture. | Inspect status, content type, and response body before mapping the result as an image. Handle errors as a separate scenario path where needed. |
7. Reliability, performance, and cost
- Confirm the response before continuing. Check status and output shape so an error body does not flow into a file or image module.
- Set a realistic timeout. Page rendering can take longer than a simple data request. Make HTTP v4 supports a configurable 1–300 second timeout; the screenshot provider’s behavior determines a suitable value.
- Account for redirects and secure connections. Make can follow up to 10 redirects and only accepts secure HTTPS connections in its current HTTP app.
- Keep data handling intentional. A returned URL may expire; a direct response may be binary; encoded image data may need format-aware handling. Store or forward the form that the next module accepts.
- Estimate workflow cost from the services involved. The dossier does not establish Make plan costs or costs for an unspecified screenshot API. Check each provider’s current pricing and avoid treating a successful Make operation as proof that a screenshot provider did not bill the capture.
Make also lists an [HTML/CSS to Image integration](https://www.make.com/en/integrations/html-css-to-image/http) with actions to create a screenshot of a URL and get an image. Compare those actions with an external API based on the capture options you need and the output your next module accepts; the available documentation does not establish feature parity or pricing.
8. Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. Make a GET request to its screenshot endpoint and send the returned image to the next step. See the ScreenshotNeo API documentation for request options and response handling.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpIn Make, configure HTTP > Make a request with method GET, URL https://api.screenshotneo.com/v1/shot, and query parameters access_key and url. Follow the docs for mapping its image response into the next module.
ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.
Sign up free for 1,000 screenshots a month, with no card required.
FAQ
Can I map a screenshot URL directly into a file upload?
Only if the receiving module accepts a URL. If it expects file data, use HTTP > Download a file first.
Does Parse response tell Make which image field to use?
It exposes structured response items for mapping, but the provider’s schema determines the field names and nesting.
Can I use a non-HTTPS screenshot endpoint?
The current Make HTTP v4 app only allows secure HTTPS connections.
