How to Test a Screenshot API Endpoint with Postman
Build a Postman request, inspect its response, and verify the captured page. Includes provider-specific checks and a ScreenshotNeo one-call option.
To test a screenshot API endpoint with Postman, create a request using the method, URL, authentication, and parameter format specified in that provider’s documentation. Send it, inspect the HTTP status, headers, and response body, then open the returned image or PDF and confirm it shows the intended page. A successful API response alone does not prove the target page loaded correctly: the image could show a login screen, an error page, or a blank page.
There is no universal screenshot API request format. Providers may use GET with query parameters, POST with a JSON body, bearer tokens, API-key headers, or Basic Auth. Responses may be binary image bytes, JSON, or a redirect. Treat the examples below as patterns and use your chosen provider’s current endpoint documentation for the actual request details.
1. Gather the endpoint details
Before configuring Postman, find these details in the API documentation:
- Endpoint URL: the full path, including its version.
- HTTP method: commonly GET or POST.
- Authentication: bearer token, API-key header, Basic Auth, or another documented scheme.
- Target URL field: the name and location of the page URL parameter, such as a query parameter or JSON property.
- Capture options: supported format, viewport, full-page setting, and any wait or rendering options.
- Expected response: image or PDF bytes, JSON, or a redirect.
- Page-status signal: any documented header or response field describing the target page’s load status.
Do not assume that two screenshot APIs accept the same method, parameter names, or credentials. For example, documented services use both GET and POST; some use bearer authentication, while others document an API-key header or Basic Auth.
2. Create and configure the Postman request
- In Postman, create a new HTTP request.
- Select the exact method from the provider’s documentation.
- Enter the documented endpoint URL.
- Open the Authorization tab and select the documented authentication type. For bearer authentication, choose Bearer Token and enter the token. For Basic Auth, enter the documented username and password. If the service requires an API-key header, choose No Auth and add the specified key and value under Headers.
- Enter the target page URL and capture options in the location required by the endpoint: Params for query parameters, or Body for a JSON request.
- For a JSON POST request, select Body → raw → JSON so Postman sends the appropriate JSON content type.
- Send the request and inspect the response before treating the test as successful.
GET with query parameters
For a GET endpoint, put the base endpoint in the URL field and add the target page and options in Params. Postman encodes query values, which is safer than manually joining a long URL. A provider might document a request shaped like this:
GET https://provider.example/v1/screenshot?url=https%3A%2F%2Fexample.com&width=1280&height=800&format=png
provider.example is a placeholder, not a real endpoint. Replace the URL, parameter names, and options with values from your provider’s documentation. Do not send a JSON body with GET unless that endpoint explicitly requires it.
POST with a JSON body
For a POST endpoint that documents JSON input, select POST, set its URL, configure authentication, then enter the documented JSON fields under Body → raw → JSON. A generic example is:
{
"url": "https://example.com",
"width": 1280,
"height": 800,
"format": "png",
"full_page": true
}
This body illustrates the shape only. Field names and supported values vary by provider. Use only options in the endpoint reference.
3. Read the response correctly
After sending, check the status code, headers, and response body. Then verify the capture itself.
| What to inspect | What it tells you |
|---|---|
| HTTP status | Whether the API request was accepted and processed. A success status does not guarantee the desired page was captured. |
Content-Type |
Whether the response declares an image, PDF, JSON, or another type. Compare it with the endpoint documentation. |
| Response body | For JSON, inspect the documented fields. For binary output, use Postman’s response view or save/download handling to inspect the file. |
| Target page status | If the provider exposes a documented header or JSON field for the target document, use it to distinguish an API success from a page-level error. |
| Rendered content | Open the image or PDF and check that it shows the intended page, viewport, and content rather than a login, error, or blank page. |
Some endpoints return raw image bytes, some return JSON, and others may redirect to a file. A JSON response is not necessarily an error, and an image response is not necessarily proof that the correct page loaded. Follow the response-handling instructions for the endpoint you are testing.
4. Use a repeatable Postman setup
Once the request works, save it in a collection so you can repeat the same capture after changing the target URL or options.
- Save the request with a name that identifies the provider and capture case.
- Store reusable endpoint details and credentials in a Postman environment or collection variables. Keep secret tokens out of shared request examples and exported collections.
- Use variables for the base URL, token, and target page if you expect to run the request against different environments.
- Keep the expected method, parameter names, and response type next to the request so another developer can compare them with the provider’s documentation.
- When a provider changes its API, update the saved request from the current endpoint reference rather than relying on an old example.
5. ScreenshotNeo request example
ScreenshotNeo is a website screenshot API and MCP server. Its screenshot endpoint accepts a GET request to return a screenshot or PDF. To try it in Postman, create a GET request to https://api.screenshotneo.com/v1/shot, then add access_key and url under Params. Set access_key to your key and url to the page to capture. The API details and capture options are in the ScreenshotNeo documentation.
For example, the parameters correspond to this cURL request:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
To compare the same request outside Postman, these are runnable Python and Node.js examples:
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
timeout=90,
)
r.raise_for_status()
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}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));
Replace YOUR_API_KEY and the target URL. Treat a successful HTTP response as only one part of the check: inspect the image and any documented response headers to confirm what happened during capture.
6. Troubleshooting
| Symptom | Likely cause | What to check or change |
|---|---|---|
| 401 or 403 response | Missing, invalid, expired, or incorrectly placed credentials; the endpoint may use a different authentication scheme. | Compare the Authorization setting or API-key header with the provider’s current docs. Check for whitespace or a misplaced key. |
| 404 response | Incorrect host, path, or API version. | Copy the complete endpoint from the provider reference, including its versioned path. |
| 405 response | The request method is not supported at that endpoint. | Change GET to POST, or vice versa, only as the documentation specifies. |
| 400 response or parameter validation error | A required field is missing, a parameter is misspelled, or the request body format is wrong. | Check required fields, exact parameter names, value types, URL encoding, and whether the endpoint expects query parameters or JSON. |
| 415 response | The body’s media type is unsupported or missing. | For a documented JSON request, choose raw JSON in Postman and confirm the request sends Content-Type: application/json. |
| Postman shows unreadable characters | The API returned binary image or PDF bytes that the current response view does not display as a document. | Check Content-Type and use Postman’s save or download handling to open the file with a suitable viewer. |
| HTTP success, but image shows a login or error page | The API successfully captured a page that the target site served, such as a login page or an error document. | Inspect the screenshot and any documented target-page status header or field. Check whether the target needs authentication, a different URL, or extra render wait time. |
| Blank or incomplete capture | The page may require more time to render, depend on client-side JavaScript, or load content below the initial viewport. | Check the provider’s documented wait and full-page options. If supported, wait for a selector or network idle and request full-page capture when needed. |
| Postman reports a timeout | The page or capture took longer than the request’s timeout, or the endpoint is slow to respond. | Confirm the target URL is reachable, review the provider’s timeout guidance, and use a longer client timeout where the API supports longer captures. |
| Redirect or JSON returned instead of an image | The endpoint may intentionally return a redirect or JSON wrapper, or a response option may select a different mode. | Inspect status, Location, and Content-Type; follow the documented redirect and response behavior. |
7. Performance, reliability, and cost
- Keep captures focused: use the smallest viewport, output format, and page scope that answers your test. Full-page captures and complex pages can take longer or produce larger files.
- Allow for rendering: dynamic pages may need a documented wait condition. A fixed delay can be simple, but waiting for a meaningful selector is often a clearer test when the provider supports it.
- Separate API health from page health: record the HTTP result and inspect the screenshot or page-status signal. A provider can successfully return an image of a page-level failure.
- Repeat deliberately: cache behavior, if offered, can affect repeated captures. Check the provider’s cache controls when you need a fresh render.
- Understand billing rules before automating: providers define billable requests differently. Check the plan and response indicators rather than assuming that every request, retry, or failed page is free.
ScreenshotNeo reports the page verdict and billing outcome in response headers. It bills only clean shots; bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Its plans include 1,000 shots per month free with no card, then paid plans from $5 for 3,000 shots. Check the docs for the endpoint’s current parameters and behavior.
Or skip the browser setup
Make one GET request with your key and target URL:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed, and response headers report the page verdict and billing result. An MCP server lets AI agents use its screenshot, page-info, and PDF tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. See the API documentation, then sign up free for 1,000 screenshots a month with no card.
FAQ
Does a 200 response mean the screenshot is correct?
No. It means the API request succeeded at the HTTP level. Inspect the returned capture and any target-page status signal.
Should I use Postman’s Authorization tab or add a header myself?
Use whichever matches the provider’s documented authentication scheme. Postman’s Authorization tab can generate common headers, while some APIs require a specifically named API-key header.
Can Postman display an image response?
It depends on the response and Postman’s handling of it. Check the content type and use its save or download option when the body is binary.
Why does the same request work in code but fail in Postman?
Compare the raw method, final URL and query encoding, headers, authentication, body, and redirect behavior. One difference in these details can change the request.


