How to Troubleshoot a Screenshot API Response That Make Cannot Parse

If Make cannot parse a screenshot API response, first check the HTTP status, Content-Type, and raw response body in the module’s run output. Then choose the next module based on what the API actually returned: parse JSON as data, handle image or PDF bytes as a file, follow a documented redirect or use a returned URL, and fix an API error before trying to parse it as a successful capture. Screenshot APIs do not all use the same response format.

In Make, the HTTP app’s Parse response option structures supported responses so their fields can be mapped. It does not convert arbitrary image or PDF bytes into JSON. Make also needs a successful module run before it can expose output fields for mapping. See Make’s HTTP app documentation for the current interface; its current app is HTTP Version 4, while legacy users should select Version 3. [c001]

1. Inspect what the screenshot API actually returned

Open the scenario’s run history, select the HTTP module, and inspect its input and output bundle. Record these values before changing the scenario:

HTTP status: did the endpoint return success, a redirect, or an error status?
Content-Type: does the response identify JSON, an image format, PDF, or something else?
Raw body or file output: does the body visibly contain JSON, look like binary data, or contain a URL?
Response headers: are there provider-specific headers, a location for a redirect, or information about the returned file?
Request details: confirm the endpoint, URL being captured, authentication, query parameters, and any response-mode setting against that provider’s API reference.

Do not assume that every successful screenshot request returns JSON. For example, ScreenshotEngine documents raw image, PDF, or video bytes on successful captures and JSON for errors. Allscreenshots documents binary output by default, with separate base64 JSON and URL modes. Screenshot API documents JSON by default and an option to redirect to the image or PDF. These are examples of provider-specific contracts, not a universal standard. [c003] [c004] [c005]

2. Match Make’s next step to the response type

What you observed	What it means	What to do in Make
Valid JSON body and JSON content type	The API returned structured data, such as metadata, an error object, base64 data, or a URL.	Enable Parse response on the HTTP module. Run it once, then map the exposed fields. If the response remains a raw text field, pass that raw string to Make’s JSON parsing module.
Image or PDF content type and file/binary output	The endpoint returned the capture itself as media bytes.	Pass the response as a file to a compatible storage, email, or file-processing module. If a downstream service requires JSON, encode the file only when its API specifically asks for base64; otherwise, do not send binary data to a JSON parser.
JSON body containing a hosted URL	The API returned a link to a capture rather than the capture bytes.	Parse the JSON, map the documented URL field, and fetch that URL in a subsequent HTTP step if the next module needs the file. Check whether the URL expires or requires authorization in the provider’s docs.
Redirect status or response	The API may be directing the client to the resulting image or PDF.	Use the provider’s documented redirect behavior. If the HTTP module follows redirects, inspect the final response type; if it does not, use the documented location or redirect option as appropriate.
4xx or 5xx with JSON or text body	The request failed; the body is an error response, not a successful screenshot result.	Fix the status-level issue first: check endpoint, credentials, required parameters, capture URL, quotas, and provider error details. Configure Make’s HTTP module to return an error for 4xx/5xx if you want the scenario to take an error route.

The exact output labels in Make can vary with the HTTP app version and response shape. Use the run bundle as the source of truth, not a field name from another provider’s example.

3. Configure the Make HTTP module

Choose the correct module version. Use the current HTTP app version in your Make account. Make’s documentation says users of the legacy app should select Version 3; the current app is Version 4. [c001]
Set the request exactly as the screenshot provider documents. Use the documented method and endpoint, URL encoding, authentication method, and response-mode parameters. Do not assume a provider’s query parameters or auth scheme work with another API.
Turn on Parse response when the endpoint returns JSON. Make describes this option as structuring output data so it is easier to map. For binary image or PDF responses, parsing as JSON is the wrong operation. [c001]
Run the module once. Make makes mappable output items available after a run. Run a known successful request, then refresh or reopen downstream field mappings. [c001]
Decide how HTTP errors should flow. The HTTP app has an option to return an error for 4xx or 5xx responses. Choose whether to handle those statuses through an error route or inspect the returned error payload, then make sure the scenario does not treat an error body as an image. [c001]
Test success and failure separately. A screenshot service can return a file for success and JSON for errors. Verify both routes so a later change in authentication or capture URL does not silently break file handling. [c003]

4. If the body is JSON but Make shows no fields

Compare the body with its Content-Type. Make’s automatic response parsing relies on that header. Its custom-app documentation lists recognized types including application/json, text/plain, application/x-www-form-urlencoded, application/xml, and text/xml. The custom-app response-type setting described there is for custom app development; do not look for it as a setting in every standard HTTP module. [c002]

If the body is valid JSON and the header is application/json, enable Parse response, run the module, and inspect the output bundle again.
If the body is valid JSON but the provider uses an unexpected media type, check whether the provider offers a way to request or configure the correct content type.
If you cannot change the provider’s header, use the raw response string with an explicit JSON parser. This works only when the body is valid JSON text; it cannot parse raw image or PDF bytes.
If the body is text that merely resembles JSON, check for extra content around the JSON, such as a proxy error page, a debug message, or an HTML response. Correct the upstream response before parsing.

A Make Community discussion describes explicit parsing as a workaround in one reported case, but it is an anecdote rather than evidence that a content-type mismatch explains every failure. [c006]

5. Build a response-aware scenario

A robust scenario branches on the response instead of assuming a single format:

Send the screenshot request.
Inspect the HTTP status and response type using the fields exposed by the module.
For successful JSON, parse and map the JSON fields.
For successful image or PDF output, route the file to the module that accepts a file.
For a URL response or redirect, use the provider’s documented behavior to retrieve the capture if a file is needed.
For non-success status codes, handle the error separately and preserve the provider’s message for diagnosis.

If your provider has multiple response modes, choose based on what the next Make module needs. Compare whether the mode returns raw media, base64 inside JSON, or a hosted URL; whether downstream steps need metadata fields or a file; how errors are represented; and whether Make must follow a redirect. The provider’s API reference defines the actual contract. [c003] [c004] [c005]

6. Runnable request examples for diagnosing the response

The following examples use a generic placeholder endpoint and illustrate how to inspect status, content type, and body. Replace the URL and authentication with the screenshot provider’s documented values. These snippets do not claim that every screenshot API returns JSON or a file in the same way.

cURL: print status and response headers

curl -sS -D response-headers.txt \
  -o response-body.bin \
  -w '\nHTTP status: %{http_code}\nContent type: %{content_type}\n' \
  'https://api.example.com/screenshot?url=https%3A%2F%2Fexample.org'

cat response-headers.txt
file response-body.bin

Use the provider’s real endpoint and authentication. The separate header and body files make it easier to tell an API error response from a successful media response.

Python: inspect headers before interpreting the body

import requests

endpoint = "https://api.example.com/screenshot"
params = {"url": "https://example.org"}

response = requests.get(endpoint, params=params, timeout=90)
content_type = response.headers.get("Content-Type", "")

print("HTTP status:", response.status_code)
print("Content-Type:", content_type)

if not response.ok:
    print("Error body:", response.text[:2000])
    response.raise_for_status()

if "json" in content_type.lower():
    data = response.json()
    print("JSON response:", data)
elif content_type.lower().startswith("image/") or "pdf" in content_type.lower():
    with open("capture.bin", "wb") as capture:
        capture.write(response.content)
    print("Saved media response to capture.bin")
else:
    print("Unexpected response body:", response.text[:2000])

Install the dependency with python -m pip install requests. Replace the endpoint, parameters, and auth handling with the provider’s API requirements. This example deliberately checks status and type before saving or parsing.

Node.js: branch on status and content type

const endpoint = new URL('https://api.example.com/screenshot');
endpoint.searchParams.set('url', 'https://example.org');

const response = await fetch(endpoint);
const contentType = response.headers.get('content-type') || '';

console.log('HTTP status:', response.status);
console.log('Content-Type:', contentType);

if (!response.ok) {
  const errorBody = await response.text();
  throw new Error(`Screenshot request failed (${response.status}): ${errorBody.slice(0, 2000)}`);
}

if (contentType.toLowerCase().includes('json')) {
  const data = await response.json();
  console.log('JSON response:', data);
} else if (contentType.toLowerCase().startsWith('image/') || contentType.toLowerCase().includes('pdf')) {
  const bytes = Buffer.from(await response.arrayBuffer());
  const fs = await import('node:fs/promises');
  await fs.writeFile('capture.bin', bytes);
  console.log('Saved media response to capture.bin');
} else {
  console.log('Unexpected response body:', (await response.text()).slice(0, 2000));
}

This uses Node.js versions with the built-in fetch API. Add the provider’s documented credentials and parameters before using it.

7. Common errors and fixes

Symptom	Likely cause	Fix
JSON parser reports invalid JSON, with unreadable characters	The response is raw image or PDF bytes.	Stop parsing it as JSON. Route the HTTP output as a file or select a documented JSON/base64 response mode if the provider has one.
JSON parser reports invalid JSON, but the body starts with HTML	The API, proxy, or upstream site returned an HTML error page, often after an unsuccessful request.	Check status, endpoint, authentication, and provider error details. Do not pass the HTML body into a successful-capture route.
The run succeeds but no fields appear for mapping	Parse response is off, the module has not run since configuration, or the response is not JSON.	Enable parsing for JSON, run the module once, and inspect the output again. For binary output, map the file data instead of expecting JSON fields. [c001]
The body is JSON but automatic parsing does not expose fields	The response content type may not be one Make recognizes, or the JSON may be nested/stringified.	Check the content type and raw body. Ask the provider for the right media type where possible; otherwise explicitly parse valid raw JSON and inspect whether another parse is needed for a JSON-encoded string. [c002] [c006]
The API returns an error object instead of a capture	The request failed, but the scenario treats the error response as success.	Branch on status and inspect the provider’s error schema. Fix the underlying request problem before processing capture data.
The response contains a URL, but the next module receives no file	The API returns a hosted link or redirect, not the media bytes.	Map the documented URL and make a second request if needed. Check whether authentication, expiry, or redirect handling applies.
Works for one request but fails for another	Different inputs may produce different success and error structures, or capture output types may vary.	Test representative success and failure cases. Keep status and response-type checks before downstream mapping.

8. Reliability, performance, and cost considerations

Reliability: handle status codes and body types explicitly. A screenshot service may return JSON errors even when successful captures are binary, so a single fixed parser can fail only on error paths. [c003]
Retries: retry only when the provider documents the failure as transient or the status indicates a temporary problem. Avoid repeatedly retrying malformed requests, invalid credentials, or unsupported parameters. Check whether repeated calls can incur capture charges in the provider’s pricing terms.
Timeouts: set the Make request timeout to fit the provider’s documented capture behavior and your scenario’s limits. A timeout is not evidence that the body was malformed; the response may never have arrived.
Payload size: raw full-page images and PDFs can be larger than JSON metadata. Consider whether a hosted URL or provider-supported resize/output option better fits downstream storage limits, when available.
Cost: billing rules differ by provider. Confirm whether failed captures, retries, cached results, binary downloads, and URL modes count as billable usage. The dossier provides no comparable price or performance figures across the cited providers.

9. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. Its one-call endpoint returns PNG, JPEG, WebP, or PDF output; check the response headers and handle the returned type in Make just as you would with any screenshot endpoint. See the ScreenshotNeo API documentation for request parameters and response details.

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 like a visitor and 60+ known consent platforms, newsletter popups, and chat widgets are removed before the shot; each step can be turned off.
Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing. Response headers say which page verdict applied and whether the request was billed.
An MCP server gives AI agents, including Claude and Cursor, the tools take_screenshot, get_page_info, and capture_pdf.
1,000 screenshots per month are free with no card. Paid plans start at $5 for 3,000 screenshots; every feature is on every plan.

10. FAQ

Does Parse response mean Make will turn the screenshot into JSON?

No. It structures supported response data for mapping. Raw image and PDF bytes remain media; they are not JSON fields. [c001]

Should I always use base64 so Make can parse a screenshot?

No. Base64 is useful when a downstream API specifically needs the file embedded in JSON. Otherwise, binary file handling or a hosted URL may be more suitable. Only use a mode the screenshot provider documents. [c004]

Can I trust the Content-Type header by itself?

Use it as a diagnostic clue and compare it with the raw body and status. If they disagree, investigate the provider, proxy, or endpoint response instead of assuming the body has the advertised format.

Why are fields missing until I run the module?

Make exposes output items for mapping after the HTTP module has run and produced a sample response. [c001]

Sources

[c001] Make HTTP app documentation.
[c002] Make custom app response documentation.
[c003] ScreenshotEngine API documentation.
[c004] Allscreenshots API documentation.
[c005] Screenshot API documentation.
[c006] Make Community report referenced in the research dossier; it is a single reported case, not a general guarantee.