How to Integrate a Screenshot API with Make (Integromat)

To integrate a screenshot API with Make, add an HTTP request module to a scenario, send it the page URL and the authentication your provider requires, then pass the response to a module that can store or use the resulting file. The exact endpoint, parameters, response type, and authentication are provider-specific. This guide walks through the generic Make HTTP approach, explains how to handle image data, and covers the native ScreenshotOne app as another route.

A screenshot API captures a web page on a remote browser and returns an image, PDF, or sometimes a URL or structured response. Make can call APIs that do not have a native integration through its HTTP app. Before building the scenario, check your provider’s current API documentation for the endpoint, method, required fields, response format, limits, and key handling. Make’s HTTP app documentation describes its request and file-download modules: Make HTTP app documentation.

1. Choose your Make integration route

There are two practical routes in the documented sources:

Route	Use it when	What to check
Make HTTP app	You want to call a screenshot provider’s API directly, especially if it has no suitable native Make app.	Endpoint, method, auth, request fields, response type, and error handling.
ScreenshotOne app for Make	You use ScreenshotOne and its listed modules fit your scenario.	Current availability, module fields, support, and any third-party terms or fees.

Make’s app directory lists a community-developed ScreenshotOne integration with “Take a static screenshot,” “Take an animated screenshot,” and “Make an API Call.” The listing notes that developer terms or fees may apply, so confirm the current details in Make before relying on it. The generic HTTP route gives you a more provider-neutral setup, but you must match each provider’s own API contract.

2. Build the scenario around the page URL

1. Pick a trigger. Use an app event that provides the URL to capture, or start with a custom webhook. Make describes custom webhooks as instant triggers that receive an incoming request. In a test payload, send a field such as url with a complete HTTPS address.
2. Add the screenshot request. Add Make’s HTTP “Make a request” module after the trigger. Use the provider’s HTTPS endpoint and method. Map the trigger’s URL field into the API’s target URL parameter or JSON property.
3. Configure authentication. Follow the provider’s documented method. Use Make’s dedicated credential controls where the selected auth method supports them. Do not expose a live key in a public scenario screenshot, shared blueprint, or sample URL.
4. Run once and inspect the output. Make needs a sample response to expose fields for downstream mapping. Inspect the status, headers, content type, and body. Establish whether you received binary image data, a file object, JSON containing a URL, or an error response.
5. Connect the destination. Map the returned image or file into the next module, such as a storage or messaging app. If the API returns binary data, the next module must accept a file or Make file object. If the provider returns a hosted image URL, map that URL instead.
6. Decide what failures should do. Configure Make’s HTTP error behavior and scenario error route deliberately. A failed capture should not be passed onward as though it were an image.

Make’s HTTP app supports standard methods, headers, query parameters, and different body types. Its documented authentication choices include API key, Basic Auth, and OAuth 2.0. A particular screenshot provider may support only a subset or require a different arrangement. Use HTTPS; Make requires secure HTTPS connections for HTTP requests and advises keeping credentials in its credential field instead of embedding them in headers or query parameters.

3. Configure a provider-specific request

ScreenshotOne is a concrete example of a provider with public endpoint documentation; it is not a universal screenshot API contract. Its getting-started guide documents a GET request to https://api.screenshotone.com/take with a target url and an access_key. It also documents POST requests with screenshot options in a JSON body. Its access-key guide describes query, POST-body, and X-Access-Key header approaches. Follow the current instructions for the provider you select; do not assume another API accepts the same endpoint or credentials.

For a minimal ScreenshotOne-style GET request in Make, configure:

Setting	Example	Notes
URL	https://api.screenshotone.com/take	Use the endpoint documented by your provider.
Method	GET	ScreenshotOne also documents POST for options in a JSON body.
Query parameter	url = mapped page URL	URL-encode values; use Make’s parameter fields rather than concatenating query strings by hand.
Authentication	access_key per provider instructions	Use credential storage where compatible. Avoid publishing a key in a scenario URL.
Response	Image binary for a standard image response	Check response headers and the provider’s selected output option.

For a POST request, select the provider’s documented JSON body type and include only supported options. ScreenshotOne’s options documentation describes URL, HTML, or Markdown as possible inputs and PNG, JPEG, WebP, PDF, and text formats as possible outputs. It can return binary data for a requested format or JSON for relevant response options. These details belong to ScreenshotOne; another provider may use different fields and outputs. Refer to its API documentation and access-key guide.

4. Map the response into the next Make module

Do not assume the capture result is a public image URL. ScreenshotOne documents a binary response for standard image output. In Make, inspect the output after a successful run and choose the next step accordingly:

• Binary/file response: map the returned data and filename or content type into a destination module’s file input. If the destination expects a file object, use Make’s HTTP “Download a file” module when appropriate to turn an accessible URL into a file. Check the destination module’s field requirements.
• JSON with an image URL: map the URL field. If the next app needs the actual file, download that URL before sending it.
• PDF or other format: verify the provider’s response content type and the destination’s accepted file formats.
• Error JSON: route it to a notification, log, or review path. Do not map an error body into the file field.

Make’s HTTP app includes “Make a request,” “Download a file,” and “Resolve URL.” Which module is appropriate depends on whether your provider returns bytes, a file-like response, or a URL. A successful HTTP status alone is not enough to prove the result is a usable image: validate the response’s content type or provider-specific result fields before continuing.

5. Set up an example end-to-end workflow

For example, a custom webhook can receive a page URL, the HTTP module can capture it, and a storage module can archive the resulting image. The steps below describe configuration rather than a claim that a particular scenario was tested:

1. Create a custom webhook in Make and copy its generated webhook address into the upstream service that will submit capture requests.
2. Send a sample payload containing a full page URL, for example {"url":"https://example.com"}. Use a page you are permitted to access.
3. Add HTTP “Make a request.” Set the provider endpoint and method, then map the webhook’s url field into the provider’s target URL parameter. Add authentication using the provider’s documented method and Make’s credential controls where supported.
4. Run the scenario once with the sample. Confirm the response is successful and determine whether Make exposes a file, binary body, or URL.
5. Add a destination that accepts the result. Map the file data and any required filename or MIME type, or download a returned URL first if that is what your destination requires.
6. Add an error handler or route for failed HTTP responses. Send useful error details to a review destination and prevent the normal file-upload path from running.
7. Test the workflow with a normal page and an intentionally invalid or unavailable URL, then enable the schedule or upstream trigger that should run it in production.

Use controlled test inputs and avoid sending sensitive URLs or credentials to logs that are visible to people who should not see them. If the source URL is user supplied, consider what your workflow should do with malformed values and destinations that are outside the intended scope.

6. Authentication and key safety

API keys can be handled differently by different providers. Some accept a query parameter, some accept a header, and some accept credentials in a POST body. ScreenshotOne documents these options for its access key. Make’s advice is to store credentials in its dedicated credentials controls when possible rather than hard-coding a secret into a request.

• Use HTTPS endpoints only.
• Keep live keys out of public blueprints, screenshots, logs, and shared sample requests.
• Limit access to scenarios and connections that can use the credential.
• If a key is exposed, replace it. ScreenshotOne warns that exposed keys should be replaced and that unsigned public screenshot URLs can expose keys.
• Check whether your provider supports a header-based key method if putting a secret into a query string would expose it in logs or copied URLs.

Do not place a real API key in the sample settings above. Use a placeholder in documentation and test with a key stored through the provider and Make’s supported credential mechanism.

7. Options to consider for screenshot jobs

Keep the first request minimal, then add options only when the workflow needs them. Options vary by provider. ScreenshotOne’s documentation includes examples such as output format and different input types; consult its options reference for exact names, allowed values, and compatibility.

Need	What to decide	Workflow consideration
Image or document	PNG, JPEG, WebP, PDF, or another supported output	Match the destination’s accepted formats and any later processing.
Target content	Public URL, supplied HTML, or another documented input	Validate the input and encode it as required by the request type.
Capture timing	Wait behavior or page readiness, if offered	Longer waits can increase scenario duration; define a failure path for timeouts.
Response mode	Raw binary or JSON response	Build downstream mapping for the actual response format.
Authentication	Header, credential control, query, or POST body	Use the provider’s supported method and protect secrets.

Only include options the provider documents. Do not copy a parameter from another screenshot service without checking that it is supported at the selected endpoint.

8. Troubleshooting common errors

Symptom	Likely cause	Fix
401 or 403 response	Missing, invalid, expired, or incorrectly placed key; account or endpoint permissions may also be involved.	Check the provider’s required authentication method, key status, and endpoint. Store the secret in Make credentials where supported.
400 response	Required target URL or option is missing, malformed, or sent in the wrong place.	Compare the configured method and fields with the provider’s API reference. Inspect the encoded request parameters and remove unsupported options.
404 response	Wrong endpoint path or API version.	Copy the exact HTTPS endpoint from the provider’s current documentation.
429 response	Provider rate limit or account quota reached.	Check provider limits and usage. Reduce simultaneous requests or add retry behavior only if the provider documents how retries should work.
5xx or timeout	Provider-side failure, slow page, or capture that exceeded a time limit.	Use a deliberate retry or review route, avoid unlimited retries, and confirm whether a repeated capture could create extra usage under that provider’s rules.
Downstream module says file is missing	The response is binary but was mapped as text, or the API returned JSON/error content rather than an image.	Inspect a successful run’s output, status, and content type. Map the actual file data or download a returned URL.
File is corrupt or has the wrong extension	Filename or format does not match the response, or an error body was saved as an image.	Check content type and provider output selection; use a matching filename extension and filter unsuccessful responses.
URL works in a browser but not in the capture	The page may require authentication, be inaccessible to the provider, or load content asynchronously.	Check provider support for cookies, headers, or wait options and ensure you are authorized to capture the page. Confirm the resulting response before uploading.

Make’s HTTP module has an option to return an error when a request receives a 4xx or 5xx response. Choose whether such failures should stop the route or enter an error handler. In either case, keep success and failure paths distinct so an API error cannot be mistaken for a screenshot.

9. Performance, reliability, and cost

A scenario’s runtime includes the remote page load, capture processing, Make’s request, and downstream file transfer. Large full-page images or slow pages can take longer to process and move. Where your provider exposes output or waiting controls, choose settings that meet the workflow’s needs and avoid waiting longer than required.

For reliability, make failure behavior explicit. Use bounded retries only where appropriate, record enough status information to diagnose failures, and prevent repeated retries from creating a loop. If your scenario processes many URLs, consider how Make scheduling and the provider’s rate or quota limits interact. Do not assume that a failed request is free or billed; check the selected provider’s terms and usage reporting.

Cost can include both Make operations and the screenshot provider’s usage. Check current plan limits, billing rules for errors and retries, and whether the provider bills by request, successful capture, or another measure. A binary response may also increase the amount of data transferred to a downstream storage module. The research sources do not establish a universal price or billing rule across providers.

10. Or skip the browser setup

For a direct Make HTTP call using ScreenshotNeo, add an HTTP request to https://api.screenshotneo.com/v1/shot with your key and target URL. ScreenshotNeo is a website screenshot API and MCP server from ScreenshotNeo. Its API returns PNG, JPEG, WebP, or PDF; follow the ScreenshotNeo API documentation for request setup 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.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}`);

In Make, configure the same endpoint and fields in the HTTP module, store your API key using Make’s credential controls where compatible, and inspect the returned file before mapping it onward. ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000. Sign up free for 1,000 screenshots a month.

FAQ

Does Make have to use a screenshot API?

No. The API route is useful when you want a remote browser capture in an automated scenario. Whether it is the right approach depends on your provider, workflow, and destination.

Can I use any screenshot API with Make?

You can call APIs that accept requests compatible with Make’s HTTP app, but each provider has its own endpoint, authentication, fields, and response behavior. Follow that provider’s API documentation.

Will Make always receive an image URL?

No. A screenshot API may return binary image data, a file-like response, JSON, or a URL. Inspect the actual response and configure the next module accordingly.

Should I use the native ScreenshotOne app or HTTP?

Use the route whose current modules and terms fit your scenario. The native app can expose task-specific actions; HTTP is useful when you need a generic request or another provider.

Can I safely share my scenario?

Remove or protect credentials and sensitive sample data before sharing. Use Make’s credential controls where supported and replace a key if it has been exposed.