How to troubleshoot a screenshot API that returns a 400 error in n8n

A screenshot API returns HTTP 400 in n8n when the service considers the request malformed or invalid. The exact fix depends on the provider: inspect its response body, then compare the endpoint, method, parameters, authentication, body encoding, and target page URL with that provider’s current API documentation. n8n identifies invalid query parameter names or values and incorrectly formatted array parameters as common causes of this error. n8n’s HTTP Request common-issues guide advises: “Review the API documentation for your service to format your query parameters.”

1. Capture the full error details

Open the failed n8n execution and record the status code, response body, endpoint, method, and request configuration. The generic “Bad request – please check your parameters” text is not enough to identify which field the provider rejected. The response may name a missing field, unsupported value, invalid URL, or malformed body.

For diagnosis, you can configure the HTTP Request node to include response headers and status. Its “Never Error” response option can also let the workflow continue with the response available to inspect. These are inspection and flow-control settings: they expose the service’s response but do not repair a rejected request. See the HTTP Request node documentation for the available options.

Open the failed execution and select the HTTP Request node.
Expand its error or output details and copy the complete response body.
Note the exact request method, API endpoint, query parameters, headers, authentication, and body configuration.
Redact API keys, cookies, authorization values, and other secrets before sharing the details for help.

2. Check the API endpoint and method

Confirm the hostname, path, API version, and HTTP method against the screenshot provider’s current documentation. A typo or retired endpoint can produce a bad-request response. Keep the API endpoint separate from the page URL that the service is being asked to capture: both must be valid, but they serve different purposes.

Request part	What to verify
API endpoint	Correct provider hostname, path, and supported API version.
Method	The documented method, often GET or POST, for the selected endpoint.
Capture URL	A complete page URL with a scheme such as `https://`, and any provider-specific restrictions.

3. Verify parameter names, values, and arrays

Compare every query parameter with the provider’s reference, including spelling, capitalization, required fields, allowed values, and data type. A parameter accepted by one screenshot API may be unknown to another. Remove unneeded parameters temporarily, then add them back one at a time to isolate the field that triggers the 400.

Array query parameters need the serialization the API expects. n8n offers formats such as repeated unbracketed keys, bracket suffixes, and indexed brackets. These produce different requests: for example, a list might be sent as tag=a&tag=b, tag[]=a&tag[]=b, or tag[0]=a&tag[1]=b. Use only the form documented by your provider.

Check required parameters first, then optional settings.
Check case and punctuation; full_page, fullPage, and fullpage are distinct names.
Confirm booleans and numbers use the API’s expected representation.
Remove empty values and parameters copied from another provider’s example.
For arrays, confirm both the parameter name and the serialization format.

4. Match body encoding and headers

For POST requests, the body format must match the API contract. n8n supports JSON, multipart form-data, form URL-encoded, binary-file, and raw body configurations. These are not interchangeable: sending JSON while the API expects form-data can make required fields appear missing. Check the content type and field names as well as the body itself.

Also compare authentication and other required headers with the provider’s docs. A missing or incorrectly placed API key can produce different status codes depending on the service, so use the response body and API reference rather than assuming every 400 has the same cause.

Choose the body format the provider documents.
Use the exact documented field names and nesting.
Set required content-type and authentication headers as specified.
Remove manually set headers that conflict with n8n’s body configuration, unless the API requires them.

5. Validate both URLs and provider restrictions

Check the API URL for typos and the target page URL for a valid scheme and hostname. Screenshot services may apply additional rules, but restrictions vary by provider. For example, screenshot-api.net’s documentation lists restrictions on schemes, private or reserved addresses, embedded credentials, and certain ports. Treat that as an example of provider-specific validation, not a universal rule for screenshot APIs.

If the target page is behind a login, uses a private network address, or redirects to another host, check whether your provider supports that case and whether the request supplies the needed cookies or headers. Do not send credentials in the page URL unless the provider explicitly documents that method.

6. Compare n8n with a known-good cURL request

Start with a cURL example from the same provider’s current API documentation. Compare its method, endpoint, query string, headers, authentication, and body with the HTTP Request node. n8n can import cURL commands into the node, which helps map request fields, but review the imported configuration: imported parameter values are strings, and the API may expect numbers or booleans.

Use this checklist while comparing:

Does the hostname and path match exactly?
Does the method match the example?
Are all required query parameters present and spelled correctly?
Are arrays encoded in the required format?
Are authentication and content headers in the right place?
Does the body use the expected encoding and field names?
Did imported values retain the expected types?
Is the capture URL acceptable under this provider’s rules?

A 400 is a response from the service, so first investigate the encoded request. A connection refusal or other connectivity failure is a different failure mode. Repeating an unchanged malformed request is unlikely to help.

7. Common errors and fixes

What you see	Likely cause	What to do
“Bad request – please check your parameters”	Invalid parameter name or value, or array format not accepted.	Compare parameter names, allowed values, and array serialization with the provider’s docs.
Response says a field is missing	The field is absent, nested incorrectly, or sent in the wrong body format.	Check the required field name, body encoding, and content type.
cURL works, n8n gets a 400	The requests differ in encoding, headers, types, or form fields.	Import or compare the working cURL request, then review the resulting node configuration and value types.
Target URL is rejected	Malformed URL or a provider-specific URL restriction.	Check the scheme, address, redirects, and the provider’s documented restrictions.
The error appears after changing the API version	Endpoint or parameter contract may have changed.	Use the current endpoint and parameters documented for that version.
“Never Error” makes the workflow continue, but no screenshot appears	The option changed error handling, not the request’s validity.	Inspect the returned status and body and fix the rejected request.

A reported n8n multipart upload issue described a specific “No file field in request” response even though cURL worked. That individual report is not evidence that multipart handling explains a screenshot API’s 400; use it only as a reminder to compare the actual transmitted fields when form-data is involved. See the reported issue.

8. Keep the workflow reliable and economical

Malformed requests are deterministic: retrying the same endpoint, parameters, and body usually repeats the same rejection. Fix the request before adding retries. Once the request is valid, use retries only for failures that may be transient, and follow the provider’s guidance for rate limits and retry timing.

For debugging, change one request component at a time and keep a known-good request example alongside the workflow. Avoid logging secrets when saving request details. If the provider returns a useful error body, preserve it in the workflow’s diagnostic output so the next failure is easier to identify.

Or skip the browser setup

ScreenshotNeo provides a screenshot API: one GET request returns an image or PDF. Cookie banners are accepted and removed before capture, along with supported newsletter popups and chat widgets. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed; response headers identify the page verdict and billing status. Its MCP server gives AI agents tools for screenshots, page information, and PDF capture.

Example request:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Replace YOUR_API_KEY with your key and change the target URL as needed. See the ScreenshotNeo API documentation for request options and formats. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots. Learn about ScreenshotNeo and sign up for 1,000 free screenshots a month, no card required.

FAQ

Does n8n generate the 400 error?

The HTTP Request node reports that it received a 400 response from the target service. Inspect that service’s response body to find what it rejected.

Can I fix a 400 by enabling “Never Error”?

No. It can expose the response while allowing the workflow to continue, but it does not make the request valid.

Share the provider name, endpoint path, method, redacted node configuration, and complete response body. Remove API keys, cookies, and other secrets.

Is every 400 caused by a bad target page URL?

No. The rejected part could be the endpoint, method, parameters, array encoding, authentication, headers, or body format. Check both URLs and the full request.